On Sat, Oct 3, 2020 at 1:29 AM Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: > > On 03.10.20 09:34, Atish Patra wrote: > > On Fri, Oct 2, 2020 at 11:38 PM Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote: > >> > >> Describe how a device tree and an initial RAM disk can be passed to the EFI > >> Boot Stub. > >> > >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@xxxxxx> > >> --- > >> v2: > >> mention EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER (thx Atish) > >> --- > >> Documentation/admin-guide/efi-stub.rst | 35 ++++++++++++++++++++++++++ > >> 1 file changed, 35 insertions(+) > >> > >> diff --git a/Documentation/admin-guide/efi-stub.rst b/Documentation/admin-guide/efi-stub.rst > >> index 833edb0d0bc4..4965dec48af4 100644 > >> --- a/Documentation/admin-guide/efi-stub.rst > >> +++ b/Documentation/admin-guide/efi-stub.rst > >> @@ -38,6 +38,34 @@ arch/arm/boot/zImage should be copied to the system partition, and it > >> may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image > >> should be copied but not necessarily renamed. > >> > >> +Passing an initial RAM disk to the EFI Boot Stub > >> +------------------------------------------------ > >> + > >> +The following means sorted by decreasing priority can be used to provide an > >> +initial RAM disk to the EFI Boot Stub: > >> + > >> +* The firmware may provide a UEFI Load File 2 Protocol. The stub will try to > >> + load the RAM disk by calling the LoadFile() service of the protocol using > >> + a vendor device path with the vendor GUID > >> + 5568e427-0x68fc-4f3d-ac74-ca555231cc68. > >> +* Next the EFI stub will try to load the file indicated by the "initrd=" command > >> + line parameter if CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is enabled. > >> +* The prior boot stage may pass the location of the initial RAM disk via the > >> + "linux,initrd-start" and "linux,initrd-end" properties of the "/chosen" node > >> + of the device-tree. > >> + > > > > Should we also specify which method is enabled by default for which > > ARCH and recommended methods? > > The user relevant configuration is not the Linux' defconfig but what the > distribution maintainer has baked. I doubt mentioning Linux' defaults is > meaningful here. > Yes. But some distribution admin may think that one of these two configs (initrd or dtb) are not enabled for RISC-V by mistake and enable it in the distro config. Ard had suggested that it is best if RISC-V doesn't inherit the legacy options. > > > > For example, It's recommended to use the LoadFile method for RISC-V > > and new ARM systems. > > GRUB does not implement the LoadFile2 protocol yet. In U-Boot it is only > good for testing. I am not aware of usability with unmodified EDK II. > Why should we recommend anything before building the ecosystem that > makes it useful? > > What is best may depend on the use case. There is nothing insecure in > passing the initrd via "linux,initrd-start" and "linux,initrd-end" if > you control the load options. > > The EBBR (https://github.com/arm-software/ebbr) might be a better place > for a recommendation. > Agreed. > > Existing ARM ones will continue to use the initrd argument as that's > > the method enabled by default. > > Only if if the LoadFile2 protocol is not available because that has a > higher priority for ARM, x86, and RISC-V. > > Should I consider my i.mx6 Wandboard Quad bought in 2013 "old" while it > is running the U-Boot v2020.10-rc5, Linux v5.9-rc7, and Debian testing? > A distinction between "old" and "new" systems seems irrelevant here. All > are treated equal by the EFI stub. > > > > >> +The first two items are inhibited by the "noinitrd" command line parameter. > >> + > >> +Passing a device-tree to the EFI Boot Stub > >> +------------------------------------------ > >> + > >> +A device-tree can be passed to the EFI Boot Stub in decreasing priority using > >> + > >> +* command line option dtb= > >> +* a UEFI configuration table with GUID b1b621d5-f19c-41a5-830b-d9152c69aae0. > >> + > > > > I am just curious. Is there any specific reason why efistub tries to > > load the dtb from the command line first > > and loads from the config table only if it fails from the first approach ? > > As we disable dtb= in secure boot it would make sense to turn the > priorities around for non-secure boot too. > > But this is beyond the scope of a documentation patch. > Yes. I was just using the context to ask the question. I will send a separate patch for that. > Best regards > > Heinrich > > > > >> +The command line option is only available if CONFIG_EFI_ARMSTUB_DTB_LOADER=y > >> +and secure boot is disabled. > >> > >> Passing kernel parameters from the EFI shell > >> -------------------------------------------- > >> @@ -46,6 +74,10 @@ Arguments to the kernel can be passed after bzImage.efi, e.g.:: > >> > >> fs0:> bzImage.efi console=ttyS0 root=/dev/sda4 > >> > >> +The "noinitrd" option > >> +--------------------- > >> + > >> +The "noinitrd" option stops the EFI stub from loading an initial RAM disk. > >> > >> The "initrd=" option > >> -------------------- > >> @@ -98,3 +130,6 @@ CONFIGURATION TABLE. > >> > >> "dtb=" is processed in the same manner as the "initrd=" option that is > >> described above. > >> + > >> +This option is only available if CONFIG_EFI_ARMSTUB_DTB_LOADER=y and secure > >> +boot is disabled. > >> -- > >> 2.28.0 > >> > >> > >> _______________________________________________ > >> linux-riscv mailing list > >> linux-riscv@xxxxxxxxxxxxxxxxxxx > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > -- Regards, Atish
