Hi Heinrich, On Fri, Nov 17, 2023 at 3:12 PM Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > On 11/16/23 19:45, Shantur Rathore wrote: > > On Thu, Nov 16, 2023 at 6:15 PM Heinrich Schuchardt > > <heinrich.schucha...@canonical.com> wrote: > >> > >> On 11/16/23 17:52, Shantur Rathore wrote: > >>> Hi Simon, > >>> > >>> Currently bootstd - bootmethod_efi only looks for the default > >>> bootxx64.efi in /EFI/boot folder only. > >>> Generally many distros end up putting their bootloaders in > >>> EFI/<distro> folders like EFI/ubuntu and EFI/debian etc. > >>> > >>> In x86 worlds, the NVRAM is modified and new boot entries are added to > >>> support these but in the U-boot world the NVRAM variables are > >>> read-only. > >> > >> I guess you are referring to UEFI boot options. These typically are not > >> stored in non-volatile RAM but on a SPI flash device. > >> > > > > Thanks for correcting me. > > > >>> > >>> What would be the best way to implement this? > >>> > >>> I was thinking of having a "efi_prefixes" environment variable which > >>> can be set to "ubuntu debian centos" etc and bootmethod_efi can try > >>> all of them. Will bootmethod_efi be able to support multiple entries ( > >>> thinking of multiboot ) ? > >> > >> On my laptop I have: > >> > >> EFI/Microsoft/Boot/bootmgr.efi > >> EFI/Microsoft/Boot/memtest.efi > >> EFI/Boot/bootx64.efi > >> EFI/Boot/fbx64.efi > >> EFI/Boot/mmx64.efi > >> EFI/debian/shimx64.efi > >> EFI/debian/grubx64.efi > >> EFI/debian/mmx64.efi > >> EFI/debian/fbx64.efi > >> EFI/ubuntu/grubx64.efi > >> EFI/ubuntu/shimx64.efi > >> EFI/ubuntu/mmx64.efi > >> > >> Obviously each installed operating system provides multiple EFI binaries > >> and non uses the fallback file name BOOT<ARCH>.EFI. A value "ubuntu > >> debian centos" would not be able to describe which file you are looking > >> for. > >> > >> We already have the U-Boot command line eficonfig and efidebug commands > >> to set up UEFI boot options which can describe which EFI binary to load > >> and which command line to pass to it. These are considered by the > >> existing boot flows. > > > > So, I am building a new RockPro64 based cluster and using Canonical > > MAAS to set them up automatically, booting them up using DHCP and > > installing them over the network. > > I configured an Armbian image using Packer to be compatible with MAAS > > and it happily installs it. As part of installation process, a > > grub-install is run which installs the grub efi, > > this EFI ends up in EFI/debian instead of expected EFI/boot. > > To be able to make it boot, I have to add commands to move it to > > EFI/boot. I am trying to find a way in U-Boot that would allow me to > > skip this step. > > With eficonfig if I understand correctly, it would need manual > > intervention to create boot entries. > > > >> > >> If you are installing the shim-signed package on Ubuntu, the EFI boot > >> option for Ubuntu is set up by EFI/BOOT/BOOT<ARCH>.EFI using the content > >> of EFI/ubuntu/BOOT<ARCH>.CSV. This is done before ExitBootServices() and > >> therefore should work with current U-Boot. > >> > >> Patches are pending upstream to make EFI variables writable from Linux > >> if they are stored in the RPMB partition in the eMMC. See this series: > >> > >> https://lore.kernel.org/linux-efi/20231107054057.1893-2-masahisa.koj...@linaro.org/ > >> > > > > Would it be possible to save it in SPI Flash as the U-Boot environment ? > > Currently this is not supported by U-Boot. > > The U-Boot environment variables can be stored in lots of different > places SPI flash is only one of these. But none of these locations is > protected from OS access which would be preferable for UEFI variables > for security reasons. > > To support boards without eMMC the right way forward would be writing a > new implementation of the OP-TEE standalone MM which writes the > variables to SPI flash instead of the RPMB partition and ensures that > the SPI flash' MMIO registers are protected against access from the > non-secure world.
Thanks for explaining this to me. This seems like a long way to go, for now what would be an acceptable solution, some options are 1. Allow to set a space separated efi_prefixes (e.g. "boot ubuntu debian") variable which is ready by bootmeth_efi and used as efi/<efi_prefix> instead of efi/boot. 2. Improve bootmeth_efi to find all bootxxxx.efi in efi/ folder and present all them as bootflows to bootstd. Kind regards, Shantur