MichaIng
Orange Pi 3B | NVMe boot fails
Creating a bug report/issue
- [x] 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
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?
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!
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.
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.
Okay so no difference between vendor kernel sources (Linux 6.1) and mainline kernel sources (Linux 6.12). Good to know.
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
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?
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. :(
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 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.
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.
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?
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
Okay then it does not seem to boot at all. Could it be some power issue? You have a good 5V 3A or higher PSU? An NVMe SSD does draw quite some additional power on load, and I could imaging, if it is used as root device early on, and has some peak, it might affect the initialization of other devices, like HDMI in one case, of something more critical preventing boot completely in another case.
Okay then it does not seem to boot at all. Could it be some power issue? You have a good 5V 3A or higher PSU? An NVMe SSD does draw quite some additional power on load, and I could imaging, if it is used as root device early on, and has some peak, it might affect the initialization of other devices, like HDMI in one case, of something more critical preventing boot completely in another case.
I was wondering the same. Tried both 5V 3A and 5V 5A good power supply, same issue...
Just in case, could you test that image based on latest bootloader and kernel? https://dietpi.com/downloads/images/testing/
Just in case, could you test that image based on latest bootloader and kernel? https://dietpi.com/downloads/images/testing/
Tested. Same. Not booting..
I was researching a bit further about all this, and am now pretty certain that the defined PCIe regulator nodes vcc3v3_pcie (Xunlong image) and vcc3v3_pcie30 (mainline/DietPi image) refer to the same hardware component. Same output voltage, same regulator type, same attached GPIO pins etc.
Significant difference, across all kernel and device tree versions on each side, never changed, is that Xunlong device tree defines an additional 12V regulator, and that one as input for its vcc3v3_pcie. Mainline does not define any 12V regulator, but uses vcc3v3_sys 3.3V regulator as input for its vcc3v3_pcie30 instead.
Xunlong device tree says about the 12V regulator "/* labeled +12v in schematic */". So yeah, finally we need to check schematics. Linked from here: http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-3B.html
- How I love those Google drive stored documents ... https://drive.google.com/file/d/1oyozD-EEQKczGPXWlmkygSNtAl-OAftn/view (attached hereby OPi 3B V2.1.pdf)
Checking through the schematics carefully, there is not a single 12V regulator or input or output or anything like that mentioned at all. It does mention the vcc5v0_sys and vcc3v3_pcie30, and vcc3v3_sys, so generally mainline device tree uses the correct node names from the schematics, while Xunlong device tree uses a different name, not matching their own schematics, and defines a 12V regulator which is not present in the schematics. The board is documented to support and use 5V only (not making use of PD if the PSU supports that), moreover, the wiki explicitly warns to not power it with any higher voltage: http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_3B#Start_the_Orange_Pi_development_board
So the Xonlong device tree is wrong, defines a non-existing regulator with voltage that is not supported by the board, and yet, you say with that one (I verified the image you linked uses the Xunlong device tree), it boots from NVMe, while with mainline Linux it does not.
Based on all that, I am pretty certain it would be safe to just add the 12V regulator to our device tree as well, use it as input for the PCIe regulator and just see whether this fixes things. But otherwise it is somewhat wrong. Checking the schematics more carefully, 2nd last slide about the M.2 socket, bottom right box, you see the vcc3v3_pcie30 regulator and vcc5v0_sys attached, as well as the pcie20_pwren power enable pin control that is defined in both device trees as pin control for the PCIe power regulator. In that section of the schematics, the vcc3v3_sys regulator is not mentioned at all. This suggests that it would more accurately describe the hardware when using vcc5v0_sys as input regulator for the vcc3v3_pcie30 node, instead of having this cascaded regulator attachment vcc5v0_sys to vcc3v3_sys to vcc3v3_pcie30. It would be somewhat in the middle between Xonlong and mainline device trees, matching the schematics most accurately, as far as I understand them. I have not really an idea in how far definitions in the device tree can effect stability of (internal) power supply of certain board components, but obviously it does have an effect.
But before playing with this, @lemontreeau any chance you get a UART adapter to check bootloader and early kernel logs, to be sure I am not on the wrong track?
And @StephanStS if you find time to have a look on this, that would be awesome. I studied engineering, which did include electrical power topics, but on the larger scale, also control and regulation circuits, but excluding microelectronics. So when it comes to software definitions affecting hardware behavior on this level, it is still somewhat a black box to me 😅.
any chance you get a UART adapter to check bootloader and early kernel logs
Don't have UART adapter :( I'll start looking for one now..
Not a bad investment when using SBCs, like 5 $ or what, but allows you to debug all sorts of problems with bootloader, boot config or kernel, at a stage before the HDMI display is up. The Orange Pi wiki actually also has a section about it: http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_3B#How_to_use_the_debugging_serial_port
Generally you need a USB-UART adapter with 3 pins only: RX, TX and GND. It does not require additional flow control or power pins, but they do not hurt either. Regarding power pins it is power a question to be on the safe side and not accidentally put 5V on a pin that is not supposed to get any power.
All SBCs have either dedicated 3 pins for the debug UART (like the Orange Pi 3B does), or use pins 6+8+10 on the 40 pins GPIO header for the default UART, a standard which has been pretty much established with the Raspberry Pi 40-pins header. So you can use this with any SBC moreless the same way, accessing via e.g. PuTTY or other SSH client, which are usually serial console clients as well.
Message from the USB-UART adapter.. Missing dtb file? And an issue with the OP-TEE firmware?
... is now current device
Scanning nvme 0:1...
Found U-Boot script /boot/boot.scr
2711 bytes read in 1 ms (2.6 MiB/s)
## Executing script at 00c00000
285 bytes read in 2 ms (138.7 KiB/s)
37939712 bytes read in 129 ms (280.5 MiB/s)
14915917 bytes read in 52 ms (273.6 MiB/s)
** File not found /boot/dtb/ **
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Fdt Ramdisk skip relocation
## Loading init Ramdisk from Legacy Image at 0a200000 ...
Image Name: uInitrd
Image Type: AArch64 Linux RAMDisk Image (gzip compressed)
Data Size: 14915853 Bytes = 14.2 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
SCRIPT FAILED: continuing...
starting USB...
Bus dwc3@fcc00000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus dwc3@fd000000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus dwc3@fcc00000 for devices... 1 USB Device(s) found
scanning bus dwc3@fd000000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Device 0: unknown device
failed to find reset-gpios property
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-rockchip
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
failed to find reset-gpios property
No ethernet found.
Could not find misc partition
ANDROID: reboot reason: "(none)"
optee check api revision fail: -1.0
optee api revision is too low
### ERROR ### Please RESET the board ###
I saw the OP-TEE error on my Orange Pi 5 Ultra, when it failed to boot. Took the U-Boot config from Orange Pi where it was enabled. I disabled it for a new build, from which point on it worked. However, I recognized that I used an older build after which I made some other fixes, so in the meantime, I do not think that OP-TEE (while not functional with our kernel) in U-Boot was not causing my boot failure.
Also in your case, the original problem is that for whatever reason, while boot script, env, kernel and initramfs are successfully loaded from NVMe, the device tree is not. Actually it seems the fdtfile variable is not set. And indeed we do not set it for that SBC, since (our) U-Boot sets it correctly by itself.
So problem is the SPI bootloader you use to be able to boot from NVMe. You have two options:
- Flash our recent U-Boot to SPI, e.g. via
dietpi-config> Advanced Options > Splash SPI bootloader. - Define the device tree in
/boot/dietpiEnv.txt:
G_CONFIG_INJECT 'fdtfile=' 'fdtfile=rockchip/rk3566-orangepi-3b-v2.1.dtb' /boot/dietpiEnv.txt
And now I remember that we do not set it, since there are two for the respective board revision, and U-Boot picks the correct one, while we would break Ethernet for one of them when setting it ourselves. We could select one in the boot script if the variable is unset, but then we at best also find a way to detect the revision there 🤔.
Tried https://dietpi.com/downloads/images/testing/DietPi_OrangePi3B-ARMv8-Bookworm.img.xz Now getting:
... is now current device
Scanning nvme 0:1...
Found U-Boot script /boot/boot.scr
3222 bytes read in 1 ms (3.1 MiB/s)
## Executing script at 00c00000
338 bytes read in 1 ms (330.1 KiB/s)
** File not found /boot/dtb/ **
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
38277632 bytes read in 130 ms (280.8 MiB/s)
14939319 bytes read in 52 ms (274 MiB/s)
Fdt Ramdisk skip relocation
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
SCRIPT FAILED: continuing...
starting USB...
Bus dwc3@fcc00000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus dwc3@fd000000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus dwc3@fcc00000 for devices... 1 USB Device(s) found
scanning bus dwc3@fd000000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Device 0: unknown device
failed to find reset-gpios property
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-rockchip
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
failed to find reset-gpios property
No ethernet found.
Could not find misc partition
ANDROID: reboot reason: "(none)"
optee check api revision fail: -1.0
optee api revision is too low
### ERROR ### Please RESET the board ###
I did not do any change to the image in this regards. Check the 2 options you need to apply for this to work: https://github.com/MichaIng/DietPi/issues/7567#issuecomment-2988941508
Check the 2 options you need to apply for this to work: #7567 (comment)
Yes, already applied the 2 options as suggested and as well as the OS image in the testing folder.. :(
Hmm, it does not seem to have worked, I mean the bootloader has not been updated, and the fdtfile variable has not been assigned either. Can you add the output of the bootloader until ... is now current device, to verify its version?
Just to assure what you did:
- Flash DietPi to SD card and boot it
- Run
dietpi-configand select Advanced Options > Flash SPI bootloader - In case verify there was no error message about it: you can see its output on the console after exiting
dietpi-config.
Additionally, or alternatively:
- Flash DietPi to NVMe SSD.
- But boot it from the SD card at first.
- Mount the first (!) ext4 partition of the NVMe drive somewhere.
- Edit the
/path/to/mountpoint/boot/dietpiEnv.txtwithin the mounted NVMe partition and addfdtfile=rockchip/rk3566-orangepi-3b-v2.1.dtbthere.
After one or both above steps, it should boot from that NVMe SSD.
Current full message from the USB-UART adapter:
U-Boot SPL board init
U-Boot SPL 2017.09-orangepi (Aug 22 2023 - 11:36:56)
Trying to boot from MMC1
Card did not respond to voltage select!
spl: mmc init failed with error: -95
Trying to boot from MMC2
Card did not respond to voltage select!
spl: mmc init failed with error: -95
Trying to boot from MTD2
No misc partition
Trying fit image at 0x400 sector
## Verified-boot: 0
## Checking atf-1 0x00040000 ... sha256(2f01bd8955...) + OK
## Checking uboot 0x00a00000 ... sha256(cc44fd0ec8...) + OK
## Checking fdt 0x00b44d88 ... sha256(c92ef3591c...) + OK
## Checking atf-2 0xfdcc9000 ... sha256(f1fecab971...) + OK
## Checking atf-3 0xfdcd0000 ... sha256(d7aa45eb18...) + OK
Jumping to U-Boot(0x00a00000) via ARM Trusted Firmware(0x00040000)
Total: 554.139 ms
INFO: Preloader serial: 2
NOTICE: BL31: v2.3():v2.3-152-g4e725b15f:cl
NOTICE: BL31: Built : 10:51:13, Jul 15 2021
INFO: GICv3 without legacy support detected.
INFO: ARM GICv3 driver initialized in EL3
INFO: pmu v1 is valid
INFO: dfs DDR fsp_param[0].freq_mhz= 1056MHz
INFO: dfs DDR fsp_param[1].freq_mhz= 324MHz
INFO: dfs DDR fsp_param[2].freq_mhz= 528MHz
INFO: dfs DDR fsp_param[3].freq_mhz= 780MHz
INFO: Using opteed sec cpu_context!
INFO: boot cpu mask: 0
INFO: BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR: Error initializing runtime service opteed_fast
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0xa00000
INFO: SPSR = 0x3c9
U-Boot 2017.09-orangepi (Aug 22 2023 - 11:36:56 +0800)
Model: Orange Pi 3B
PreSerial: 2, raw, 0xfe660000
DRAM: 4 GiB
Sysmem: init
Relocation Offset: ed234000
Relocation fdt: eb9f6a50 - eb9fecc8
CR: M/C/I
Using default environment
failed to find reset-gpios property
dwmmc@fe2b0000: 0, dwmmc@fe2c0000: 2, sdhci@fe310000: 1
Device 0: unknown device
Card did not respond to voltage select!
Card did not respond to voltage select!
Device 0: unknown device
Device 1:
Device 2: SF: Detected sfc_nor with page size 256 Bytes, erase size 4 KiB, total 16 MiB
Vendor: 0x2207 Rev: V1.00 Prod: sfc_nor
Type: Hard Disk
Capacity: 16.0 MB = 0.0 GB (32768 x 512)
... is now current device
Bootdev(scan): mtd 2
PartType: EFI
DM: v1
boot mode: None
I2c0 speed: 100000Hz
vsel-gpios- not found! Error: -2
vdd_cpu 643750 uV
PMIC: RK8090 (on=0x40, off=0x00)
vdd_logic init 900000 uV
vdd_gpu init 900000 uV
vdd_npu init 900000 uV
of_get_regulator: Get (vccio3-supply) regulator: 0 failed, ret=-19
of_get_regulator: Get (vccio5-supply) regulator: 0 failed, ret=-19
of_get_regulator: Get (vccio6-supply) regulator: 0 failed, ret=-19
of_get_regulator: Get (vccio7-supply) regulator: 0 failed, ret=-19
io-domain: OK
Failed to get scmi clk dev
dmc_fsp failed, ret=-19
Model: Orange Pi 3B
rockchip_set_ethaddr: vendor_storage_write failed -5
CLK: (sync kernel. arm: enter 816000 KHz, init 816000 KHz, kernel 0N/A)
apll 816000 KHz
dpll 528000 KHz
gpll 1188000 KHz
cpll 1000000 KHz
npll 24000 KHz
vpll 24000 KHz
hpll 24000 KHz
ppll 200000 KHz
armclk 816000 KHz
aclk_bus 150000 KHz
pclk_bus 50000 KHz
aclk_top_high 300000 KHz
aclk_top_low 200000 KHz
hclk_top 150000 KHz
pclk_top 50000 KHz
aclk_perimid 300000 KHz
hclk_perimid 150000 KHz
pclk_pmu 100000 KHz
Net: No ethernet found.
Hit key to stop autoboot('CTRL+C'): 0
Card did not respond to voltage select!
dwmmc@fe2b0000: 0
dwmmc@fe2c0000: 2
sdhci@fe310000: 1
Card did not respond to voltage select!
failed to find reset-gpios property
Device 0: Vendor: 0x15b7 Rev: 73914108 Prod: 234638800903
Type: Hard Disk
Capacity: 244198.3 MB = 238.4 GB (500118192 x 512)
... is now current device
Scanning nvme 0:1...
Found U-Boot script /boot/boot.scr
3222 bytes read in 1 ms (3.1 MiB/s)
## Executing script at 00c00000
338 bytes read in 1 ms (330.1 KiB/s)
** File not found /boot/dtb/ **
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
38277632 bytes read in 131 ms (278.7 MiB/s)
14939319 bytes read in 52 ms (274 MiB/s)
Fdt Ramdisk skip relocation
ERROR: Did not find a cmdline Flattened Device Tree
Could not find a valid device tree
SCRIPT FAILED: continuing...
starting USB...
Bus dwc3@fcc00000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus dwc3@fd000000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus dwc3@fcc00000 for devices... 1 USB Device(s) found
scanning bus dwc3@fd000000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Device 0: unknown device
failed to find reset-gpios property
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-rockchip
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
failed to find reset-gpios property
No ethernet found.
Could not find misc partition
ANDROID: reboot reason: "(none)"
optee check api revision fail: -1.0
optee api revision is too low
### ERROR ### Please RESET the board ###
U-Boot 2017.09-orangepi (Aug 22 2023 - 11:36:56 +0800)
So still the old U-Boot there. The two options to fix it remain true.
Using your suggested alternatively way, it can successfully boot from NVMe. Thanks.
However, now the MAC address keeps changing after every reboot.
The option Update SPI bootloader : Flash current U-Boot to /dev/mtd0 was btw what I meant. Did you do that, or did you add fdtfile=rockchip/rk3566-orangepi-3b-v2.1.dtb to /boot/dietpiEnv.txt, or both?
However, now the MAC address keeps changing after every reboot.
This seems like you are still using the Xunlong/Orange Pi bootloader on SPI, hence applied the fdtfile setting instead, right? Our bootloader applies a static MAC address.
However, good to know that really only the false/missing fdtfile variable was the problem in your case.
So you could try to flash our SPI bootloader instead, the first option. This will make the Ethernet address static. But @StephanStS is currently testing NVMe on the Orange Pi 3B as well, and there it was not detected at all with our bootloader for some reason, also not when booting from SD card. But there is behaves a little different in general for so far unknown reasons:
- In your case, when booting from SD card, obviously our bootloader from SD card was used, since you did not have the
fdtfileissue there. And NVMe was working. - In his case, when despite booting from SD card, the bootloader from SPI storage is used. And if your bootloader is on SPI storage, NVMe is not working for him, while it works when using the Xunlong bootloader, when solving the same issue with false
fdtfilevariable.
We btw tested the PCIe regulator change in the device tree I was talking about, declaring the 5V regulator as input for the 3.3V PCIe regulator, instead of a cascade 5V sys => 3.3V sys => 3.3V PCIe that is not backed by the board schematics. But this made no difference.