Hi, I hope this isn’t a FAQ. I recently bought a zero3e and I’m running into problems with vanilla kernel;
Is the standard kernel >= 6.12 sufficient to drive the zero 3e as far as USB and Ethernet are concerned?
Despite my various attempts, I can’t get the Ethernet to work properly (it finds the card but makes an error on the PHY), despite the fact that I think I have support for this PHY in the kernel.
"[ 17.290113] rk_gmac-dwmac fe010000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 17.291926] rk_gmac-dwmac fe010000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
"
It’s no better for USB (which sees root hubs well, gives power to devices well, but detects absolutely nothing afterwards).
"root@rock3zeroE ~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
root@rock3zeroE ~#
"
The various distributions I’ve been able to find (armbian, openwrt) work at this level, but they use older kernels heavily patched with overlays. But from what I can see, everything now seems to exist on the latest kernel version, so I was hoping it could work as is.
Most likely, I’ve forgotten some necessary options in the kernel config, but now I can’t see anything obvious, even when studying the .config of openwrt or arbmian (but which are on different versions).
Note that I have to disable the fan53555 driver, otherwise the board crashes on startup. Could this be related?
Radxa Zero 3W/E, being a SoC, requires a OS with dedicated drivers for all the hardware found inside the SoC an on the PCB.
No wonder the various distributions come with a lot of overlays.
Hello and thank you for your reply. I have to clarify, the zero3e works perfectly with pre-existing images (armbian, openwrt, debian, ubuntu… - Kudos to all who ported).
I’m looking to port personal code that works with other SBCs (on A20 in armhf and RIsc-V). The eco system is based on Guix, which supports a good number of SBCs, but not yet zero 3E.
My aim is therefore to write support for u-boot and the kernel. u-boot 2025.01 seems functional (with binaries bl31.elf + rk3566_ddr_1056MHz). The rest of the eco-system is already working.
The 6.12 and 6.13 kernels start up, but with the problems mentioned above.
My question was about the current state of development of the kernel and uboot in their “mainline” versions as far as the zero3E is concerned: is it realistic to expect the Ethernet and USB ports to work without using additional overlays or patches, as the changelogs (both on the kernel and uboot sides) seem to indicate that this should be possible.
(nb: the lack of hdmi support is not a problem, as these are servers without displays).
I have the same problem with my Zero3E; could you explain to a noob like me how you solved the problem? I think I’ll find the way to download, compile and copy u-boot on my SD card, but have no clue how and where to replace the USB firmware.
Hello and sorry for the late reply, I hadn’t touched this all week.
This is not USB firmware. As explained above, in my particular case, when booting the sbc, the “mainline” kernel doesn’t seem to be able to completely initialize certain peripherals. I eventually noticed that, depending on the u-boot version used, some devices seem to be in a state that seems to be better suited to what this kernel expects.
Using the latest u-boot 2025.04 together with bl31, whose links I’ve given above, allows me to get a more or less functional system (cpufreq doesn’t seem to be ok yet). As I’m by no means a specialist in these machines, it’s likely that armbian kernels+uboot (or the ubuntu distribution mentioned at the start of this thread) are functionally much more complete and efficient than what I’ve ended up with. But all in all, I wanted a system based on as few proprietary sources as possible, and this is relatively satisfactory and stable as it stands.
I’m currently cleaning up the necessary kernel options, testing on kernel 6.14 and finalizing a clean definition for Guix, which I’ll put on a gitlab as soon as possible, so that everyone can easily reproduce and generate images from it (and possibly improve!).
Armbian currently uses arm-trusted-firmware v2.13, which is May 22, so after your post.
But unfortunately this has not entirely fixed USB3 for me: The port fails to work with an unpowered hub that shows no issues at all with Radxa’s own 6.1 images.
(That, and with Armbian on 6.1-radxa, for whatever reason the port is limited to USB2 if the USB-C cable is entered “the right way.” Turned by 180 degrees, it returns to USB3/5G speeds.)
Could you please take a look whether I missed anything? Thanks!
Hello, I’ve been away from the keyboard for the last few months, but I need to restart this project in the next few days. I’m going to tidy up my Guix recipes so that everyone can move forward.
During my last tests several months ago, USB 3 worked pretty well in some respects: I use a USB-C/5-port SATA adapter for RAID. BUT I can confirm that unfortunately, anything behind a hub does not work,[Edited, see below]
Another issue is that there’s nothing I can do to get cpufreq to work, which is unfortunate, since the SBC is stuck at low speed.
I’ll update everything at the beginning of the week—the kernel to 6.16 or 6.17rc, u-boot, and the trusted firmware—to see if that changes anything, hoping to be able to devote more time to it this time around.
Hello @twwm, I said something wrong in previous message : it works well ( I must have messed up during my previous tests…)
/local/admin# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 002 Device 003: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 05e3:0625 Genesys Logic, Inc. USB3.2 Hub
Bus 003 Device 003: ID 152d:a583 JMicron Technology Corp. / JMicron USA Technology Corp. External
Bus 003 Device 004: ID 152d:a580 JMicron Technology Corp. / JMicron USA Technology Corp. USB Mass Storage
3 devices are behind a hub (usb-c to 5xSata, usb-c to nvme, logitech dongle), and speed is good.
Rotating 180° usb-c Indeed switches between USB2 and USB3
/local/admin# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 002 Device 005: ID 152d:a583 JMicron Technology Corp. / JMicron USA Technology Corp. External
Bus 002 Device 006: ID 152d:a580 JMicron Technology Corp. / JMicron USA Technology Corp. USB Mass Storage
Bus 002 Device 007: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
attached current config for 6.15.10 in zip format.
The configuration is very large, there are far too many useless options in it, but maybe you’ll find what’s missing in your own configuration.
Took time to remake tests with newer u-boot (2025.10-rc3), kernel (6.16.4) and still no luck with cpufreq.
Unfortunately, there is likely a small piece missing somewhere in the kernel or dts mainlines, because the exact same configuration works perfectly on a rock5b+ (with just this same uboot configured for rockchip 5b+).
Aha, it wasn’t so hard to solve. The default DTB is wired up to use scmi for the cpu clock, so you need that driver and the firmware. Also I was missing the rk817 driver, so that caused wifi to fail to load. Essentially check you have all needed SCMI drivers enabled and you should get cpufreq running
@@ -654,7 +654,7 @@ CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
CONFIG_CPUFREQ_DT=m
# CONFIG_CPUFREQ_VIRT is not set
CONFIG_CPUFREQ_DT_PLATDEV=y
-# CONFIG_ARM_SCMI_CPUFREQ is not set
+CONFIG_ARM_SCMI_CPUFREQ=y
# end of CPU Frequency scaling
# end of CPU Power Management
@@ -5625,8 +5625,8 @@ CONFIG_COMMON_CLK=y
# CONFIG_LMK04832 is not set
# CONFIG_COMMON_CLK_MAX9485 is not set
-# CONFIG_COMMON_CLK_RK808 is not set
-# CONFIG_COMMON_CLK_SCMI is not set
+CONFIG_COMMON_CLK_RK808=y
+CONFIG_COMMON_CLK_SCMI=y
# CONFIG_COMMON_CLK_SCPI is not set
# CONFIG_COMMON_CLK_SI5341 is not set
# CONFIG_COMMON_CLK_SI5351 is not set
Hi HiFly,
It’s really good news to hear that someone has managed to do it
I do have these options in the kernel (see config.gz above), but initialization is causing problems (I ignored this error message, as I didn’t think it was relevant).
Aha, so I created my u-boot I used the 2x binary blobs from Radxa, One is the secure arm stuff and the other is the memory init. You can replace the secure arm stuff with an opensource one, but I didn’t get that far, so possibly the radxa one has extra options compiled?
Broadly ensure that you have all the relevant SCMI drivers in the kernel as well I guess?
Hi Hifly,
Hello, and thank you for the clarification. Since all the SCMI drivers are in the kernel, the difference seems to lie in BL31, which does not come from the same sources. I switched to open source because it worked better for me for USB and Ethernet.
I guess it’s time to try again . There may be some adjustments to be made in the compilation of the ARM trusted firmware.
The culprit was indeed the BL31 in its open source version.
Using rk3568_bl31_v1.44.elf from the Rockchip repository, cpufreq works as it should (and I no longer have the USB and Ethernet issues I had when I started this, see first messages in this thread…).
With versions 2.12 and 2.16 of the ARM trusted firmware, the BL31 produced for rk3566 causes cpufreq issues, whereas generating it for its big brother rk3588 works perfectly (rockchip 5b+). Something must be missing in the open-source version for this chipset.
Anyway, thanks for pointing me in the right direction.
This time, I think we can truly declare this thread resolved.
. There may be some adjustments to be made in the compilation of the ARM trusted firmware.