When boot mode is set to QSPI (0,0) it is possible to boot from an sdcard if no NVME drive is installed.
When using SPI v2.11.5 you can still boot from an sdcard if an NVME drive is installed.
This is an empty formatted nvme drive to be used as data storage i.e. no OS system.
With SPI v3.0.4 and v3.1.5 this is no longer possible. Why??? If there is no OS on the NVME drive then the boot should default to the sdcard as it did in v2.11.5.
Now it is no longer possible to use an NVME drive with an OS running from an sdcard.
Is it possible to manually set the boot order somewhere?
See page 48 (last page). Flip the boot mode switches to SDIO and it will ignore the NVME just like you’re wanting. I don’t know if there is a software setting to accomplish the same, but this should do exactly what you want.
From the (recently updater) VisionFive 2 boot User guide:
“System will detect in sequence whether it can boot from the following device sequence: NVMe > SD > eMMC. For example, if the boot program is found on the SD, eMMC will be ignored.”
But at a guess this documentation change does not apply to v3.1.5 nor v3.0.4, and I assume that it only applies to EDK2 ( JH7110 VF2 JUNE 2023) or JH7110 VF2 APR 2023 UEFI firmware and not the U-Boot. But that is not explicitly stated in the documentation.
What I would do is power down the board, change the switches to the SDIO position. Boot from a MicroSD card and while 3 serial wires are connected to the GPIO header (GND->GND,TX->RX,RX->TX) with a USB to UART device, I would hit the space bar when asked during the boot to escape into the U-Boot prompt (#) and type “env print” and take a note of all environmental variables especially the “bootcmd” variable and everything directly related to it.
Or else I would power off the board, change the switches to the QSPI position. Boot while 3 serial wires are connected to the GPIO header (GND->GND,TX->RX,RX->TX) with a USB to UART device, I would hit the space bar when asked during the boot to escape into the U-Boot prompt (#) and type “env print” and take a note of all environmental variables especially the “bootcmd” variable and everything directly related to it.
Then I would analyse the boot process and go about changing any environmental variables if I needed to. And in the worse case I would just no longer reference anything to do with the NVME hardware in the environmental variables. I would boot at least once with my in RAM only modifications to tested that my changes actually worked. And if they did actually work as expected I would change all the variables, in RAM, that I had found that I needed to change for the boot process to work the way I needed it to work and finally I would “envsave” to write the changes onto permanent storage in the QSPI NOR FLASH.
@mzs thanks for all the info.
Can give more details on how to change environmental variables with some code examples?
Also is there any documentation anywhere because I haven’t been able to find any.
I have only started to learn about this stuff very recently (Basically I’m no expert), so I can’t really give you examples, I would look at the hard coded defaults used by the starfive visionfive 2 board within U-Boot for inspiration that are used to setup all the environmental if the QSPI NOR FLASH has not been setup… And I would also look at the hard coded defaults for all the other boards supported by Das U-Boot.for examples. Just keep in mind that before the board specific configuration is used that other hard coded defaults are set first for all boards. But these can be overwritten by board specific values e.g. configs/starfive_visionfive2_defconfig which sets up the boot command environmental variable (bootcmd) that will eventually be run and the boot arguments (bootargs) used. Tracing back how all the environmental variables are setup is not really needed, just the ability to change them, if they need to be and saving them only after you are happy that your changes work (you do not want to accidentally remove your ability to access the U-Boot environment) should you save them permanently (It can be recovered from but best to avoid that pain).
Print out all variables and their values env print
Print out one specific variable and its value env print <variable>
Create a new variable or modify an existing variable with a new value env set <variable> <value>
Write all environmental variables and their values from RAM to QSPI NOR FLASH.(Only do this once you have tested at least once from RAM that your changes actually work (They will all be removed on a the boot, so keep notes and set them all again, maybe even test your changes with more than one boot before saving). env save
And then there is the command that can be used as a very last resort, it will zap all environmental variables back to their factory defaults: env default -a -f
Two useful links for documentation are for the env command and the environment variables. Just keep in mind that the documentation is for the latest version of U-Boot (e.g. 2023-07) and not the version used on the VisionFive 2 board U-Boot SPL 2021.10-dirty (Jun 11 2023 - 07:44:44 +0000), but the basic functionality should be almost the exact same for something that is a core functionality of Das U-Boot.