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.


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.

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/

Best regards

Heinrich

Reply via email to