U-Boot boot_targets set to only mmc0 dhcp

[jrtc27]

https://github.com/starfive-tech/u-boot/blob/62eeb016d65b6872408d9e5384cd9626aee8ff2a/include/configs/starfive-visionfive2.h#L90

This has two issues:

1. mmc0 is the eMMC not the SD card
2. There is no nvme0

The first means it tries to boot from eMMC, fails (if not present) and then doesn't try to boot from SD. It should at least try the SD card, if not both.

The second means it never tries to automatically boot from NVMe.

Please fix both of these. It should be extremely straightforward. This is a regression in 3.1.5 over 2.11.5 (I have not tried the intermediate 3.0.4).

[jrtc27]

Note: this means distro_bootcmd, at least for automatic EFI booting, is completely broken for anything other than eMMC and DHCP, i.e. broken for everything people actually use.

[MichaIng]

Check out my post about this topic in the U-Boot repo: starfive-tech/u-boot#51

[jrtc27]

Check out my post about this topic in the U-Boot repo: starfive-tech/u-boot#51

Ack. So I guess I answered your question of "where"?

[jrtc27]

(BOOT_TARGET_DEVICES is used with a bunch of macro magic to generate bootcmd_* and boot_targets from templates)

[MichaIng]

Not fully. Is this BOOT_TARGET_DEVICES somehow adding/creating the boot_targets variable for the default U-Boot environment? If so, this would work? Okay you answered it while I was writing. So this would work?

#define BOOT_TARGET_DEVICES(func) func(MMC, mmc, 1) func(MMC, mmc, 0) func(NVMe, nvme, 0) func(DHCP, dhcp, na)

Is the "NVMe" correct with capital letter?

EDIT: Ah, but if this function is supposed to do it correctly, why does the resulting environment have this invalid syntax?

bootcmd_mmc0=devnum=0; run mmc_boot

The devnum=0 misses the setenv, as I explained at the other topic.

[jrtc27]

Not fully. Is this BOOT_TARGET_DEVICES somehow adding/creating the boot_targets variable for the default U-Boot environment? If so, this would work? Okay you answered it while I was writing. So this would work?

#define BOOT_TARGET_DEVICES(func) func(MMC, mmc, 1) func(MMC, mmc, 0) func(NVMe, nvme, 0) func(DHCP, dhcp, na)

Is the "NVMe" correct with capital letter?

All-caps; see https://github.com/starfive-tech/u-boot/blob/62eeb016d65b6872408d9e5384cd9626aee8ff2a/include/configs/sifive-unmatched.h#L49C2-L49C21

EDIT: Ah, but if this function is supposed to do it correctly, why does the resulting environment have this invalid syntax?

bootcmd_mmc0=devnum=0; run mmc_boot

The devnum=0 misses the setenv, as I explained at the other topic.

https://github.com/starfive-tech/u-boot/blob/62eeb016d65b6872408d9e5384cd9626aee8ff2a/include/config_distro_bootcmd.h#L38-L41 is where that comes from. The syntax is valid, the difference is whether it's a local or global variable. Presumably some of StarFive's other crud is interacting poorly with this.

[MichaIng]

Hmm, on our VisionFive 2, it did not work. Not sure whether the dedicated devnum=1 env entry makes it a global variable, so that it would work in case devnum was not defined at all (outside of the bootcmd_ functions)?

[jrtc27]

StarFive # setenv devnum 0
StarFive # echo ${devnum}
0
StarFive # devnum=1
StarFive # echo ${devnum}
0
StarFive # devnum=1 echo ${devnum}
0
StarFive # setenv devnum          
StarFive # devnum=1 echo ${devnum}
1
StarFive # echo ${devnum}         
1
StarFive # devnum=2
StarFive # echo ${devnum}
2

So global environment assignments take precedence, and the various setenv's of devnum elsewhere in the StarFive goop are breaking this.

[jrtc27]

