* [PATCH v2 0/2] docs: admin-guide: EFI Boot Stub @ 2020-10-03 6:37 ` Heinrich Schuchardt 0 siblings, 0 replies; 12+ messages in thread From: Heinrich Schuchardt @ 2020-10-03 6:37 UTC (permalink / raw) To: Ard Biesheuvel Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-efi, linux-doc, linux-kernel, linux-riscv, Atish Patra, Heinrich Schuchardt Describe the passing of the device tree and the initial RAM disk to the EFI Boot Stub. Describe the handoff to the main Linux kernel. The links given here provide the necessary information about structures like boot_params that have to be filled by the EFI stub. So we don't have to describe them in the admin-guide. Heinrich Schuchardt (2): docs: admin-guide: fdt and initrd load in EFI stub docs: admin-guide: EFI stub to main Linux handoff Documentation/admin-guide/efi-stub.rst | 47 ++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) -- 2.28.0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 0/2] docs: admin-guide: EFI Boot Stub @ 2020-10-03 6:37 ` Heinrich Schuchardt 0 siblings, 0 replies; 12+ messages in thread From: Heinrich Schuchardt @ 2020-10-03 6:37 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi, Atish Patra, linux-doc, Heinrich Schuchardt, Jonathan Corbet, linux-kernel, Albert Ou, Palmer Dabbelt, Paul Walmsley, linux-riscv Describe the passing of the device tree and the initial RAM disk to the EFI Boot Stub. Describe the handoff to the main Linux kernel. The links given here provide the necessary information about structures like boot_params that have to be filled by the EFI stub. So we don't have to describe them in the admin-guide. Heinrich Schuchardt (2): docs: admin-guide: fdt and initrd load in EFI stub docs: admin-guide: EFI stub to main Linux handoff Documentation/admin-guide/efi-stub.rst | 47 ++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) -- 2.28.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub 2020-10-03 6:37 ` Heinrich Schuchardt @ 2020-10-03 6:37 ` Heinrich Schuchardt -1 siblings, 0 replies; 12+ messages in thread From: Heinrich Schuchardt @ 2020-10-03 6:37 UTC (permalink / raw) To: Ard Biesheuvel Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-efi, linux-doc, linux-kernel, linux-riscv, Atish Patra, Heinrich Schuchardt 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@gmx.de> --- 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. + +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. + +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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub @ 2020-10-03 6:37 ` Heinrich Schuchardt 0 siblings, 0 replies; 12+ messages in thread From: Heinrich Schuchardt @ 2020-10-03 6:37 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi, Atish Patra, linux-doc, Heinrich Schuchardt, Jonathan Corbet, linux-kernel, Albert Ou, Palmer Dabbelt, Paul Walmsley, linux-riscv 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@gmx.de> --- 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. + +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. + +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@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub 2020-10-03 6:37 ` Heinrich Schuchardt @ 2020-10-03 7:34 ` Atish Patra -1 siblings, 0 replies; 12+ messages in thread From: Atish Patra @ 2020-10-03 7:34 UTC (permalink / raw) To: Heinrich Schuchardt, Ard Biesheuvel Cc: linux-efi, Linux Doc Mailing List, Jonathan Corbet, linux-kernel@vger.kernel.org List, Albert Ou, Palmer Dabbelt, Paul Walmsley, linux-riscv On Fri, Oct 2, 2020 at 11:38 PM Heinrich Schuchardt <xypron.glpk@gmx.de> 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@gmx.de> > --- > 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? For example, It's recommended to use the LoadFile method for RISC-V and new ARM systems. Existing ARM ones will continue to use the initrd argument as that's the method enabled by default. > +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 ? > +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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub @ 2020-10-03 7:34 ` Atish Patra 0 siblings, 0 replies; 12+ messages in thread From: Atish Patra @ 2020-10-03 7:34 UTC (permalink / raw) To: Heinrich Schuchardt, Ard Biesheuvel Cc: linux-efi, Jonathan Corbet, Linux Doc Mailing List, linux-kernel@vger.kernel.org List, Albert Ou, Palmer Dabbelt, Paul Walmsley, linux-riscv On Fri, Oct 2, 2020 at 11:38 PM Heinrich Schuchardt <xypron.glpk@gmx.de> 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@gmx.de> > --- > 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? For example, It's recommended to use the LoadFile method for RISC-V and new ARM systems. Existing ARM ones will continue to use the initrd argument as that's the method enabled by default. > +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 ? > +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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub 2020-10-03 7:34 ` Atish Patra @ 2020-10-03 8:28 ` Heinrich Schuchardt -1 siblings, 0 replies; 12+ messages in thread From: Heinrich Schuchardt @ 2020-10-03 8:28 UTC (permalink / raw) To: Atish Patra, Ard Biesheuvel Cc: linux-efi, Linux Doc Mailing List, Jonathan Corbet, linux-kernel@vger.kernel.org List, Albert Ou, Palmer Dabbelt, Paul Walmsley, linux-riscv On 03.10.20 09:34, Atish Patra wrote: > On Fri, Oct 2, 2020 at 11:38 PM Heinrich Schuchardt <xypron.glpk@gmx.de> 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@gmx.de> >> --- >> 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. > > 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. > 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. 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@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub @ 2020-10-03 8:28 ` Heinrich Schuchardt 0 siblings, 0 replies; 12+ messages in thread From: Heinrich Schuchardt @ 2020-10-03 8:28 UTC (permalink / raw) To: Atish Patra, Ard Biesheuvel Cc: linux-efi, Jonathan Corbet, Linux Doc Mailing List, linux-kernel@vger.kernel.org List, Albert Ou, Palmer Dabbelt, Paul Walmsley, linux-riscv On 03.10.20 09:34, Atish Patra wrote: > On Fri, Oct 2, 2020 at 11:38 PM Heinrich Schuchardt <xypron.glpk@gmx.de> 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@gmx.de> >> --- >> 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. > > 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. > 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. 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@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub 2020-10-03 8:28 ` Heinrich Schuchardt @ 2020-10-03 17:16 ` Atish Patra -1 siblings, 0 replies; 12+ messages in thread From: Atish Patra @ 2020-10-03 17:16 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Ard Biesheuvel, linux-efi, Linux Doc Mailing List, Jonathan Corbet, linux-kernel@vger.kernel.org List, Albert Ou, Palmer Dabbelt, Paul Walmsley, linux-riscv On Sat, Oct 3, 2020 at 1:29 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > On 03.10.20 09:34, Atish Patra wrote: > > On Fri, Oct 2, 2020 at 11:38 PM Heinrich Schuchardt <xypron.glpk@gmx.de> 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@gmx.de> > >> --- > >> 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@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > -- Regards, Atish ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub @ 2020-10-03 17:16 ` Atish Patra 0 siblings, 0 replies; 12+ messages in thread From: Atish Patra @ 2020-10-03 17:16 UTC (permalink / raw) To: Heinrich Schuchardt Cc: Albert Ou, Jonathan Corbet, Linux Doc Mailing List, linux-kernel@vger.kernel.org List, linux-efi, Palmer Dabbelt, Paul Walmsley, linux-riscv, Ard Biesheuvel On Sat, Oct 3, 2020 at 1:29 AM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > On 03.10.20 09:34, Atish Patra wrote: > > On Fri, Oct 2, 2020 at 11:38 PM Heinrich Schuchardt <xypron.glpk@gmx.de> 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@gmx.de> > >> --- > >> 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@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > -- Regards, Atish _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 2/2] docs: admin-guide: EFI stub to main Linux handoff 2020-10-03 6:37 ` Heinrich Schuchardt @ 2020-10-03 6:37 ` Heinrich Schuchardt -1 siblings, 0 replies; 12+ messages in thread From: Heinrich Schuchardt @ 2020-10-03 6:37 UTC (permalink / raw) To: Ard Biesheuvel Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-efi, linux-doc, linux-kernel, linux-riscv, Atish Patra, Heinrich Schuchardt Describe the handoff from the EFI stub to the main Linux kernel. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> --- v2: new patch --- Documentation/admin-guide/efi-stub.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Documentation/admin-guide/efi-stub.rst b/Documentation/admin-guide/efi-stub.rst index 4965dec48af4..669602ff4515 100644 --- a/Documentation/admin-guide/efi-stub.rst +++ b/Documentation/admin-guide/efi-stub.rst @@ -133,3 +133,15 @@ described above. This option is only available if CONFIG_EFI_ARMSTUB_DTB_LOADER=y and secure boot is disabled. + +Handoff to main Linux kernel +---------------------------- + +Currently the EFI stub enters the main Linux kernel via the same entry points +that are used when booting without UEFI. This might change in future versions. +For a description of these entry points see: + +* for arm :doc:`/arm/booting` +* for arm64 :doc:`/arm64/booting` +* for riscv :doc:`/riscv/index` +* for x86 :doc:`/x86/boot` -- 2.28.0 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v2 2/2] docs: admin-guide: EFI stub to main Linux handoff @ 2020-10-03 6:37 ` Heinrich Schuchardt 0 siblings, 0 replies; 12+ messages in thread From: Heinrich Schuchardt @ 2020-10-03 6:37 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi, Atish Patra, linux-doc, Heinrich Schuchardt, Jonathan Corbet, linux-kernel, Albert Ou, Palmer Dabbelt, Paul Walmsley, linux-riscv Describe the handoff from the EFI stub to the main Linux kernel. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> --- v2: new patch --- Documentation/admin-guide/efi-stub.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Documentation/admin-guide/efi-stub.rst b/Documentation/admin-guide/efi-stub.rst index 4965dec48af4..669602ff4515 100644 --- a/Documentation/admin-guide/efi-stub.rst +++ b/Documentation/admin-guide/efi-stub.rst @@ -133,3 +133,15 @@ described above. This option is only available if CONFIG_EFI_ARMSTUB_DTB_LOADER=y and secure boot is disabled. + +Handoff to main Linux kernel +---------------------------- + +Currently the EFI stub enters the main Linux kernel via the same entry points +that are used when booting without UEFI. This might change in future versions. +For a description of these entry points see: + +* for arm :doc:`/arm/booting` +* for arm64 :doc:`/arm64/booting` +* for riscv :doc:`/riscv/index` +* for x86 :doc:`/x86/boot` -- 2.28.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-10-03 17:17 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-03 6:37 [PATCH v2 0/2] docs: admin-guide: EFI Boot Stub Heinrich Schuchardt 2020-10-03 6:37 ` Heinrich Schuchardt 2020-10-03 6:37 ` [PATCH v2 1/2] docs: admin-guide: fdt and initrd load in EFI stub Heinrich Schuchardt 2020-10-03 6:37 ` Heinrich Schuchardt 2020-10-03 7:34 ` Atish Patra 2020-10-03 7:34 ` Atish Patra 2020-10-03 8:28 ` Heinrich Schuchardt 2020-10-03 8:28 ` Heinrich Schuchardt 2020-10-03 17:16 ` Atish Patra 2020-10-03 17:16 ` Atish Patra 2020-10-03 6:37 ` [PATCH v2 2/2] docs: admin-guide: EFI stub to main Linux handoff Heinrich Schuchardt 2020-10-03 6:37 ` Heinrich Schuchardt
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.