fix the EFI path

[pdp7]

Theo de Raadt from OpenBSD contacted me:

The uboot configuration has this:

scan_dev_for_efi=if test -e ${devtype} ${devnum}:${distro_bootpart} efi/fedora/bootriscv64.efi; then echo Found EFI removable media binary efi/fedora/bootriscv64.efi; run scan_dev_for_dtb; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile

Putting /fedora/ in the path like that makes these machines only able to boot
one specific brand of Linux.

I suspect that path should be efi/boot/bootriscv64.efi

So that other operating systems stand a chance of running on this.

[jonathangray]

See the UEFI 2.9 specification 3.5.1.1:

To generate a file name when none is present in the FilePath, the firmware must
append a default file name in the form \EFI\BOOT\BOOT{machine type short-name}.EFI

The fedora patches should be dropped. For example fe93fbc 8a6805d and others which are for different architectures/socs entirely.
Fedora must have a way to handle this on amd64/arm64 machines where they do not provide the firmware.

A binary image with these reverted along with instructions would be helpful.
https://github.com/starfive-tech/freelight-u-sdk/blob/starfive/README.md seems to cover the instructions part.

It also isn't clear which repository should be used.
https://github.com/starfive-tech/freelight-u-sdk uses https://github.com/starfive-tech/sft-riscv-opensbi and https://github.com/starfive-tech/sft-riscv-uboot .
https://github.com/starfive-tech/beaglev_fedora uses https://github.com/starfive-tech/beagle_opensbi and https://github.com/starfive-tech/beagle_uboot-opensbi .

Which combination of repositories and branches were used to build the image that shipped in the spi flash of the beta boards?

There is only one repository for the earlier stages
https://github.com/starfive-tech/beagle_secondBoot https://github.com/starfive-tech/beagle_ddrlnit

[jonathangray]

https://wiki.seeedstudio.com/BeagleV-Make-File-System-Compile-uboot-Kernal/

uses the Fedora branches of https://github.com/starfive-tech/beagle_opensbi and https://github.com/starfive-tech/beagle_uboot-opensbi with manual offset changes and the result is run through https://github.com/starfive-tech/freelight-u-sdk/blob/starfive/fsz.sh

[pdp7]

@jonathangray sorry for the confusion about the repositories.

Wei Fu (@tekkamanninja) is actively cleaning this up so that there will be just a single repo each for opensbi, uboot and Linux. I will make it widely known once @tekkamanninja has finished that cleanup.

For the BeagleV beta developers, I have apost about this in the beaglev-beta forum:
https://forum.beagleboard.org/t/clarification-for-starfive-tech-repos/29535

For BeagleV beta developers that can not access that URL please email me: [email protected]

[pdp7]

@tekkamanninja tells me that this will be resolved once we get u-boot executing grub which is the eventual solution needed for Fedora. We also plan in the future to try EDK2 UEFI as well.

[tekkamanninja]

@tekkamanninja tells me that this will be resolved once we get u-boot executing grub which is the eventual solution needed for Fedora. We also plan in the future to try EDK2 UEFI as well.

Since today , we have got u-boot executing grub to boot Fedora, so let me try to explain this :

for scan_dev_for_efi, we do not use this for efi file.
the current approach is uboot will import uEnv.txt for distro boot variable, and uEnv.txt is in Image, so every distro image can have their own boot flow.
For current fedora image for BeagleV, it can execute /EFI/Fedora/grubriscv64.efi

for other distro image , we can also execute efi/boot/bootriscv64.efi by modify uEnv.txt for their own Image

[kettenis]

Reviving this thread since we're now adding support for the VisionFive board to OpenBSD.

Customizing images using uEnv.txt doesn't make any sense; the whole point of UEFI is that it allows to boot generic OS images. As a project we simply can't provide separate customized images for each and every board that hits the market. So we only provide a single generic OS image. And I suspect some of the Linux distributions are in the same boat.

While I do think that there should be no need for uEnv.txt, it should be possible to retain this feature, but simply fall back on the default distroboot boot command if no uEnv.txt file is found. I can probably help with the necessary changes in u-boot.

[X547]

Customizing images using uEnv.txt doesn't make any sense; the whole point of UEFI is that it allows to boot generic OS images. As a project we simply can't provide separate customized images for each and every board that hits the market.

The same for Haiku.

[rpx99]

I would like to see this glitch fixed, too. Thanks.