e.g. https://github.com/starfive-tech/u-boot/blob/62eeb016d65b6872408d9e5384cd9626aee8ff2a/include/configs/starfive-visionfive2.h#L152-L163 has some setenv's that likely shouldn't be

[jrtc27]

Also https://github.com/starfive-tech/u-boot/blob/62eeb016d65b6872408d9e5384cd9626aee8ff2a/board/starfive/visionfive2/starfive_visionfive2.c#L363-L389 if it's running outside the SPL

[MichaIng]

Yes exactly, this newly added setenv devnum=0 within the NVMe scan is breaking SD card boot (if an NVMe card is attached). And the variable must be globally assigned to 1 elsewhere (I can only see a dedicated devnum=1 on a separate line in the environment), as the bootcmd_mmc0 never worked before, which is actually the eMMC chip, but it did always boot from SD card before.

It is a mess for sure. This whole thing with the hardcoded FAT partition should be removed IMO, leaving only the generic ordered boot targets. This however would break the device tree rewrite (the one on the FAT partition, not the one of U-Boot) that is currently done on every boot, to switch between 4 GiB and 8 GiB RAM, and between A1.2 and A1.3 revision Ethernet. This all looks like a hack to me, and is too fragile and error prone for serious environments. On our personal distribution images I aim to solve this with device tree overlays which are automatically applied on Linux image package installs based on the serial number. But such an intrusive change is unlikely to be accepted by StarFive for their images.

[jrtc27]

I guess downstream as a hack you can patch the generic bootcmd_<block><num> targets to use setenv in the file I linked above. It's piling more hacks on top of the hacks, but at this point it all just needs a rewrite as you say, and we likely just need to wait for the upstreaming efforts to conclude, as those will be starting from scratch and adding a saner flow.

[MichaIng]

Jep, this is what I did on our test system to have proper boot ordering from all block device types. But it means that we must write an override of the whole default U-Boot environment to the SPI flash, which I actually was hoping to avoid, to not potentially break boot of the StarFive image and others. This finally is still a testing and developing board, and hence distros should not do too intrusive changes to the shared SPI flash, to maintain easy switch between distros. However, at the same time it is an opportunity to do some other cleanup and redundant or obsolete function calls, like load_vf2_env and boot2.

[ThomasKorimort]

I installed the Debian-202306 image for nvme on the nvme, booting from SD first. Then i flushed the QSPI flash with "u-boot-spl.bin.normal.out" and "visionfive2_fw_payload.img" from the StarFive Software v3.0.4 Github source tree https://github.com/starfive-tech/VisionFive2/releases/ as the v3.1.5 lacks the "visionfive2_fw_payload.img" file with mtbutils flashcp according to the instruction on https://rvspace.org/en/project/VisionFive2_Debian_User_Guide section 4.4. Then i set the boot mode switch of the VisionFive 2 to the setting for QSPI flash and i removed the SD card and then it booted nicely from the nvme.

Once the QSPI flash of the VisionFive 2 is updated to at least v3.0.4 it will boot from the nvme. Then on the nvme in order to boot the image only two files are involved: /boot/envU.txt, which contains a line with bootcmd listing mmc0 or nvme0 and /boot/extlinux/extlinux.conf, which contains the menu entries for the boot loader. Although the Debian-202306 nvme image makes also partitions for the "u-boot-spl.bin.normal.out" (nvme0n1p1) and "visionfive2_fw_payload.img" (nvme0n1p2) OpenSBI boot process, only the version flashed onto the QSPI flash of the VisionFive 2 will be used and from the nvme will only be called nvme0n1p3 /boot/ directory with the kernel and boot menu entries.

[jrtc27]

