- a bit verbose but confirms missing `ethernet0`/`1` alias was the cause of random MACs for at least a few boards
- there's quite a few boards to fix, so we might want to pull this one level up later
- By fully describing the pcie hardware for the RTL8125s (rtl8169) present on the
board, we get to alias them to ethernet0/1. In return, (mainline) u-boot will by
default patch the runtime FDT though it's fdt_fixup_ethernet() implementation,
hopefully resulting in fully stable MAC addresses without the need to program
the RTL NIC's EEPROM; as an added benefit, u-boot MAC & kernel MAC would match,
facilitating network-boot setups.
- optionally, if UBOOT_BINS_TO_OUTPUT=yes, copy them out to output/
- this might reveal differences in binwalk itself more than u-boot
- but better than nothing
Problem:
On Helios64 boot, the Type-C PHY (ff7c0000.phy) gets stuck in
"deferred probe" state with unknown reason. This causes:
- USB 3.0 SuperSpeed via Type-C port not working
- DisplayPort via Type-C (Alt Mode) not working
The following messages appear in dmesg:
platform ff7c0000.phy: deferred probe pending: (reason unknown)
platform fe800000.usb: deferred probe pending: wait for supplier /phy@ff7c0000/usb3-port
platform fec00000.dp: deferred probe pending: wait for supplier /phy@ff7c0000/dp-port
Along with dependency cycle warnings:
/phy@ff7c0000/dp-port: Fixed dependency cycle(s) with /i2c@ff3d0000/typec-portc@22/connector
Root cause:
The Helios64 DTS uses a legacy Type-C connection method:
&tcphy0 {
extcon = <&fusb0>; // Expects extcon from fusb302
};
However:
1. The FUSB302 driver with TCPM support (since kernel ~4.14) does NOT
create extcon devices
2. Instead, it uses the Type-C connector class (/sys/class/typec/)
3. The phy-rockchip-typec driver calls extcon_get_edev_by_phandle(),
fails to find an extcon device at the specified phandle, and
returns -EPROBE_DEFER
4. The PHY remains in deferred probe indefinitely
The extcon-cables property is present in the DTS, but without a
typec_extcon_bridge node it serves no purpose.
This bug has existed since Type-C support was added to Helios64
(at least since kernel 6.6). It likely worked with older fusb302
driver versions, but broke after the transition to TCPM.
Solution:
Use the typec-extcon-bridge driver (Armbian patch from Ondrej Jirman/megi)
which translates Type-C connector class events to the extcon interface.
The Pinebook Pro patch (board-pbp-add-dp-alt-mode.patch) implements this
correctly: it has a typec_extcon_bridge node, and all extcon references
point to it rather than directly to fusb0.
Changes:
1. Add typec_extcon_bridge node with compatible = "linux,typec-extcon-bridge"
2. Change extcon = <&fusb0> to extcon = <&typec_extcon_bridge> in
tcphy0, cdn_dp, u2phy0, usbdrd_dwc3_0 nodes
3. Add usb-role-switch, mode-switch, orientation-switch properties
to fusb0 connector for integration with the bridge
4. Update PDO definitions with DUAL_ROLE and DATA_SWAP flags
5. Convert typec-altmodes property to modern altmodes subnode format
(required for TCPM port registration)
6. Add extcon,ignore-usb to u2phy0 (following Pinebook Pro pattern)
7. Add snps,usb3-phy-reset-quirk to usbdrd_dwc3_0
After this fix:
- Type-C PHY (ff7c0000.phy) no longer stuck in deferred probe
- USB 3.0 SuperSpeed via Type-C port should work
- DisplayPort via Type-C (Alt Mode) should work
- Correct cable orientation detection
- USB role switching (host/device)
Known remaining issues:
- FUSB302 fails to register TCPM port with error:
4-0022 typec_fusb302: cannot register tcpm port
This prevents USB Power Delivery negotiation. The root cause
appears to be in the connector configuration and requires
further investigation.
- Use SERIALCON instead of systemd override for serial console
- Remove fdtfile from bootenv (use BOOT_FDT_FILE instead)
- Remove ATF_COMPILER (arm64 default)
- Inline OPTEE variables into fetch_sources_tools hook
- Remove empty family_tweaks() and family_tweaks_bsp()
- Use only debug mode for ATF build
- Build fiptool in atf_custom_postprocess
- Move header creation inline into uboot_custom_postprocess
- Use <<- heredoc for Python script
This commit implements a complete parallel repository management system
that allows building and publishing Debian repositories in parallel,
significantly reducing build time for multiple distributions.
- `update-main`: Builds common/main component once for all releases
- `update -R <release>`: Builds release-specific components in isolated DBs
- `merge`: Combines common + release-specific components into final repos
- Isolated databases (aptly-isolated-<release>) avoid locking during parallel builds
- Common component built once, not duplicated per release
- Release-specific components (utils, desktop) built independently
- Final merge combines all components with proper GPG signing
- Fixed GPG signing to target top-level Release files (dists/{release}/Release)
- Pool cleanup before publishing avoids "file already exists" errors
- Smart package import skips duplicates during merge
- Proper handling of empty repositories and missing components
- Improved error handling and logging throughout
1. update-main: Build common component (once)
2. update -R <release>: Parallel workers build release-specific components
3. merge: Combine all components and publish with GPG signatures
This enables GitHub Actions to run multiple release builders in parallel,
reducing total repository build time from hours to minutes.
Signed-off-by: Igor Pecovnik <igor@armbian.com>
- move patches into version folder (`atf-rockchip` -> `atf-rockchip/v2.13`)
- also prepares patches for v2.14 since I had them anyway
- keeps using v2.13 for now, someone can test v2.14 later and bump; I've no rk3399
- new patches:
- add `-no-pie` to rk3399's m0 build LDFLAGS (since upstream doesn't honor M0_LDFLAGS)
- bump PMSURAM_RSIZE from 8k to 16k to avoid overflows - confirmed working by Amazingfate
- build tested OK on jammy/bookworm/trixie/noble/resolute
- resolute's gcc 15 and it still builds
