Orange Pi 3B | NVMe boot fails

[lemontreeau]

Creating a bug report/issue

• I have searched the existing open and closed issues

Steps to reproduce

I used RKDevTool, followed steps in their official guide, flashed the following images downloaded from https://dietpi.com/downloads/images to the NVMe SSD on the PCIE:

• |DietPi_OrangePi3B-ARMv8-Bookworm.img.xz|2025-04-22 21:46 |210M|
• |DietPi_OrangePi3B-ARMv8-Trixie.img.xz|2025-04-22 21:50 |225M|
• |DietPi_OrangePi3B-ARMv8-Bullseye.img.xz|2025-04-22 21:14 |200M| - Can't download, redirecting back to https://dietpi.com/downloads/images.

Expected behaviour

Should boot.

Actual behaviour

Not booting. Black screen.

Extra details

• Board version 2.1
• DietPi can boot from SD Card

[MichaIng]

Which Armbian image did you use exactly? Because we use the Armbian build system for our kernel packages as well, so it should be the same, unless you use a different kernel branch.

And do you have a UART adapter to check serial console logs?

[lemontreeau]

Which Armbian image did you use exactly? Because we use the Armbian build system for our kernel packages as well, so it should be the same, unless you use a different kernel branch.

And do you have a UART adapter to check serial console logs?

Sorry, re-tested. Armbian also not working. Thanks for the quick response!

[MichaIng]

Which Armbian image did you test?

And could you try to update the SPI bootloader via dietpi-config > Advanced Options > Update SPI bootloader? Probably the original bootloader has some limitations regarding partitioning, or boot script support.

[lemontreeau]

Which Armbian image did you test?

And could you try to update the SPI bootloader via dietpi-config > Advanced Options > Update SPI bootloader? Probably the original bootloader has some limitations regarding partitioning, or boot script support.

Tried all 3 images from: https://www.armbian.com/orangepi3b/
and one more from https://github.com/armbian/community/releases/tag/25.8.0-trunk.8

Will try update SPI bootloader in dietpi-config.

[MichaIng]

Okay so no difference between vendor kernel sources (Linux 6.1) and mainline kernel sources (Linux 6.12). Good to know.

[lemontreeau]

Okay so no difference between vendor kernel sources (Linux 6.1) and mainline kernel sources (Linux 6.12). Good to know.

Still not booting after updating SPI bootloader in dietpi-config.

I tested one can boot:
https://k-space.ee.armbian.com/archive/orangepi3b/archive/Armbian_23.11.1_Orangepi3b_bookworm_edge_6.6.2.img.xz

[MichaIng]

Hmm, so it broke between Linux 6.6 and Linux 6.12. I just compared the Linux 6.6 device tree from Xunlong sources with mainline 6.12:

• https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.6-rk35xx/arch/arm64/boot/dts/rockchip/rk3566-orangepi-3b-v2.dts
• https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566-orangepi-3b.dtsi (mainline uses a common include for both revisions)

What I recognised is that the 3.3V regulator used for the PCIe node pcie2x1 in mainline Linux has a 3.3V vin-supply assigned, but in Xunlong sources a 12V vin-supply? Not yet sure what this is. Will check whether this was 12V in mainline Linux as well at some point.

Armbian uses the dts with the the 12V as well for Linux 6.6 (where no mainline dts exists yet). Btw, with that image, Ethernet does not work on v2.1 revision, right?

[lemontreeau]

Armbian uses the dts with the the 12V as well for Linux 6.6 (where no mainline dts exists yet). Btw, with that image, Ethernet does not work on v2.1 revision, right?

Correct. Ethernet doesn't work. :(

[MichaIng]

This is weird, as of wiki, the DC input or the board is 5V (even that USB-C can serve 12V theoretically). Mainline Linux defines a 5V regulator, used as input for a 3.3V regulator, used as input for the PCIe 3.3V regulator. That seems to be correct and match hardware info.

Xunlong dts defines, aside of 5V and 3.3V regulators, a 12V one, and uses this directly as input for the 3.3V PCIe regulator. The 12V one is also defined as input for one of the the 5V regulators there. As if it aims to support both, 12V and 5V input, transforms it down to 5V and 3.3V as needed. Not sure whether it makes a difference whether a 3.3V regulator has 5V or 12V defined as input.

@StephanStS maybe you know better about what is possible, and how much effect the device tree loaded by the bootloader when the system is up, can somehow provide 12V as input from a capable USB-C PSU, while otherwise the board draws 5V only? And does it make a difference whether 12V is transformed to 3.3V directly, instead of 5V to 3.3V (whatever the original input is in that case)? I mean the device tree should define the hardware. Maybe the hardware is able to use 12V input and has a regulator to convert it to 3.3V directly, but with mainline Linux it is not used. And maybe this had an effect on whether/how NVMe SSDs run.

@lemontreeau
Btw, does the NVMe port work when booting from SD card? Can it be mounted etc?

[lemontreeau]

@lemontreeau Btw, does the NVMe port work when booting from SD card? Can it be mounted etc?

Yes, the NVMe SSD can be mounted when booting from SD card.

[MichaIng]

Okay, serial console output would be helpful. This 12V vs 5V>3.3V regulator is the only relevant difference I could find in device trees, but changing something about input voltages is too risky to play around, without someone with more knowledge confirming it is safe.

Here is a matching report at the Armbian forum: https://forum.armbian.com/topic/47075-orangepi3b-booting-from-pcienvme
He booted with an old U-Boot, and the bootloader found the U-Boot script at first, but then somehow could not load it or so. At this point, no kernel or such has been loaded yet, so only thing that could have an effect is partitioning or bootloader capabilities. I compared the Armbian Linux 6.6 image that worked for you, and it has a single GPT partition with 16 MiB offset, exactly like later images and ours. So unlikely that your issue matches the report in the Armbian forum. More likely, it failed later when the initramfs is trying to mount the root filesystem or so.

[MichaIng]

Oh another interesting report: https://forum.armbian.com/topic/33615-boot-from-nvme-no-hdmi-from-sd-card-ok
Since you also mentioned "Black screen.", do you have a chance to check whether it otherwise booted, like whether it connects network?

[lemontreeau]

Oh another interesting report: https://forum.armbian.com/topic/33615-boot-from-nvme-no-hdmi-from-sd-card-ok Since you also mentioned "Black screen.", do you have a chance to check whether it otherwise booted, like whether it connects network?

Boot from:

• NVMe SSD - Not connecting to network
• SD Card - Connects to network