I installed the Debian-202306 image for nvme on the nvme, booting from SD first. Then i flushed the QSPI flash with "u-boot-spl.bin.normal.out" and "visionfive2_fw_payload.img" from the StarFive Software v3.0.4 Github source tree https://github.com/starfive-tech/VisionFive2/releases/ as the v3.1.5 lacks the "visionfive2_fw_payload.img" file with mtbutils flashcp according to the instruction on https://rvspace.org/en/project/VisionFive2_Debian_User_Guide section 4.4. Then i set the boot mode switch of the VisionFive 2 to the setting for QSPI flash and i removed the SD card and then it booted nicely from the nvme.

Once the QSPI flash of the VisionFive 2 is updated to at least v3.0.4 it will boot from the nvme. Then on the nvme in order to boot the image only two files are involved: /boot/envU.txt, which contains a line with bootcmd listing mmc0 or nvme0 and /boot/extlinux/extlinux.conf, which contains the menu entries for the boot loader.

And therein lies the problem. EFI should require none of that when U-Boot is built properly. I can boot my HiFive Unmatched from USB and NVMe without any U-Boot configuration whatsoever, only a stock build of U-Boot flashed to the on-board QSPI. But because StarFive's configuration is all broken none of that works properly on the VisionFive 2 with their U-Boot.

Although the Debian-202306 nvme image makes also partitions for the "u-boot-spl.bin.normal.out" (nvme0n1p1) and "visionfive2_fw_payload.img" (nvme0n1p2) OpenSBI boot process, only the version flashed onto the QSPI flash of the VisionFive 2 will be used and from the nvme will only be called nvme0n1p3 /boot/ directory with the kernel and boot menu entries.

[ThomasKorimort]

And therein lies the problem. EFI should require none of that when U-Boot is built properly. I can boot my HiFive Unmatched from USB and NVMe without any U-Boot configuration whatsoever, only a stock build of U-Boot flashed to the on-board QSPI. But because StarFive's configuration is all broken none of that works properly on the VisionFive 2 with their U-Boot.

