Mainline TF-A doesn't initialize SGRF_SOC_CON8-CON15 which control
DMAC0 and DMAC1 configuration. Without this, the PL330 DMA controllers
cannot be accessed from Linux and PERIPH_ID reads as 0x0.
The fix configures SGRF registers to set DMAC manager threads to
running state and non-secure mode, then pulses DMAC reset to apply
the new configuration.
Based on community reverse-engineering:
- https://lists.denx.de/pipermail/u-boot/2023-April/514267.html
- https://gist.github.com/CrystalGamma/a68333fa4c9fda7eb6c09d30ad4937fe
Tested on Helios64 (RK3399).
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Eric submitted upstream, thanks!
- Neil RB'ed it
- `b4 am -o- --add-link --check-newer-revisions "https://lore.kernel.org/all/20260116-odroid-hc4-dts-v1-1-459b601cd5cf@linuxdev.slmail.me/" > patch/kernel/archive/meson64-6.19/board-odroid-sm1-regulators-boot-on.patch`
- Armbian's patching.py chokes on b4's "cover-below-the-fold" style, small manual fix needed before rewrite
Remove usb-role-switch property from fusb302 node and replace with
extcon property. The usb-role-switch property breaks PD negotiation
and DP alt mode on kernel 6.18+.
Fix based on PR #9245 (Pinebook Pro) by amazingfate.
Apply Helios64: fix Type-C PHY registration #9158 to 6.19.
- Fixes: 4eac206ecf which over-dropped
- meanwhile for increased insanity, patch changed name as it went upstream:
- ML was `PCI: meson: Remove meson_pcie_link_up() timeout, message, speed check`
- torvalds got `PCI: meson: Report that link is up while in ASPM L0s and L1 states`
- Greg KH has already queued for 6.18.6 (coming from 6.19-rc5, so torvalds name), so remove this when that is released
- 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.
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.
- 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
