Boardcon_yang

Hi iav, Thanks — taking your offer.
We'll run release v2026.08.22 on a Boardcon SBC3568 (RK3568 SBC, 8 GB, Murata 1XD module for Wi-Fi, eMMC boot) tonight, using the README's standard path: install the kernel .debs, rocket.ko, and DT overlay, then patch in the GFP_DMA32 IOMMU fix from your `kernel-patches/` directory. We'll match your oracle — SHA-256 of the NPU output against the CPU reference for each of the seven layer-probe models plus mobilenet_v1 / v2 / resnet18, with the result captured at 800 MHz via SCMI (your `scmi_rate=800000000` module parameter) and DVFS pinned.
Specifically we want to cover three angles that ODROID-M1 doesn't quite match — eight-GiB usable memory above 4 GiB, the Murata radio coex path that shares an IOMMU group with the NPU on this board, and a long-running thermally-constrained soak at 70°C ambient rather than room temperature. The last one is what we do all the time here, so it falls out for free. Will post back in 48 h with: - the per-model SHA-256s and timings - top-5 match against the CPU reference - one-hour therm soak log (CPU/NPU temperature traces + NPU clock held at 800 MHz via SCMI despite thermal pressure — the same bit-identity check you ran at room temperature) If results hold, would you like us to add the report as a Tested-by line in your v2026.08.22 README, or are you sending that as a separate Mesa branch PR?

Hi nonconfigure,
Short answer: yes, switching to the edge kernel is the right move, but here is what's actually going on so the fix is not mysterious next time.
Why the 6.1 vendor kernel cannot drive the fan. The Rockchip 6.1 BSP ships its own thermal driver tree (`drivers/thermal/rockchip_thermal.c` under `/proc/vendor-thermal` paths) and its own PWM fan driver, but it does not expose the standard `pwm-fan`/`thermal` cooler bindings that the mainline/edge driver expects. So even if a board file declares a fan PWM and a trip point, the vendor kernel will not actually wire them together — the cooler's `cur_state` stays zero, the PWM stays at 0% duty, and the fan looks dead. That's why another 5 V fan on the same header behaves the same.
Why edge kernel 6.19.6 fixes it. Mainline wired `pwm-fan` + `thermal` on the RK3588 about a year ago and the cooling-map bindings have been refined in edge since, including the `map0/map1/map2` node-name collision that defcom5 landed in Armbian 26.8 (PR #10514, merged Monday). After that fix, edge 6.19.6 on RK3588-class SoCs sees the cooler properly, and the trip points declared in the board DT become active.
If the edge kernel doesn't pick it up either, the next thing to check is the DTB. The CM3588 FriendlyElec build carries a vendor DTB which references the 5 V header as plain GPIO, not PWM. You can confirm with `ls /sys/class/thermal/` and `ls /sys/class/pwm/` — if the cooler is missing or the PWM chip is absent, that's the symptom. The fix is to overlay a DTB fragment that exposes pwm0 (or whichever PWM channel is wired to the FAN header on the NAS carrier) and bind it to a cooler with trip points at 60°C / 75°C / 85°C. There are CM3588 community overlays floating around for this if your vendor kernel doesn't have one — let me know and I'll dig up links.
A note from the other side of the same problem. We make an industrial RK3588 SBC (the EM3588) and we ship it fanless by design — the SoC + DRAM + PMIC envelope is rated for –40°C ~ +85°C at industrial temperature grades with a heatsink but no active cooling. In an enclosure at 30°C ambient the junction-to-ambient rise is what matters, not PWM. That's a different design trade from the CM3588 NAS form factor, but the engineering pattern is the same: most RK3588-class devices do not actually need a fan unless they're in a sealed box or running heavy NPU/GPU workloads continuously. If your case is open and the NAS is just acting as a NAS, you may be better off removing the fan entirely and letting the SoC thermally throttle on its own trip points, which the vendor kernel does correctly.