no‑eMMC Zero 3W never boots from DietPi_RadxaZERO3-ARMv8-*.img.xz images, but Radxa Debian boots fine from the same SD card.

[simware]

Creating a bug report/issue

• [ *] I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version
• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
• Kernel version | uname -a
• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
• Power supply used | (EG: 5V 1A RAVpower)
• SD card used | (EG: SanDisk ultra)

Additional Information (if applicable)

• Software title | (EG: Nextcloud)
• Was the software title installed freshly or updated/migrated?
• Can this issue be replicated on a fresh installation of DietPi?

• Bug report ID | echo $G_HW_UUID

Steps to reproduce

1. Download the latest image
2. try to start the image on Radxa W3 - No boot

Expected behaviour

• Boot into diet pi

Actual behaviour

• Not booting

Extra details

1. Flash and boot Radxa's official Debian image
   Use the Radxa Zero 3 Debian Bookworm image (not Ubuntu — the installer rejects Ubuntu). Boot it on the SD card, log in (default radxa / radxa), and connect to the network.

2. Run the DietPi installer

sudo apt update
sudo apt install -y systemd-sysv ca-certificates sudo wget locales
sudo bash -c "$(wget -qO- 'https://raw.githubusercontent.com/MichaIng/DietPi/master/.build/images/dietpi-installer')"

The installer strips Radxa OS down to a minimal Debian, layers DietPi on top, and leaves the bootloader/U‑Boot — the bit that's working — untouched. It'll reboot into the DietPi first‑run wizard.

3. Done
   You end up with the same DietPi userspace as the official image, just sitting on Radxa's bootchain. Updates via dietpi-update work the same way.

A few notes
"no‑eMMC Zero 3W never boots from DietPi_RadxaZERO3-ARMv8-*.img.xz images, but Radxa Debian boots fine from the same SD card." The maintainer is responsive and that's the kind of bug report they need to fix the SPL.

[MichaIng]

When you run dietpi-installer, do you select "Radxa ZERO 3" there? Because that would install and flash the same U-Boot image our OS image ships with. Hence if the SPL was faulty, the system should fail to boot the same way after running dietpi-installer.

If you select "Generic Device" or similar, Radxa's vendor bootloader and kernel would remain, but that is not what we aim for.

The maintainer is responsive and that's the kind of bug report they need to fix the SPL.

Who said that? Did you provide serial console output elsewhere, for someone to know that the SPL is faulty? If so, please paste them here as well. Without serial console output, there is no way to know whether the SPL is the issue, or something else. We'd need more details then, HDMI output if any, LED behavior, whether it actually boots fine and just network fails to configure, in case a check of the image content whether partition/filesystem expansion failed. The U-Boot version was was pinned 7 months ago, and I know there were users successfully using our image on the ZERO 3W since then 🤔. Possible that I am missing something.

no‑eMMC Zero 3W

What does that mean? Are there variants without onboard eMMC, or do you just mean that you boot from SD card instead? Btw, what is on the eMMC, if there is one? Maybe, when mainline U-Boot is on the SD card, and some vendor U-Boot remains on the eMMC, it tries to boot from eMMC with priority or so (SPL from eMMC, but then OS from SD card if there is no bootable partition on the eMMC), which might cause the issue. This was the case with some NanoPis.

[simware]

Thanks for the answer!

Who said that?
It was Claude who said the above.

Are there variants without onboard eMMC,
That is correct, there are versions without the eMMC, and I boot from an SD card.

"Radxa Zero 3W no-eMMC variant does not boot with any DietPi_RadxaZERO3-ARMv8-*.img.xz (Bookworm/Trixie/Forky) nor after running dietpi-installer on Radxa Debian. Same SD card boots Radxa Debian Bookworm reliably. Symptom: 3 short green LED blinks, no UART output past [reserved-memory]." Claude told me to mention you confirmed it's the bootchain by testing installer-on-top.

I am unable to provide any UART information, sorry to say, since I do not have the hardware to do it.

[MichaIng]

That is correct, there are versions without the eMMC, and I boot from an SD card.

Okay, good to know.

no UART output past [reserved-memory]

I am unable to provide any UART information, sorry to say, since I do not have the hardware to do it.

If you do not have the hardware, where is the information from, that there is no UART output past [reserved-memory]? It sounds like a bootloader issue indeed, but the full log would be very helpful to be sure.

And still the question I asked above:

When you run dietpi-installer, do you select "Radxa ZERO 3" there?

It would contain this output:

[ SUB1 ] DietPi-Set_hardware > flash-u-boot-mmc (/dev/loop0)
18979+0 records in
18979+0 records out
9717248 bytes (9.7 MB, 9.3 MiB) copied, 0.0637788 s, 152 MB/s

[  OK  ] flash-u-boot-mmc (/dev/loop0) | Completed

Afterwards, the bootloader would match the one in our image. Hence the findings do not add up.

[simware]

When you run dietpi-installer, do you select "Radxa ZERO 3" there?
Yes, I did, if I remember correctly its was number 90.

What I am saying is that the image is not working, and it's not working to use dietpi-installer as well. None of those works. Was hoping that I could get DietPI up and running.

Will elaborate, I do not have a UAR cable (what I mean by the hardware). If you need the output, I can see if I can get a cable. It was once more Claude who did the summary for me. You are right that I did not read anything from UART output.

[MichaIng]

What I am saying is that the image is not working, and it's not working to use dietpi-installer as well.

Ah, in your original post you wrote:

You end up with the same DietPi userspace as the official image, just sitting on Radxa's bootchain. Updates via dietpi-update work the same way.

Which I understood as it is working. But makes sense that it does not work either, if the bootloader is the issue, except it you select some "Generic Device" to use the bootloader and kernel shipped with the original image.

Will elaborate, I do not have a UAR cable (what I mean by the hardware). If you need the output, I can see if I can get a cable. It was once more Claude who did the summary for me. You are right that I did not read anything from UART output.

Yeah, so far Claude hallucinated/guessed UART output where none was given, so it is not yet guaranteed to be a bootloader issue, and if so, whether it is the SPL. Since it works for others on the ZERO 3W, I could imagine that there is some quirk due to the missing eMMC, like that mainline U-Boot expects the eMMC on that model, to do the boot target loop correctly. Might be something with the internal mmc device numbering, or some hard failure if it tries and fails to read from it. Usually I'd expect a similar grateful behavior like if no SD card is attached, but who knows.

I'll have some look into the U-Boot config and device tree(s).