Hi Heinrich, On Sat, 18 Nov 2023 at 15:52, Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > On 11/18/23 22:28, Shantur Rathore wrote: > > 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. > > As mentioned in a prior mail ubuntu/bootxxxx.efi and debian/bootxxxx.efi > don't exist. I would prefer not to add any distro specific stuff in > upstream U-Boot. Instead we will continue to drive what Linaro has > suggested to improve U-Boot EFI variables support in Linux.
Is there any metadata in the distro which U-Boot could read to find out where the EFI file is? Regards, Simon