usual user

WEBGPU works out-of-the-box with a Mali GPU.

Can't confirm your observation on Radxa ROCK 5 ITX, but my kernel is build with # CONFIG_SCHED_CLUSTER is not set

My system is fully operational in less than 30 seconds, see boot-analyze-rock-5-itx.pdffor reference. [ 19.098516] r8169 0003:31:00.0: enabling device (0000 -> 0003) [ 19.326928] r8169 0003:31:00.0 eth0: RTL8125B, 00:e0:4c:68:03:fd, XID 641, IRQ 165 [ 19.326952] r8169 0003:31:00.0 eth0: jumbo features [frames: 16362 bytes, tx checksumming: ko] [ 19.329639] r8169 0004:41:00.0: enabling device (0000 -> 0003) [ 19.490203] r8169 0004:41:00.0 eth1: RTL8125B, 00:e0:4c:68:03:fe, XID 641, IRQ 166 [ 19.490217] r8169 0004:41:00.0 eth1: jumbo features [frames: 16362 bytes, tx checksumming: ko] [ 20.157651] r8169 0004:41:00.0 enP4p65s0: renamed from eth1 [ 20.160331] r8169 0003:31:00.0 enP3p49s0: renamed from eth0 [ 22.999249] Realtek Internal NBASE-T PHY r8169-3-3100:00: attached PHY driver (mii_bus:phy_addr=r8169-3-3100:00, irq=MAC) [ 23.156625] r8169 0003:31:00.0 enP3p49s0: Link is Down [ 23.184258] Realtek Internal NBASE-T PHY r8169-4-4100:00: attached PHY driver (mii_bus:phy_addr=r8169-4-4100:00, irq=MAC) [ 23.307706] r8169 0004:41:00.0 enP4p65s0: Link is Down [ 26.299648] r8169 0003:31:00.0 enP3p49s0: Link is Up - 2.5Gbps/Full - flow control rx/tx

For me the thermal subsystem of the kernel works flawless out-of-the-box, no user-space involved.

Because that's what Petitboot uses for its rootfs, and that's why it's not enabled in my build either since there's no Petitboot payload. Just pure U-Boot payload. I’m running this system on all my devices: My latest system resides on a USB-connected selfpowered storage device, so I can use it with all my devices since a USB port is basically standard nowadays. No hassle with proprietary eMMC module connectors or a potentially unavailable NVME slot. Speed-wise, it's on par with an eMMC in any case, but the GB/EUR ratio clearly speaks in favor of an NVME. Since the necessary firmware for system startup is always located on a storage device supported by the MASKROM code (SPI flash preferred, but eMMC or microSD is on par), the operating system can be used unmodified in the same way on all devices. Just plug-in and reboot to run it instead of its usual operating system. By the way, the screenshot was taken on my only remaining device in my collection with an Amlogic SoC. As you can see, I just updated the firmware to the state of my last build. It uses the same U-Boot binary payload as the HC4, C4 and N2, just the closed source bloobs and the DTB differs in the firmware compose. U-Boot detects at runtime which of the four devices it's running on and acts accordingly.

That's the advantage when you use a device that doesn't have a PMIC and only goes into deep sleep mode for Off Mode. This is only supported by the proprietary, closed-source manufacturer firmware, for which of course no publicly available API description exists. Mainline support will therefore most likely not become available. So it basically just leaves reverse engineering and an out-of-tree implementation. Good luck.

Your previous post reminded me that the board supplier changed the BOM of the ODROID-N2+ by using a different SPI flash vendor. He hacked the support for it into his legacy firmware build without making any further note about it. It took some effort of reverse engineering to figure that out. Mainline hasn't picked up this additional driver activation to this day, but I still keep it in my builds anyway. In my latest build for the ODROID-HC4, I also included this driver to see if they might have gone about it in the same way. But your confirmation shows that this is probably not the case. Since I don't have an ODROId-HC4 with the behavior you described on hand, I can't analyze any further what the cause of it is. These days, I also mostly avoid devices with Amlogic SoCs because of their strict closed-source policy and lack of mainline support. And the board manufacturer isn't much more helpful on this point either. Devices powered by Rockchip are much more appealing objects. So you have to help yourself if you want to find a solution.

