Kwiboo's `rk3506` branch is WIP / rebased often. Pin to commit hash while upstreaming work is underway.
Also revert (broken) changes that attempted to keep up with this branch.
- Change BOOTCONFIG from rk3506b to rk3506j variant
- Update btrfs patch to target correct defconfig
- Add OPTEE image support for secure boot functionality
In Linux 6.19, net_device->dev_addr is const unsigned char *.
Clang with -Werror,-Wincompatible-pointer-types-discards-qualifiers
rejects passing dev_addr to non-const parameters and memcpy into it.
Fix by:
- Replacing memcpy(dev->dev_addr, ...) with dev_addr_set()
- Using local buffer + ether_addr_copy for sprdwl_set_mac_addr call
that needs mutable addr (the function modifies it in-place)
- Changing u8 *mac pointer to u8 mac[ETH_ALEN] array in cfg80211.c
where dev_addr was assigned to a non-const pointer
Relates to #9049
From https://lore.kernel.org/all/20251230-ncm-refactor-v1-0-793e347bc7a7@google.com/
To fix slow startup, and the issue where the system fails
to release ncm devices when shutting down after plugging
or unplugging a usb hub, which references a null pointer
This is important for devices without serial ports,
such as the Elixir, because they enable NCM
by default for headless debugging,
making it easy to trigger related bugs.
Signed-off-by: CodeChenL <2540735020@qq.com>
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
- now each arch has its own dt folder, with its own Makefile auto-patched
- simple Makefile autopatching with `add-only: true`
- as example convert 01 null-patch to bare-dt in `dt_32/` (drop from series too)
- this patches u-boot default addresses with the same values used in the boot-genio bootscript
- this enables booting extlinux with large kernels and initrd (eg: `EXT=u-boot-menu`)
- backport fixes from upstream u-boot for
- BTRFS (plus enable BTRFS and BZIP2 support for radxa-nio-12l)
- tested with `CARD_DEVICE=/dev/mmcblk1 ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zstd` (no UFS!)
- also with `EXT=ufs CARD_DEVICE=/dev/sdc ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zstd` (UFS!)
- 4k block size UFS for UMS: fixes block size issue (USB issues unhandled)
- Enable "bind" command for the Mediatek-standard USB Gadget Ethernet
- this way, one doesn't need to cripple UFS to be able to boot from SD
- USB didn't get the same treatment as it's slow and **not working**...
- ...and beyond me to fix; both OTG and Host mode are funky in u-boot...
- ...but seem to work fine in kernel
- IMPORTANT: keep in mind: "SDcard is NOT UFS (4k block)" and don't fall for traps!
- Network note:
- `setenv ethaddr xx:xx:xx:xx:xx:xx` & `saveenv` & `reset`
- required for network booting; mtk doesn't use random/cpu# MAC
- required for stable MAC in kernel (keep IP from changing, etc)
- Use TFA + libdram to obtain and set the actual memory size.
- Overwrite the memory size in the devicetree that is passed to the kernel with the actual size detected.
- All credit to Bartosz Bilas' work for the mt8188/mt8370.
- This doesn't really "use" TF-A/libdram though, those call bl33 with magic arguments which we read here.
- That is implemented by a patch in TF-A for the mt8195 platform.
- With this, bl2 will pass down the DRAM size it gets from libdram
down to bl33 (u-boot proper) via a magic location
- This is a rework of the implementation for another MTK plat (GRINN)
- small hack to get around stupid "From xx" parsing in Armbian patcher
- also: fix attribution in `0023-watchdog-mtk_wdt-Correct-maximum-timeout-from-15-to`
- Switched to the binman-atf-mainline scenario with the same rkbin DDR blob
rk3399_ddr_933MHz_v1.25.bin (TPL blob, as in the old working loader). DRAM init is correct, full
4 GB visible, Linux boots.
- U-Boot and DTS updated to v2026.01-rc5. Added MDIO/PHY node and phy-handle in rk3399-kobol-
helios64.dts, fixing “mdio node is missing”. Disabled i2s2 in the U-Boot DT to avoid rockchip-
i2s ... Could not register PCM.
- boot_targets in U-Boot config shortened (mmc1, scsi0, usb0, pxe, dhcp) to avoid env_buf ... too
small; however, the last built binary still shows the warning (needs rebuild with the shortened
list or enlarging the buffer).
- Boot flow: bootstd scans SD (mmc0) and eMMC (mmc1); SD boot works even without mmc0 in
boot_targets.
- Other changes: defconfig has CONFIG_ROCKCHIP_EXTERNAL_TPL=y to use the external DDR blob.
Boots.
- this prepares everything for the more boards in the family
- which will need `dt/` folder to avoid null-patches
- label & make LEDs useful
- alias mmc0/mmc1 so they match u-boot
- expose i2c3 which is exposed in the 40-pin 27:SCL3 28:SDA3 (blue pins)
- shows up at i2c1 to userspace; why would Collabora alias an undescribed bus?
- fix bootorder (SD -> NVMe -> eMMC); USB disabled as nonworking with mainline still
- use the DT from rockchip64-6.18 so a single source for both u-boot and kernel
- note: the first (and only) RTL8169 used by u-boot is the port closest to board edge
- For 6.18 + 6.19
- mixtile-blade3: add 4-pin header fan at 40c
- mixtile-blade3: add gpu nodes
- mixtile-blade3: add vcc5v0-host-en "usb" pinctrl
- somehow results in 2 working RTL8169's behind the ASM1182e on pcie2x1l0
- which just means the _schematics lie_
- mixtile-blade3: drop rst pinctrl from pcie2x1l0 and pcie2x1l1
- this is me probably being stupid, but also required for working ASM1182e/RTL8169
- Status of this mainline port:
- Initially started by Joshua Riek (2023?)
- I then added some PCIe3x4 stuff, but never got around to finishing it
- Specifically, the 2 FUSB302's are beyond me for now
- One of them _powers_ the board. To use with mainline, power the board some other way with 12V, otherwise kaboom.
- See sre's talk on this issue; Blade3 should be similar to Rock-5b in this aspect.
- A challenge has been the PCI2x1 lanes to the miniPCIe and ASM1182e switch
- Which by themselves seem to work, but the devices behind them (Switch + RTL8169 NICs) do not get powered
- Until one day I tried to describe a (in theory) USB-related power pin, and suddenly both PCIe NICs started working!
- All that said, the board is really not stable with this; end-users are much better off with vendor kernel for now.
- Any and all help is appreciated. Those boards are nice, they've 2 FUSB302, and fancy PCIe Endpoint mode stuff.
- Schematics we have access to are in https://damwold5pt25n.cloudfront.net/blade3/file/Schematic_Blade_3_v1.1.0.pdf
- Those clearly lie.
