Radxa Zero 3W — Unlock SD Card UHS-I SDR104 on DietPi

[jcmtang]

For a few weeks I just accepted the poor r/w performance the SD card on this SBC, but then after seeing some Youtube videos with double the performance on some other distro, I had to start investigating. With the help of Claude Sonnet 4.6, I got document generated. I ran the script for both the generic micro SD card and on a Samsung EVO micro SD card and got better performance.

Radxa Zero 3W — Unlock SD Card UHS-I SDR104 on DietPi

Background

By default, the Radxa Zero 3W ships with the SD card slot locked to SD High-Speed mode
(50 MHz, ~21 MB/s). The hardware is fully capable of UHS-I SDR104 (150 MHz), but Radxa's
device tree omits the required flags. This guide unlocks it via a custom device tree overlay.

What this achieves

	Before	After
Clock	50 MHz	150 MHz
Mode	SD High-Speed	UHS-I SDR104
Signal Voltage	3.3V	1.8V
Read speed (hdparm)	~21 MB/s	~66 MB/s
Sequential read	~21 MB/s	~56 MB/s
Sequential write	~18 MB/s	~25 MB/s

Tested on DietPi with kernel 6.18.16-current-rockchip64.

---

How it works

The RK3566 SoC's SD slot (mmc@fe2b0000) has a vqmmc-supply pointing to LDO_REG5
(vccio_sd) on the RK805 PMIC — a switchable regulator supporting both 1.8V and 3.3V.
The kernel just needs to be told UHS-I is allowed via the sd-uhs-sdr104 device tree flag.
The overlay adds this flag at boot time without modifying any system files permanently.

---

One-shot script

Copy and paste the entire block below into your terminal as root or with sudo:

#!/bin/bash
set -e
 
echo "=== Radxa Zero 3W SD UHS-I unlock ==="
 
# Step 1: Install device-tree-compiler if missing
if ! command -v dtc &>/dev/null; then
    echo "[+] Installing device-tree-compiler..."
    sudo apt install -y device-tree-compiler
fi
 
# Step 2: Write the overlay source
echo "[+] Writing DTS overlay..."
cat << 'EOF' > /tmp/rk3566-sd-uhs.dts
/dts-v1/;
/plugin/;
 
/ {
    fragment@0 {
        target-path = "/mmc@fe2b0000";
        __overlay__ {
            sd-uhs-sdr50;
            sd-uhs-sdr104;
        };
    };
};
EOF
 
# Step 3: Compile the overlay
echo "[+] Compiling overlay..."
dtc -@ -I dts -O dtb -o /tmp/rk3566-sd-uhs.dtbo /tmp/rk3566-sd-uhs.dts
 
# Step 4: Install overlay to system overlay directory
echo "[+] Installing overlay to /boot/dtb/rockchip/overlay/..."
sudo cp /tmp/rk3566-sd-uhs.dtbo /boot/dtb/rockchip/overlay/radxa-zero3-sd-uhs.dtbo
 
# Step 5: Enable overlay in dietpiEnv.txt
echo "[+] Enabling overlay in /boot/dietpiEnv.txt..."
if grep -q "^overlays=" /boot/dietpiEnv.txt; then
    if ! grep -q "sd-uhs" /boot/dietpiEnv.txt; then
        sudo sed -i 's/^overlays=\(.*\)/overlays=\1 sd-uhs/' /boot/dietpiEnv.txt
        sudo sed -i 's/^overlays= /overlays=/' /boot/dietpiEnv.txt
    else
        echo "[=] sd-uhs already listed in overlays, skipping."
    fi
else
    echo "overlays=sd-uhs" | sudo tee -a /boot/dietpiEnv.txt
fi
 
echo ""
echo "=== Done! dietpiEnv.txt now reads: ==="
grep "^overlays=" /boot/dietpiEnv.txt
echo ""
echo "[!] Reboot now to apply: sudo reboot"
echo "    After reboot, verify with:"
echo "    sudo cat /sys/kernel/debug/mmc1/ios"
echo "    Look for: timing spec: sd uhs SDR104 and signal voltage: 1.80 V"

---

Verify after reboot

# Should show: timing spec: sd uhs SDR104 and signal voltage: 1.80 V
sudo cat /sys/kernel/debug/mmc1/ios
 
# Benchmark
sudo hdparm -t /dev/mmcblk1
sudo dietpi-benchmark

---

Reverting

If anything goes wrong, remove the SD card, mount it on another Linux machine, and either:

• Delete /boot/dtb/rockchip/overlay/radxa-zero3-sd-uhs.dtbo, or
• Edit /boot/dietpiEnv.txt and change overlays=sd-uhs back to overlays=

Then reboot normally.

---

Notes

