On Thu, 20 Feb 2020 at 15:56, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: > > > > On 2/20/20 12:06 PM, Ard Biesheuvel wrote: > > After having added new ways to load the initrd and the mixed mode kernel, > > we will need to tell the loader about this, so it can use the new, generic > > method if supported, and fall back to the existing method(s) otherwise. > > > > This is an RFC - if there are better ways to record this in the image > > somehow, please shout. > > > Hello Ard, > > for boot loaders like GRUB I understand that the boot loader could use > the initrd file path from its scripts to prepare a > EFI_LOAD_FILE2_PROTOCOL matching the loaded kernel. > > I am not sure about the requirements for a firmware. > > Up to now the U-Boot UEFI sub-system does not care about initial RAM > disk images at all. With Ilias suggested patch series U-Boot could offer > a file from a fixed file location via a EFI_LOAD_FILE2_PROTOCOL. > > Is there anything else you expect a firmware like U-Boot or EDK2 to do? > It highly depends on the use case. The distros really want GRUB, but others really don't want GRUB (like Ilias). There are other use cases we are considering where the initrd load is just a memcpy() from NOR flash. Given that the u-boot EFI subsystem was originally conceived to be able to run GRUB, you might see them as complimentary, but one of the things I am trying to do is ensure that GRUB is not essential for booting, even taking things like UEFI secure boot and measure boot into account. Currently, on x86, these are all tied together in a way that is hard to extrapolate to other architectures.
