Enabling UARTs on RK3566/Radxa Zero 3E

markmcb · Jan 29, 2026

So I'm wanting to use the Zero 3E's UARTs to connect to the consoles of a few nearby devices. I can get to:

Code:

dmesg | grep uart
uart0: <16750 or compatible> mem 0xfe660000-0xfe6600ff irq 66 on ofwbus0
uart0: console (1500000,n,8,1)
uart1: <16750 or compatible> mem 0xfe670000-0xfe6700ff irq 67 on ofwbus0
uart2: <16750 or compatible> mem 0xfe680000-0xfe6800ff irq 68 on ofwbus0
uart3: <16750 or compatible> mem 0xfe690000-0xfe6900ff irq 69 on ofwbus0
uart4: <16750 or compatible> mem 0xfe6d0000-0xfe6d00ff irq 73 on ofwbus0

Which is accomplished with overlays that look like this (UART3):

Code:

/dts-v1/;
/plugin/;

/ {
    compatible = "radxa,zero3", "rockchip,rk3566";

    fragment@0 {
        target = <&uart3>;
        __overlay__ {
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <&uart3m0_xfer>;
        };
    };
};

But for whatever reason, only UART2 (primary) and UART3 work (they map to uart0 and uart1). For example, the overlay for UART4 is:

Code:

/dts-v1/;
/plugin/;

/ {
    compatible = "radxa,zero3", "rockchip,rk3566";

    fragment@0 {
        target = <&uart4>;
        __overlay__ {
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <&uart4m1_xfer>;
        };
    };
};

But neither a loopback test or connecting to another system work. Any known work arounds to enable these additional UARTs? I suspect it's something to do with m0 vs. m1, but I don't know. Curious if others have enable these.

covacat · Jan 30, 2026

well pin function from https://docs.radxa.com/en/zero/zero3/hardware-design/hardware-interface and pin function from dtb are not the same
uart4m1-xfer {
rockchip,pins = <0x03 0x09 0x04 0xb4 0x03 0x0a 0x04 0xb4>;
phandle = <0x221>;
};

they differ for uart2 too (which works)

markmcb · Jan 30, 2026

I noticed this as well. I've tried overriding using 0x02 with no luck. I can't find a definitive source as to whether the functions on that table are a 1:1 correlation with the values on the rockchip,pins line. The difference with uart2, which works, makes me think it's not 1:1.

Phishfry · Jan 30, 2026

Even with PWM stuff I was messing with I had unsolved troubles with overlays on Rock3. rk3399 stuff works fine.

Post in thread 'PWM on Rock3'

Dec 15, 2024

I noticed that the RK3399 Rock4A has a different structure from the decompiled DTB.

