Gahing's Space

TL;DR

ArmSoM’s sales team emailed unprompted after noticing the CM5-IO listed as hardware-verified in the edk2-rk3576 README — kind words about both the UEFI port and the NPU mainlining work, and one real question: is the CM5 device tree headed for mainline Linux too, or just riding along with the UEFI path?

It’s going straight into mainline. rk3576-armsom-cm5.dtsi (module) and rk3576-armsom-cm5-io.dts (carrier) are on the linux-rockchip list at v4, split the same way as ArmSoM’s own Sige5 — already in mainline as rk3576-armsom-sige5.dts since v7.2-rc3 — which I used as the direct reference.

The binding patch carries Krzysztof Kozlowski’s Acked-by, and the DTS keeps ArmSoM’s copyright line.

Hardware-verified on the CM5-IO: GMAC0 with the on-module YT8531 linking at 1000 Mbit/s, RK806, HYM8563, eMMC, microSD, the USB3 hub, and PCIe all probe.

A small side patch too: a dwmac-rk fix on netdev that ungates the 25 MHz reference the crystal-less YT8531 needs in RGMII mode.

Posted 2026-06-20Updated 2026-08-18Firmware & Secure Boot18 minutes read (About 2752 words)

RK3576 UEFI: Teaching EDK2 to Drive HDMI, USB, and eMMC

TL;DR

EDK2 boots a real UEFI environment on the RK3576 — swapping out U-Boot proper for EDK2 after BL31, verified on two boards (Radxa ROCK 4D over SPI, ArmSoM CM5-IO over SD).
HDMI’s worst bug was the debugging itself: reading overlay registers back after enable — read-only, no writes — silently perturbed VOP2 and killed the picture; the one real fix underneath all the phantom bugs was a register-write-ordering issue.
USB needed two DWC3 xHCI workarounds: skip a structurally-redundant EvaluateContext on SuperSpeed, and mark the hub slot-context flag before the interrupt endpoint arms, or the onboard hub never enumerates.
eMMC was simply held in hardware reset — EMMC_RST_N defaults to 0, and RK3588 boards never notice because SPL boots from eMMC and clears it in passing; RK3576 booting SD/SPI never touches that bit at all.
Ethernet’s PHY part number was copy-pasted wrong everywhere — four independent sources call it an RTL8211F; the schematic says MotorComm YT8531C. It works either way (both are generic Clause-22 PHYs), until you need PHY-specific tuning.
Two firmware/OS handoff bugs lived below any single peripheral: a coincidental MZ byte pair in unrelated memory crashed the OS-loader scan, and an unpopulated RAM bank register read as all-zero decoded into a phantom 256 MB.

TL;DR

TL;DR

Tags