NVME Boot not working on VisionFive 2 QSPI with new firmware

I have installed the most recent U-Boot and firmware for the VisionFive 2 according to NVME Boot using VisionFive2 Software v2.11.5 . I flashed the NVMe 202306 image onto my NVMe disk and the 202306 SD image on my SD disk and also updated the firmware on the respective partitions 1 and 2 on the SD and NVMe disks. Booting from SD works fine, but is i set the QSPI switch on the board to boot from the NVMe, U-Boot does not seem to see/scan the PCI NVMe. Indeed, in the discussion of NVME Boot using VisionFive2 Software v2.11.5 - #24 by danboid it is suggested that U-Boot does not scan for PCI devices and thus does not boot from the NVMe SSD. The method there to use setenv and saveenv to pass on the necessary settings to the QSPI flash memory don’t work for me. Neither sentenv nor saveenv command is available to me, so i cannot use that solution method. Now i am stuck with QSPI flash Mtb U-Boot firmware not booting from NVMe. This seems to be a weakness of the most recent “u-boot-spl.bin.normal.out” and “visionfive2_fw_payload.img” files.

I don’t have any experience with U-Boot’s environment variables yet, but have you consulted this?

1 Like

The only thing that I can think of is that the image file might possibly be incompatible with v3.1.5

Because looking at the release dates the firmware in the image file is probably v3.0.4 and not v3.1.5.

2023-05-31 v3.0.4 was released 
2023-06-16 starfive-jh7110-202306-nvme-minimal-desktop.img.bz2 was released 
2023-07-02 v3.1.5 was released

You can probably get it to work if that is the case by modifying some environment variables, but I’m only guessing here, I could be totally wrong.

Still it might be worthwhile flashing with v3.0.4, or possible zapping all your your Das U-Boot environmental variables back to factor defaults (For the new/old Das U-Boot firmware).

Thinking about it a bit more, the second option is the first thing you should try.

env default bootcmd
env default -a
env save

The first two commands will reset everything in RAM, the last command will write them to storage (QSPI NOR FLASH for the VF2), so that they will persist across boots. The above three commands where blatantly plagiarised from here.

setenv and saveenv are u-boot commands, not Linux commands, and you will have them if you can access u-boot.

The most common reason for NVME failures is that your PSU isn’t providing enough power or maybe its a faulty or poor quality USB C cable. Whilst your PSU may be good enough to boot your VF2 off uSD card, it may not be powerful enough to power a NVME SSD too.


I could not enter U-Boot prompt at boottime. Thus i had no access to U-Boot prompt and shell…

I could format and flash my NVMe without any problems from my SD-card booted VisionFive 2 Debian sid. It is also accessible quite easily for read/write access without any failure. I have PD power supply upt to 30W exclusive. That should more than enough.

To do this, please connect a second system to the UART of your VF2 using a 3.3V USB-to-serial converter or directly serial-to-serial as described here:

3.4.3. Using a USB to Serial Converter

Then you can not only observe the boot process from the second system, but also interrupt the boot loader in use and make entries.


Thanks! I am currently trying to compile the most recent u-boot and payload files myself. I think the ones i am using currently are an older version, which does not yet support proper NVMe integration… I have a UART adapter btw.

OK. I flashed the 3.0.4 “u-boot-spl.bin.normal.out” and “visionfive2_fw_payload.img” files onto the QSPI flash via mtdutils flashcp tools (“u-boot-spl.bin.normal.out” to /dev/mtd0 and “visionfive2_fw_payload.img” to /dev/mtd1) and now NVMe boot works perfectly with Boot mode switches on the VisionFive 2 set to QSPI boot.

It is a pity that the official resources on the StarFive Github page do not provide visionfive2_fw_payload.img for version 3.1.15. After trying to compile the two files myself from the Github sources for StarFive Software 3.1.15, i ended up with broken “u-boot-spl.bin.normal.out” and “visionfive2_fw_payload.img” versions, which did not boot at all.

Also an attempt to compile OpenSbi and U-Boot directly from the respective sources with a profile for StarFive VisionFive 2 failed to produce working versions of the two files (but that may be due to my lacking skill and routine in such things).

1 Like