On Sat, Dec 9, 2023 at 4:26 PM Shantur Rathore <i...@shantur.com> wrote: > > Hi Peter, > > On Wed, Dec 6, 2023 at 12:16 PM Peter Robinson <pbrobin...@gmail.com> wrote: > > > > On Sun, Nov 19, 2023 at 6:55 PM Mark Kettenis <mark.kette...@xs4all.nl> > > wrote: > > > > > > > Date: Sat, 18 Nov 2023 23:52:11 +0100 > > > > From: Heinrich Schuchardt <heinrich.schucha...@canonical.com> > > > > > > Hi Heinrich, > > > > > > > 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. > > > > > > I agree that adding hacks like this is not a good idea. > > > > > > The Linaro approach that involves OP-TEE makes for a fairly complex > > > solution. And there are plenty of boards that have neither eMMC nor > > > SPI flash. If Secure Boot is not a requirement (and I'd argue that > > > for most "hobbyist" boards it isn't) storing the EFI variables in a > > > file on the ESP (as implemented by the CONFIG_EFI_VARIABLE_FILE_STORE > > > Kconfig option) is a workable alternative. And this is actually what > > > the rockpro64-rk3399_defconfig enables. > > > > > > I noticed that the latest EBBR attempts to standardize this: > > > > > > > > > https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage > > > > > > Not sure what the status here is. But if the Linux kernel folks > > > accept that alternative implementations for runtime EFI variable > > > access are a thing, then a method that modifies the file would be > > > possible as well. Or maybe it is good enough to implement support for > > > this in the efivar library. > > > > > > That said, Linux distros probably should install their EFI bootloader > > > as EFI/BOOT/BOOTxxxx.EFI if that file doesn't exist yet. Some Linux > > > distros already do this. This would make the distro work "out of the > > > box" on a lot more boards. > > > > I believe the EFI/BOOT/BOOTxxxx.EFI is the EFI fallback mechanism (not > > sure it that's the proper spec name but it's what I've heard it > > referred to) and tha's the way Fedora generally works to boot devices > > that don't have working set variable where the boot entry can be > > updated. I had assumed that was part of the standard as, at least in > > Fedora, that has always been there and explicitly the way we made UEFI > > work on U-Boot from the outset. > > This is definitely the standard for Removable Storage as per the spec. > Section 3.5.1.1 Removable Media Boot Behavior - Link [0] > > [0] - https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf > > But the spec isn't stopping the firmware to perform scan to be able to list > the possible bootable EFIs, in-fact it says firmware can do special things as > in > Section 3.4.3 Boot Option Variables Default Boot Behavior > > @Simon Glass - If one was to implement such a scanning behaviour ( > knowing it might not be > merged ), how should one go about this? > > As I understand, the bootmeth_efi is expected to provide only 1 > bootflow for a partition, what would > be the best way for bootmeth_efi to provide multiple bootflows for > each partition. > > Kind regards, > Shantur
Throwing spanner in the works, with Unified Kernel Image coming in, it will be required to implement the scanning for EFI files. https://github.com/uapi-group/specifications/blob/main/specs/boot_loader_specification.md#locating-boot-entries Kind regards, Shantur