• Tested on: Radxa Zero 3W, DietPi, kernel 6.18.16-current-rockchip64
• PMIC: RK805 on I2C (i2c@fdd40000), LDO_REG5 = vccio_sd (1.8V–3.3V switchable)
• SD controller: dwmmc_rockchip at fe2b0000
• The overlay is non-destructive — it is applied at boot and does not modify your DTB
• The overlay sits alongside official Armbian/DietPi overlays in the system overlay directory
• A kernel update may overwrite the overlay directory — re-run this script if speeds regress after apt upgrade
• Write speed improvement is modest (~25 MB/s) due to flash controller overhead; reads benefit most

[MichaIng]

Thanks!

I see, higher speeds are enabled for the onboard eMMC chip, and not sure what the other one (sdmmc1=mmc2) is, maybe a controller exposed via GPIO, or something else, but it is not the SD card: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3w.dts#n55

The SD card is sdmmc0=mmc1 here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero-3.dtsi#n474
No highspeed enabled at all 🤔. The same is true for the Radxa ZERO 3E which I have here. I do not see this being discussed on the Linux mailing list either: https://lore.kernel.org/all/20240521202810.1225636-1-jonas@kwiboo.se/
@Kwiboo hope its fine to ping you here, any reason why highspeed is not enabled for the SD card slot, like stability concerns or so?

I'll at least test it on Radxa ZERO 3E, using a UHS and an older non-UHS SD card. We might just patch it into our kernel, but better to apply upstream if there was no particular reason to limit speed.

@jcmtang
Just some minor points, in case it turns out to cause issues in some cases, and it remains as optional overlay only. Use modern/simpler syntax:

/dts-v1/;
/plugin/;

&sdmmc0 {
	sd-uhs-sdr50;
	sd-uhs-sdr104;
};

