ArmSoM Noticed the Work, and the CM5 Device Tree Hits v4

Backstory first, since it’s short: back in May I asked ArmSoM for a CM5 + CM5-IO sample to get a second RK3576 board under the UEFI port — checking peripheral bring-up (HDMI, USB, eMMC, WiFi/BT) against a board design different from the one I’d been using, with the intent of upstreaming CM5 platform support to edk2. They sent a CM5 Basic + CM5-IO, credited in the edk2-rk3576 README ever since.

This week ArmSoM’s sales team emailed again, unprompted — they’d noticed that credit and wanted to say the UEFI work, and separately the NPU mainlining effort, had been worth following. The one actual question in the email: is the CM5 device tree headed for mainline Linux as well, or is that something that follows the UEFI path for now?

It’s going straight into mainline. The series adding rk3576-armsom-cm5.dtsi (the module) and rk3576-armsom-cm5-io.dts (the carrier) is on the linux-rockchip list at v4 — split the same way ArmSoM already did for their Sige5 board, whose device tree (rk3576-armsom-sige5.dts) landed in mainline at v7.2-rc3. That was the direct reference for what a merged RK3576 platform file is expected to look like, since ArmSoM had already been through review for a sibling board. The binding patch carries Krzysztof Kozlowski’s Acked-by, and the DTS keeps ArmSoM’s copyright line.

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

One separate small patch came out of this too: a dwmac-rk fix on netdev that ungates the 25 MHz reference clock the crystal-less YT8531 needs in RGMII mode — without it the PHY doesn’t get a clean reference and link training is unreliable.

No conclusions yet — the series is still at v4 and review is ongoing. Just noting the timeline: hardware in hand since May, work upstreamed since, and a vendor noticing enough to ask about it unprompted, which is a nice thing to have happen.