Code:

    pwm@ff420000 {

                compatible = "rockchip,rk3399-pwm", "rockchip,rk3288-pwm";
                reg = <0x0 0xff420000 0x0 0x10>;
                #pwm-cells = <0x3>;
                pinctrl-names = "default";
                pinctrl-0 = <0x8a>;
                clocks = <0x7b 0x1e>;
                status = "disabled";
                phandle = <0x108>;

For my overlay I decided to go the "fragment" method for overlay. Still not working.

Code:

/dts-v1/;
/plugin/;
/ {
        fragment@0 {...

covacat · Jan 30, 2026

tried on my board and no go.
couldn't find anything about it working (or not) on linux
there is a bug related to some possible uart clocks in the rk3568_cru.c code but those clocks aren't used so it's not it.

Code:

$ egrep "(MUX|COMP|FRACT).*uart" rk3568_cru.c
    COMP(0, "clk_uart1_src_c", gpll_cpll_usb480m_p, 0, 52, 0, 7, 8, 2),
    MUX(0, "sclk_uart1_sel", sclk_uart1_p, 0, 52, 12, 2),
    FRACT(0, "clk_uart1_frac_frac", "clk_uart1_src", 0, 53),
  
    COMP(0, "clk_uart2_src_c", gpll_cpll_usb480m_p, 0, 54, 0, 7, 8, 2),
    MUX(0, "sclk_uart2_sel", sclk_uart2_p, 0, 52, 12, 2),  /* 52 has to be 54*/
    FRACT(0, "clk_uart2_frac_frac", "clk_uart2_src", 0, 55),
  
    COMP(0, "clk_uart3_src_c", gpll_cpll_usb480m_p, 0, 54, 0, 7, 8, 2),  /* 54 has to be 56 */
    MUX(0, "sclk_uart3_sel", sclk_uart3_p, 0, 56, 12, 2),
    FRACT(0, "clk_uart3_frac_frac", "clk_uart3_src", 0, 57),
  
    COMP(0, "clk_uart4_src_c", gpll_cpll_usb480m_p, 0, 58, 0, 7, 8, 2),
    MUX(0, "sclk_uart4_sel", sclk_uart4_p, 0, 58, 12, 2),
    FRACT(0, "clk_uart4_frac_frac", "clk_uart4_src", 0, 59),
  
    COMP(0, "clk_uart5_src_c", gpll_cpll_usb480m_p, 0, 60, 0, 7, 8, 2),
    MUX(0, "sclk_uart5_sel", sclk_uart5_p, 0, 60, 12, 2),
    FRACT(0, "clk_uart5_frac_frac", "clk_uart5_src", 0, 61),
  
    COMP(0, "clk_uart6_src_c", gpll_cpll_usb480m_p, 0, 62, 0, 7, 8, 2),
    MUX(0, "sclk_uart6_sel", sclk_uart6_p, 0, 62, 12, 2),
    FRACT(0, "clk_uart6_frac_frac", "clk_uart6_src", 0, 63),
  
    COMP(0, "clk_uart7_src_c", gpll_cpll_usb480m_p, 0, 64, 0, 7, 8, 2),
    MUX(0, "sclk_uart7_sel", sclk_uart7_p, 0, 64, 12, 2),
    FRACT(0, "clk_uart7_frac_frac", "clk_uart7_src", 0, 65),
  
    COMP(0, "clk_uart8_src_c", gpll_cpll_usb480m_p, 0, 66, 0, 7, 8, 2),
    MUX(0, "sclk_uart8_sel", sclk_uart8_p, 0, 66, 12, 2),
    FRACT(0, "clk_uart8_frac_frac", "clk_uart8_src", 0, 67),
  
    COMP(0, "clk_uart9_src_c", gpll_cpll_usb480m_p, 0, 68, 0, 7, 8, 2),
    MUX(0, "sclk_uart9_sel", sclk_uart9_p, 0, 68, 12, 2),
    FRACT(0, "clk_uart9_frac_frac", "clk_uart9_src", 0, 69),

anyway the bug relates to uarts 2-3 which work

markmcb · Jan 31, 2026

I installed DietPi (Linux 6.18.7) and using the same overlay works without issue.

From the decompiled rk3566-radxa-zero-3e.dts on FreeBSD (first) and DietPi (second):

Code:

uart4m1-xfer {
    rockchip,pins = <0x3 0x9 0x4 0xbd 0x3 0xa 0x4 0xbd>;
    phandle = <0x1de>;
};

serial@fe680000 {
    compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
    reg = <0x0 0xfe680000 0x0 0x100>;
    interrupts = <0x0 0x78 0x4>;
    clocks = <0x21 0x12b 0x21 0x128>;
    clock-names = "baudclk", "apb_pclk";
    dmas = <0x80 0x8 0x80 0x9>;
    pinctrl-0 = <0x1db>;
    pinctrl-names = "default";
    reg-io-width = <0x4>;
    reg-shift = <0x2>;
    status = "disabled";
    phandle = <0x8f>;
};

Code:

uart4m1-xfer {
    rockchip,pins = <0x03 0x09 0x04 0xb5 0x03 0x0a 0x04 0xb5>;
    phandle = <0x224>;
};

serial@fe680000 {
    compatible = "rockchip,rk3568-uart", "snps,dw-apb-uart";
    reg = <0x00 0xfe680000 0x00 0x100>;
    interrupts = <0x00 0x78 0x04>;
    clocks = <0x0f 0x12b 0x0f 0x128>;
    clock-names = "baudclk", "apb_pclk";
    dmas = <0x26 0x08 0x26 0x09>;
    pinctrl-0 = <0x94>;
    pinctrl-names = "default";
    reg-io-width = <0x04>;
    reg-shift = <0x02>;
    status = "disabled";
    phandle = <0x107>;
};

This is a bit beyond my expertise. Not sure how much of that should be identical, and how much is system specific on compilation. The differences on the pins and clocks line make me wonder.

covacat · Jan 31, 2026

the clocks are the same (0x21 and 0xf are the phandle of the cru node)
the 0xb5 and 0xbd in pinctrl is a phandle of the node that says probably a pull-up
so the problem is not in the dtb is in some driver most likely
its either a clock or a pinctrl problem or so it seems at the first look but
the clocks driver works for tens of devices and also pinctrl works. what i did many times on problems like this when running out of ideas was dumping the regspace with devmem2 and compare
can you dump the clock tree from the linux side ? (here is a script to do it https://forums.freebsd.org/threads/...-that-are-supported.95479/page-14#post-702652)

covacat · Jan 31, 2026

ok, it looks like pinctrl driver might be the problem
i took a look at the linux driver and looks more complex than the freebsd one
ill try to fix it in the following days

Phishfry · Jan 31, 2026

I have some GPS projects I am exploring this weekend. TLL/UART GPS modules on Upboard and Minnowboard.

Sounds like I can try testing on Zero3E. Perhaps second UART for target..

markmcb · Jan 31, 2026

covacat said:
can you dump the clock tree from the linux side ? (here is a script to do it https://forums.freebsd.org/threads/...-that-are-supported.95479/page-14#post-702652)

output attached as clock_tree_dump_radxa_zero-3e_linux_6.18.7.txt

covacat · Feb 2, 2026

here is the fix.
tested on radxa-zero-3e with loopback

i did not use overlays, just edited the dts and rebuild it

markmcb · Feb 2, 2026

Wow, thank you. I see what you mean now, that's a lot of changes. I'll aim to test/confirm this, but I might be slow as I've never tweaked the OS source code before and will need to educate myself how to do that. Loopback working sounds like a solid indication that you've got it resolved.

covacat · Feb 3, 2026

slightly off topic, is your ethernet working well in 1000fdx mode ?

because mine does not. if i force phy mode to rgmii and use std delays it works well.
otherwise tx is crap in 1000fdx but works in 100fdx
i suspect the phy is either rgmii or rgmii_rxid but not rgmii_id as the dtb says
the _id in rgmii_id stands for "internal delay" / phy is responsable to delay data from clock, not the mac
so a rgmii_id prop should not have delays
interesting part is that on the cubie a5 board the allwinner version of eqos had both delays and rgmii-id (and it works properly)

markmcb · Feb 3, 2026

covacat said:
slightly off topic, is your ethernet working well in 1000fdx mode ?

It appears to be a bit slower than 1G, but I haven't noticed any problems in use. iperf3 reports this on a LAN test:

Code:

# iperf3 -c 10.0.1.201
Connecting to host 10.0.1.201, port 5201
[  5] local 10.0.1.206 port 44509 connected to 10.0.1.201 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  45.6 MBytes   382 Mbits/sec    1    373 KBytes
[  5]   1.00-2.00   sec  45.1 MBytes   378 Mbits/sec    1    317 KBytes
[  5]   2.00-3.05   sec  46.9 MBytes   377 Mbits/sec    1    250 KBytes
[  5]   3.05-4.06   sec  45.6 MBytes   377 Mbits/sec    1    182 KBytes
[  5]   4.06-5.00   sec  42.2 MBytes   377 Mbits/sec    0    395 KBytes
[  5]   5.00-6.00   sec  45.0 MBytes   377 Mbits/sec    1    351 KBytes
[  5]   6.00-7.00   sec  45.0 MBytes   377 Mbits/sec    1    320 KBytes
[  5]   7.00-8.00   sec  45.0 MBytes   377 Mbits/sec    1    262 KBytes
[  5]   8.00-9.03   sec  46.0 MBytes   376 Mbits/sec    1    291 KBytes
[  5]   9.03-10.05  sec  46.0 MBytes   377 Mbits/sec    2    324 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.05  sec   452 MBytes   378 Mbits/sec   10            sender
[  5]   0.00-10.06  sec   452 MBytes   377 Mbits/sec                  receiver

The one oddity I noticed is it gets a new MAC address every reboot, but I was able to set one in rc.conf, so at least I could mitigate that.

Code:

$ ifconfig
eqos0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=80008<VLAN_MTU,LINKSTATE>
        ether 02:00:00:00:00:06
        hwaddr f2:00:1e:f9:8c:d8
        inet 10.0.1.206 netmask 0xffffff00 broadcast 10.0.1.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

I do get full speeds when running Debian/DietPi:

Code:

# iperf3 -c 10.0.1.203
Connecting to host 10.0.1.203, port 5201
[  5] local 10.0.1.206 port 50074 connected to 10.0.1.203 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   115 MBytes   962 Mbits/sec    0   1.52 MBytes
[  5]   1.00-2.00   sec   112 MBytes   944 Mbits/sec    0   1.52 MBytes
[  5]   2.00-3.00   sec   112 MBytes   943 Mbits/sec    0   1.52 MBytes
[  5]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0   1.52 MBytes
[  5]   4.00-5.00   sec   112 MBytes   937 Mbits/sec    0   1.52 MBytes
[  5]   5.00-6.00   sec   113 MBytes   947 Mbits/sec    0   1.52 MBytes
[  5]   6.00-7.00   sec   112 MBytes   944 Mbits/sec    0   1.52 MBytes
[  5]   7.00-8.00   sec   112 MBytes   941 Mbits/sec    0   1.52 MBytes
[  5]   8.00-9.00   sec   112 MBytes   938 Mbits/sec    0   1.52 MBytes
[  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec    0   1.52 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   944 Mbits/sec    0            sender
[  5]   0.00-10.01  sec  1.10 GBytes   941 Mbits/sec                  receiver

That said, I force the link to 100fdx as speed isn't a concern and that knocks off about 0.3W of power consumption.

covacat · Feb 3, 2026

looks good. i assume cpu is at 800 mhz (u-boot default). mine does about 5-600 without powerd and 900+ with powerd. (with the pyh in rgmii mode)
with rgmii-id tx is 2Mbs

Enabling UARTs on RK3566/Radxa Zero 3E

markmcb

covacat

markmcb

Phishfry

Post in thread 'PWM on Rock3'

covacat

markmcb

covacat

covacat

Phishfry

markmcb

Attachments

covacat

Attachments

markmcb

covacat

markmcb

covacat