But more importantly: add the overlay as /boot/overlay-user/*.dtbo and to user_overlays= in /boot/dietpiEnv.txt. No prefix needed, use the full filename (except .dtbo extension). That way, the overlay remains effective after kernel upgrades, and does not prevent /boot/dtb-6.18.16-current-rockchip64 from being removed, leaving that dir as cruft behind.

[Kwiboo]

any reason why highspeed is not enabled for the SD card slot, like stability concerns or so?

I do not remember exactly why I left it out from mainline, but likely due to stability issues and/or sd-card not reliably being detected in some boot/reboot scenarios.

It is possible that such issue can be triggered due to IO voltage domain vs sdmmc driver probing order, or possible an issue that my old mmc: core: set initial signal voltage on power off patch, that currently is included in multiple arm/sbc focused distros, help prevent but likely affect plain mainline.

[MichaIng]

Thanks, at least we should test it carefully. Armbian has your patch included: https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.18/general-fix-mmc-signal-voltage-before-reboot.patch
From the mailing list, it seems the mmc_delay() is not actually needed?

Probably best to create an overlay first, and enable it by default on our new images. So we do not break any running systems, but have this tested more widely. If for a longer time, no one reports failing boot for our Radxa ZERO 3 images, we can apply it permanently in the kernel.

[jcmtang]

Thank you! Also, somewhat related but different topic:

The official OPP table for /boot/dtb/rockchip/rk3566-radxa-zero-3w.dtb has

Frequency	Voltage (typ)	Voltage (max)	Status
408 MHz	850 mV	1150 mV	stock
600 MHz	850 mV	1150 mV	stock
816 MHz	850 mV	1150 mV	stock
1104 MHz	900 mV	1150 mV	stock
1416 MHz	1025 mV	1150 mV	stock max

But the official Radxa documentation indicates "up to 1.6GHz", but it's missing from the OPP.
The last one i see is

        opp-1416000000 {
            opp-hz = <0x00 0x54667200>;
            opp-microvolt = <0xfa3e8 0xfa3e8 0x118c30>;
            clock-latency-ns = <0x9c40>;
        };

I added

        opp-1608000000 {
            opp-hz = /bits/ 64 <1608000000>;
            opp-microvolt = <1100000 1100000 1150000>;
            clock-latency-ns = <40000>;
	};

Were there thermal throttling or power management issues causing stability concerns? I'm have passive heatsinks on my SBC and sit comfortably around 55C (when fully saturated) and get 20% better CPU performance and about 25% faster RAM read/write based of the dietpi-benchmark when 1608 MHz (1100 -1150 mV) is added.

Edit:
Hmm there seems to be some odd interaction that affects negatively affects wifi speed

Default 1.4GHz

   Speedtest by Ookla

      Server: Rogers Wireless - Toronto, ON (id: 46759)
         ISP: Rogers Cable
Idle Latency:     7.46 ms   (jitter: 1.93ms, low: 6.20ms, high: 9.61ms)
    Download:   180.58 Mbps (data used: 218.2 MB)                                                   
                 49.06 ms   (jitter: 10.87ms, low: 10.46ms, high: 125.24ms)
      Upload:   224.38 Mbps (data used: 274.9 MB)                                                   
                 77.38 ms   (jitter: 24.82ms, low: 14.75ms, high: 352.43ms)
 Packet Loss:     0.0%

With 1.6GHz

   Speedtest by Ookla

      Server: Rogers Wireless - Toronto, ON (id: 46759)
         ISP: Rogers Cable
Idle Latency:     7.58 ms   (jitter: 2.10ms, low: 5.31ms, high: 9.43ms)
    Download:   103.95 Mbps (data used: 78.8 MB)                                                   
                 62.81 ms   (jitter: 14.49ms, low: 13.87ms, high: 166.62ms)
      Upload:   155.70 Mbps (data used: 194.1 MB)                                                   
                100.90 ms   (jitter: 28.71ms, low: 14.58ms, high: 342.12ms)
 Packet Loss:     0.0%

not sure if there would be any effect on the zero 3E model.

[MichaIng]

Yes, mainline Linux limits it to 1.4 GHz for RK3566T: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566t.dtsi
The commit message mentions a discrepancy between vendor kernel source and SBC specifications in these regards, and uses the conservative value until clarification: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=e4832d1

The vendor kernel source indicates that the maximum frequency for the CPU cores
is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Until
that discrepancy is resolved somehow, let's take the safe approach and use
the lower maximum frequency for the CPU cores.

But hmm, as far as I can see, the Radxa Rockchip vendor kernel uses 1.8 GHz, at least I cannot see any removal/override of the default RK356x OPP table throughout the dts and dtsi: https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr5.1/arch/arm64/boot/dts/rockchip/rk3566-radxa-zero3.dtsi
Generally, the vendor kernel does not seem to differentiate between RK3566 and RK3566T.

If someone finds time to test Radxa's own Debian images, would be interesting to verify that they do run in 1.8 GHz, or otherwise, where/how it is limited (if not at device tree level): https://github.com/radxa-build/radxa-zero3/releases

Hmm there seems to be some odd interaction that affects negatively affects wifi speed

Ehm, please verify this with a few more reboots and back/forth tests. That seems basically impossible. Also can you check e.g. via cpu command that the 1.6 GHz is indeed available?

[jcmtang]

I have the CPU frequency shown in htop in the screenshots below. I'm on a 5GHz wifi connection. I'm guessing it's poorly designed power management isolation or some noise caused by this higher clock, or some EMI issue at this frequency. I tested a few times and performed reboots between tests and it's consistently the same. The device is right next to my router and the signal strength is about -34 dBm (according to dietpi-config).

Also not sure why the reported latency is atrocious and sporadic (as seen in my previous comment). I just assumed some bad hardware design or something.

 ─────────────────────────────────────────────────────
 DietPi CPU Info
 Use dietpi-config to change CPU / performance options
 ─────────────────────────────────────────────────────
 Architecture |     aarch64
 Temperature  |     39 °C / 102 °F : Cool runnings
 Governor     |     schedutil

                 Current Freq    Min Freq   Max Freq
 CPU0         |      1608 MHz      408 MHz    1608 MHz
 CPU1         |      1608 MHz      408 MHz    1608 MHz
 CPU2         |      1608 MHz      408 MHz    1608 MHz
 CPU3         |      1608 MHz      408 MHz    1608 MHz

1.6 GHz

1.4 GHz

If you were curious, below was my performance gain:

Metric	Stock 1416 MHz	With 1608 MHz overlay	Change
CPU benchmark	14.46 s	11.59 s	+20%
RootFS write	23 MiB/s	23 MiB/s	-
RootFS read	56 MiB/s	56 MiB/s	-
RAM write	324 MiB/s	416 MiB/s	+28%
RAM read	888 MiB/s	1097 MiB/s	+24%

I'll probably stick with the 1.4 GHz stock configuration since the network performance hit is a bad trade-off for me.

Let me know if you want me to perform any more investigation or testing. Thanks for looking into the issues!

[MichaIng]

Is the WiFi speed as well affected if you limit it via CPUFreq only, e.g. dietpi-config > Performance Options > CPU Frequency Limits? Similarly, it could be tested whether changing the CPU governor has some effect, like if the frequency/voltage changes are causing this, rather than the higher frequency alone.

Unlikely, but I can at least try to replicate it with a USB WiFi adapter on the Radxa ZERO 3E 😅.

[jcmtang]

Ah very interesting. You solved my problem 😃. I left CPU Governor at schedutil and just played around with the min and frequency and pegged them to the same value so that there was no switching during the tests. Everything was looking good until I hit the 1512 MHz. I failed to mentioned earlier that I had added

			opp-1512000000 {
				opp-hz = /bits/ 64 <1512000000>;
				opp-microvolt = <1062500 1062500 1150000>;
				clock-latency-ns = <40000>;
			};

At this frequency is where I had constantly poor networking performance. I re-tested with the full range 408-1608, and saw poor performance again (as expected). Then removed the opp-1512000000 in my overlay and re-tested and performance is back to normal! Thanks!

I could add 1.8 GHz and test (let me know if I should), but was concerned about whether the power management was designed to support this since Radxa's official tech specs says up to 1.6GHz.

Would this be patched into the kernel to add this additional frequency? I'm currently using a user_overlay approach that you suggested earlier.

[MichaIng]

😄 you are welcome. Yeah 1.5 GHz is not present in the RK3566 OPP table either: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566.dtsi

I could add 1.8 GHz and test (let me know if I should), but was concerned about whether the power management was designed to support this since Radxa's official tech specs says up to 1.6GHz.

Probably safer to test Radxa's image first. But on the other hand, worst that can happen is that it fails to boot, or crashes at some point, or runs hot until thermal throttling kicks in.

Would this be patched into the kernel to add this additional frequency? I'm currently using a user_overlay approach that you suggested earlier.

I'll first test everything on my Radxa ZERO 3, then add an overlay to the kernel package, enabled by default for new images. Keep the user overlay for now, I'll leave a comment here if/when there is an update our end that makes the user overlay obsolete.

[jcmtang]

I'm not to keen on testing Radxa's image. DietPi is too good 😄. Thanks for your hard work!

I went ahead and tested 1.8 GHz

			opp-1608000000 {
				opp-hz = /bits/ 64 <1608000000>;
				opp-microvolt = <1100000 1100000 1150000>;
				clock-latency-ns = <40000>;
			};
			opp-1800000000 {
				opp-hz = /bits/ 64 <1800000000>;
				opp-microvolt = <1150000 1150000 1150000>;
				clock-latency-ns = <40000>;
			};

I originally tried 1.05V-1.15V to see if I could possibly undervolt to and still get performance gain, but I didn't see much of a performance gain from 1600MHz (even though it was 1.10V-1.15V), so I had to bump up the voltage to 1.15V. I ended up testing more than I originally planned, but I got the following results (from dietpi-benchmark) averaged from 5 tests locked at the different frequencies and voltages:

Metric	(baseline) 1416 MHz @ 1.025-1.15V	1608 MHz @ 1.10–1.15V	1608 MHz @ 1.20V fixed	1800 MHz @ 1.10V fixed	1800 MHz @ 1.15V fixed	1800 MHz @ 1.20V fixed
CPU benchmark	14.35–14.63 s	11.58–11.72 s (-20%)	10.95–11.12 s (-24%)	11.32–11.38 s (-22%)	10.96–11.03 s (-24%)	10.72–10.76 s (-26%)
RAM write	320–331 MiB/s	400–415 MiB/s (+25%)	406–438 MiB/s (+30%)	403–427 MiB/s (+28%)	407–436 MiB/s (+30%)	421–449 MiB/s (+34%)
RAM read	851–898 MiB/s	1110–1118 MiB/s (+27%)	1132–1179 MiB/s (+32%)	1114–1143 MiB/s (+29%)	1146–1171 MiB/s (+32%)	1156–1202 MiB/s (+35%)

Based off these test results, I don't see much value in adding 1.8GHz. According to the datasheet https://files.pine64.org/doc/quartz64/Rockchip%20RK3566%20Datasheet%20V1.0-20201210.pdf max safe voltage is 1.2V. Performance seems to scale with voltage, but we're I'm getting in the territory of diminishing returns. The initial jump from 1.4 GHz to 1.6GHz is significant though. 1608 MHz @ 1.10–1.15V and 1800 MHz @ 1.10V fixed looks relatively the same, but I'd assume we'd be more stable at the 1608MHz config (no clue about stability and errors that might appear at 1.8GHz these voltages).

[MichaIng]

I'm not to keen on testing Radxa's image. DietPi is too good 😄. Thanks for your hard work!

Only temporarily, to see whether they really run at 1.8 GHz, as indicator that it does not seem to cause damage, at least 😉. But I do now see the opp-supported-hw in the vendor sources: https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr5.1/arch/arm64/boot/dts/rockchip/rk356x.dtsi#L187-L218
In an earlier version, custom code removed the higher frequencies: radxa/kernel@2dfd51d
So they use indeed 1.4 GHz. Similar to UHS support, probably best to enable it as overlay first, to it can be easily reverted by admins in case of instabilities.

Weird that performance scales as well with voltage 🤔. Usually I would assume it to only affect stability.