Just a shot in the dark, does this build work better?

As long as you do not provide proper serial console logs, no one can tell what is going on. I can't help you in this situation any further, and you have to find a solution for yourself.

Nope, my build is based on current mainline and even build on target (aarch64). I.e. no cross-compiling involved. Oh, by the way, in my build bootstd scans any attached storage for a valid bootflow and uses the first found one. The used hardware interface dosen't matter and even network is valid.

Usually I do that via the U-Boot console, since I build my firmware with SPI command support for devices with SPI flash. With an added convenience command, it's just a "==> run mmc-fw-to-sf" to transfer firmware currently running from microSD. So everything is self-contained, no external components involved.

You made me curious, so I rebooted for the first time after my previous report to activate my current versions. I' m now at kernel 7.0.0-0.rc1.15.fc45.aarch64 and U-Boot 2026.07-rc1 (May 22 2026 - 00:00:00 +0000). No regressions can be observed and it works as fast as before.

The first iteration of mainline kernel driver support has just been posted. So a kernel build with this patch set applied should give a playground for initial experiments.

It happened a few days ago that I rebuilt my complete firmware package to try something with another device. An HC4 firmware binary also automatically falls out in this process. If you like, you can put it on a microSD card (dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-device-to-be-used}), place the prepared microSD card in your HC4 and start it with the boot button pressed. Check whether it meets your expectations, and if all tests are successful, you can transfer it to the SPI flash.

The one from my firmware build.

Since I haven't restarted the M1 for some time, I am currently still at: # uptime 12:56:23 up 115 days, 1:51, 5 users, load average: 1.76, 1.26, 0.92 # uname -a Linux micro-015 6.18.0-65.fc44.aarch64 #1 SMP PREEMPT_DYNAMIC Sun Dec 7 20:40:45 CET 2025 aarch64 GNU/Linux I still get: So nothing to complain about.

According to the circuit diagram, the reset button is connected to the hardware reset lines, so nothing can prevent forcing the reset state.

At least that explains the result of the nvme scan command. Now it remains to find out why this is the case, but since improvements are still pending for PCIe support even in the mainline kernel, the question arises whether all of this has already been migrated into the firmware.

u-boot-rockchip-spi.bin is a firmware. Out of pure curiosity, what is the result of 'pci enum' on the firmware console?

IMHO, OP wants to boot OS from NVME while the firmware is stored in the SPI flash, but he is using firmware in which the necessary support is not enabled.

I usually use Falkon in a Plasma environment with Wayland backend.

I haven't looked at this use case for a very long time. I can no longer remember since when it has worked out-of-the-box for me. Since decoder support has been part of the GStreamer framework for a very long time, hardware-supported video decoding works for all browsers that use this framework with the standard packages of the distribution of my choice. When v4lrequest support was still implemented with the out-of-tree patches using the stateful method, it also worked with Firefox out-of-the-box. Just an accordingly patched FFmpeg framework was required. This is likely no longer going to work with the current patches for the FFmpeg framework and requires an additional implementation in Firefox. I suspect, however, that this will only happen after the official inclusion of v4lrequest support in the FFmpeg framework, as is also the case with MPV. To what extent patches for Firefox are already available is unknown to me. For the distribution of my choice, I have in any case rebuilt the FFmpeg and MPV packages with the corresponding patches. I have to confess that I usually use Firefox and the video decoding works flawlessly for my use cases. However, I cannot say whether this is actually hardware-accelerated, because the SBCs I use with a graphical Desktop are powerful enough to function sufficiently even with only software decoding. I'm just taking the lazy way here and waiting for it to end up in Manline. For SBCs that need hardware acceleration, I simply use a browser that uses the GStreamer framework.

From an OS's point of view, only a Mesa build with Teflon and Rocket driver support is needed (available since Mesa 25.3). Inferences can then be executed with ai-edge-litert. I have been experimenting with this for some time on all my devices equipped with Rockchip RK3588/RK3588s.

I am currently at 7.0.0-rc1. I can upload my jump-start image so you can check if my kernel build works with your device. If you like what you see, it is only a 'prepare-jump-start ${target-mount-point}' away to install the kernel package alongside your existing system. I know about it, but since it is just another not mainline solution with another dependency mess, I am not particularly interested.