You are just obstructing the issue here. As an embedded device with custom boot ROM, OpenSBI bootloader firmware (https://www.scs.stanford.edu/~zyedidia/docs/riscv/riscv-sbi.pdf, https://crvf2019.github.io/pdf/43.pdf) is applied prior to U-Boot bootloader (https://en.wikipedia.org/wiki/Bootloader). The boot sequence for the RISC-V VisionFive 2 is ZSBL -> U-Boot SPL -> OpenSBI -> U-Boot proper -> linux kernel /boot/. The procedure i described is working as it should. USB Boot is not yet working in the upstream u-boot #64, but nvme boot works via the QSPI flash boot mode. There are four mode switches on the VisionFive 2 board 00. QSPI flash, 01. SDIO, 10. eMMC 11. UART debug. In order to use nvme boot, one needs to put the mode switch to QSPI boot mode and flash the QSPI flash with v3.0.4 "u-boot-spl.bin.normal.out" (/dev/mtd0) and "visionfive2_fw_payload.img" (/dev/mtd1) files. In Debian-202306 image this can be done via flashcp util from the mtdutils package:

sudo apt install mtd-utils
sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
sudo flashcp -v visionfive2_fw_payload.img /dev/mtd1

[jrtc27]

And therein lies the problem. EFI should require none of that when U-Boot is built properly. I can boot my HiFive Unmatched from USB and NVMe without any U-Boot configuration whatsoever, only a stock build of U-Boot flashed to the on-board QSPI. But because StarFive's configuration is all broken none of that works properly on the VisionFive 2 with their U-Boot.

You are just obstructing the issue here. The procedure i described is working as it should. USB Boot is not yet working in the upstream u-boot #64, but nvme boot works via the QSPI flash boot mode. There are four mode switches on the VisionFive 2 board 00. QSPI flash, 01. SDIO, 10. eMMC 11. UART debug. In order to use nvme boot, one needs to put the mode switch to QSPI boot mode and flash the QSPI flash with v3.0.4 "u-boot-spl.bin.normal.out" (/dev/mtd0) and "visionfive2_fw_payload.img" (/dev/mtd1) files. In Debian-202306 image this can be done via flashcp util from the mtdutils package:

sudo apt install mtd-utils sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0 sudo flashcp -v visionfive2_fw_payload.img /dev/mtd1

I flashed v3.1.5 and it tries to boot from mmc0 then dhcp and fails. In QSPI boot mode, 00, the opposite of UART boot mode, 11, which I use to flash the firmware in the first place. No other U-Boot configuration is present. That is the bug I'm reporting that others have confirmed. That should work, and would work if the built-in configuration weren't broken, but it is, so it doesn't work. I am not "obstructing the issue", I am the one who reported the issue. You're the one coming in here telling me I'm wrong and should be doing other things when the whole point is that I shouldn't have to do those things.

[ThomasKorimort]

I flashed v3.1.5 and it tries to boot from mmc0 then dhcp and fails. In QSPI boot mode, 00, the opposite of UART boot mode, 11, which I use to flash the firmware in the first place. No other U-Boot configuration is present. That is the bug I'm reporting that others have confirmed. That should work, and would work if the built-in configuration weren't broken, but it is, so it doesn't work. I am not "obstructing the issue", I am the one who reported the issue. You're the one coming in here telling me I'm wrong and should be doing other things when the whole point is that I shouldn't have to do those things.

First, how can you flash v3.1.5, when the v3.1.5 payload file is not provided from the github resources (https://github.com/starfive-tech/VisionFive2/releases/)? Then, i had the same problem at first, that the QSPI flash firmware had to be updated from factory settings to at least v3.0.4 SPL (then it would boot from nvme) and payload.

You have to also be sure, that on your nvme, you installed the Debian-202306 nvme image version, as this links the root directory to the proper drive (nvme0n1p4) then in the U-Boot config in /boot/extlinux/extlinux.conf . (https://jamesachambers.com/starfive-visionfive-2-debian-ssd-boot-guide/)

[jrtc27]

I flashed v3.1.5 and it tries to boot from mmc0 then dhcp and fails. In QSPI boot mode, 00, the opposite of UART boot mode, 11, which I use to flash the firmware in the first place. No other U-Boot configuration is present. That is the bug I'm reporting that others have confirmed. That should work, and would work if the built-in configuration weren't broken, but it is, so it doesn't work. I am not "obstructing the issue", I am the one who reported the issue. You're the one coming in here telling me I'm wrong and should be doing other things when the whole point is that I shouldn't have to do those things.

First, how can you flash v3.1.5, when the v3.1.5 payload file is not provided from the github resources (https://github.com/starfive-tech/VisionFive2/releases/)?

Did you click “Show all 13 assets” at the bottom? It’s right there.

Then, i had the same problem at first, that the QSPI flash firmware had to be updated from factory settings to at least v3.0.4 SPL (then it would boot from nvme) and payload.

You have to also be sure, that on your nvme, you installed the Debian-202306 nvme image version, as this links the root directory to the proper drive (nvme0n1p4) then in the U-Boot config in /boot/extlinux/extlinux.conf . (https://jamesachambers.com/starfive-visionfive-2-debian-ssd-boot-guide/)

Which isn’t using EFI. I am trying to use EFI, which is supposed to work, without any U-Boot-specific configuration. To boot an OS other than Debian. Hence me saying that the firmware is broken, and more so than it used to be, since it used to be able to boot from the SD card at least, but even that is now broken for EFI booting. If you don’t know what you’re talking about, fine, but please don’t come in here telling me all the ways I’m wrong when it’s clear you’ve not read and understood the existing contents of this issue.

[ThomasKorimort]

Which isn’t using EFI. I am trying to use EFI, which is supposed to work, without any U-Boot-specific configuration. To boot an OS other than Debian. Hence me saying that the firmware is broken, and more so than it used to be, since it used to be able to boot from the SD card at least, but even that is broken for EFI booting. If you don’t know what you’re talking about, fine, but please don’t come in here telling me all the ways I’m wrong when it’s clear you’ve not read and understood the existing contents of this issue.

Ok, i understand you. I have three Raspberry Pi 4B computers in my home network and it is not even possible to activate routing functionality in the Raspberry Pi OS kernel. That is because of a high amount of corruption and sabotage even amongst the open-source (kernel) developer community. I bought the Vision Five 2 to evaluate the situation there, as the RISC-V design is open-source. The weak point of the Vision Five 2 RISC platform is the ZSBL (Zero Stage boot loader in ROM), which might be already manipulated to not work with a custom-made firmware, but that cannot be afforded by as how the board was announced. Then, if the ZSBL bootloader is unbiased, the further boot procedure is:

ZSBL -> U-Boot SPL -> OpenSBI -> U-Boot proper -> linux kernel /boot/ (see e.g. https://www.scs.stanford.edu/~zyedidia/docs/riscv/riscv-sbi.pdf, https://crvf2019.github.io/pdf/43.pdf) is applied prior to U-Boot bootloader (https://en.wikipedia.org/wiki/Bootloader). The U-Boot SPL (u-boot-spl.bin.normal.out) goes onto /dev/mtd0 and the payload (visionfive2_fw_payload.img) goes onto /dev/mtd1 in the QSPI flash. If you put the v3.0.4 versions of the two files onto the QSPI flash, booting via boot switch QSPI (putting out any SD-card or other possible boot device), then the QSPI installed bootloader will start the operating system from the /boot partition. Thus the bootloader installed on the NVMe itself will not be called.

I agree with you that the boot firmware provided by StarFive is not exactly "kosher". I tried myself to compile it from the OpenSBI and U-Boot projects directly with the proper configuration files for the StarFive Vision Five 2, but could not successfully produce my own custom-made bootloader firmware hooking up directly on the ZSBL part of the ROM bootloader (which is non-flashable i guess), most likely because of my lacking experience, but i have already made a lot of experience with the systematic obstruction of open-source technology in the last few years (especially targeting people trying to make serious use of Raspberry Pi and other SoC boards). We can only hope, that this crazy way of self-destruction of all freedom and peace in our world will stop soon before everything will be broken.

[jrtc27]

Please take your tangential ramblings elsewhere, it's not on topic for this specific bug report.

[ThomasKorimort]

https://github.com/starfive-tech/edk2 . The EFI support of the Vision Five 2 platform seems to be provided by edk2. If you read into the description there of supported platforms the Vision Five 2 is not yet listed. It seems the this is a thing to do to get EFI working.

[jrtc27]

https://github.com/starfive-tech/edk2 . The EFI support of the Vision Five 2 platform seems to be provided by edk2. If you read into the description there of supported platforms the Vision Five 2 is not yet listed. It seems the this is a thing to do to get EFI working.

No it's not, that's a separate thing. EDK2 is the reference open-source implementation of the full-blown EFI spec, but U-Boot provides a minimal implementation of the parts that are needed for bootloaders to work (conforming to Arm's EBBR spec, which documents what parts of EFI need to be present). Please, if you have nothing of value to add to this discussion, don't, it's just cluttering up the issue with irrelevant comments that detract from the actual meaningful technical discussion earlier.

[ThomasKorimort]

No it's not, that's a separate thing. EDK2 is the reference open-source implementation of the full-blown EFI spec, but U-Boot provides a minimal implementation of the parts that are needed for bootloaders to work (conforming to Arm's EBBR spec, which documents what parts of EFI need to be present). Please, if you have nothing of value to add to this discussion, don't, it's just cluttering up the issue with irrelevant comments that detract from the actual meaningful technical discussion earlier.

UEFI is a x64 standard and it is available on ARM, but not RISC-V, says the U-Boot manual (https://u-boot.readthedocs.io/en/v2021.04/uefi/uefi.html). U-Boot is a specifically designed bootloader for embedded platforms, where there is no standardized BIOS boot procedure available. Thus you wanting EFI boot on the Vision Five 2 is a little bit going with the church around the cross. So, i guess the thing to do is to wait for edk2 supporting the Vision Five 2. As it is already included in the Star Five source tree chances are high that it will be working for the Vision Five 2 some time soon.

[jrtc27]

No it's not, that's a separate thing. EDK2 is the reference open-source implementation of the full-blown EFI spec, but U-Boot provides a minimal implementation of the parts that are needed for bootloaders to work (conforming to Arm's EBBR spec, which documents what parts of EFI need to be present). Please, if you have nothing of value to add to this discussion, don't, it's just cluttering up the issue with irrelevant comments that detract from the actual meaningful technical discussion earlier.

UEFI is a x64 standard

No, has it its origins in Itanium, was later adopted for x86 and then spread to other architectures.

and it is available on ARM, but not RISC-V, says the U-Boot manual (https://u-boot.readthedocs.io/en/v2021.04/uefi/uefi.html).

The manual just doesn't mention that it supports RISC-V. But I promise you it does. It's worked on my HiFive Unmatched for years, and it used to work for booting off the SD card on the VisionFive 2 in older firmware versions.

U-Boot is a specifically designed bootloader for embedded platforms, where there is no standardized BIOS boot procedure available.

It exists to provide a sensible boot procedure.

Thus you wanting EFI boot on the Vision Five 2 is a little bit going with the church around the cross.

No. It allows any random embedded board to follow a standard that means you can just download an OS and boot it, no messing with board-specific config needed. This is why Arm's EBBR spec exists and is being adopted for RISC-V.

So, i guess the thing to do is to wait for edk2 supporting the Vision Five 2.

No it's not. I just need the U-Boot configuration to search the right devices. That is it. The EFI part is already there and working if it's told the right device. But it doesn't find the device automatically because that part of the config is broken.

As it is already included in the Star Five source tree chances are high that it will be working for the Vision Five 2 some time soon.

EDK2 for RISC-V is a long way off, and totally unnecessary for this use case.

So, please, stop. I know what I'm talking about, which is why my bug report is very specific in pointing out the exact problem. It is clear you do not, and your contributions are not helping. I am asking you one final time to go away and stop spamming this thread with your ill-informed and irrelevant comments.

[ThomasKorimort]

When i did research on how to boot from NVMe, i found somewhere that some kind of "pci enum" setting would solve the problem in some configuration file (https://forum.rvspace.org/t/nvme-boot-using-visionfive2-software-v2-11-5/2464/5), which would be parsed and could be used even to be stored in the QSPI flash later. But then i decided to simply boot from SD and install the nvme Debian-202306 image through the system running from SD.

So, please, stop. I know what I'm talking about, which is why my bug report is very specific in pointing out the exact problem. It is clear you do not, and your contributions are not helping. I am asking you one final time to go away and stop spamming this thread with your ill-informed and irrelevant comments.

I am not uninformed, just seeing things from a different viewpoint, which focuses on the success of the Vision Five 2 platform, not its demise before it can even grow to full functionality.

[misuzu]

Upstream u-boot has support for NVMe since v2023.10-rc2, I haven't been able to actually use it though, see here #72

[X547]

UEFI is a x64 standard and it is available on ARM, but not RISC-V, says the U-Boot manual (https://u-boot.readthedocs.io/en/v2021.04/uefi/uefi.html). U-Boot is a specifically designed bootloader for embedded platforms, where there is no standardized BIOS boot procedure available.

UEFI is of course available for RISC-V and supported by U-Boot. You do not need EDK 2 to have UEFI support. I run Haiku operating system installed on NVMe with EFI boot method with default VisionFive2 firmware on QSPI: https://forum.rvspace.org/t/progress-on-running-haiku-on-visionfive-2/2708.

Recently I also managed to run Haiku from SD card, of course with EFI.