mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "Jonathan Corbet" <corbet@lwn.net>,
	linux-efi <linux-efi@vger.kernel.org>,
	"Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"François Ozog" <francois.ozog@linaro.org>,
	"Ilias Apalodimas" <ilias.apalodimas@linaro.org>
Subject: Re: [PATCH 1/1] docs: admin-guide: fdt and initrd load in EFI stub
Date: Fri, 2 Oct 2020 21:14:27 +0200	[thread overview]
Message-ID: <9899cc58-c856-38ca-3a89-4b545c973a4f@gmx.de> (raw)
In-Reply-To: <CAMj1kXHsGcAX-DqfcpgxzZY3M+JzY-Ef9OdJ+JdysNnx1fK6zg@mail.gmail.com>

On 10/2/20 7:21 PM, Ard Biesheuvel wrote:
> Hi Heinrich,
>
> Thanks for documenting this.
>
>
> On Fri, 2 Oct 2020 at 19:11, 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>
>> ---
>>  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..86f50a33884c 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.
>> +* 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.
>> +
>
> On x86, the boot_params struct is used to pass the address and size of
> the initrd in memory. Maybe include that for completeness?

On x86 boot_params is set in function efi_pe_entry() after loading the
file indicated by the initrd= command line.

boot_params is not accessible by a caller of the EFI stub but is a
structure used at the interface between EFI stub and main kernel. This
interface is not in the scope of the admin-guide.

The main Linux entry point is already described in
Documentation/x86/boot.rst and ./Documentation/x86/zero-page.rst.

We can add Sphinx style documentation for function efi_pe_entry()
mentioning that it fills in boot_params.
drivers/firmware/efi/libstub/x86-stub.c then can be added to
Documentation/driver-api/firmware/efi/index.rst in an x86 chapter. But
these will be separate patches.

Best regards

Heinrich

>
>> +The first two items are inhibited by the "noinitrd" command line parameter.
>> +
>
> Interesting. Are you saying noinitrd is ignored by the kernel itself?
>
> Looking at the code, it might only work for preventing the load of old
> style initrd ramdisks, whereas initramfs images are handled
> separately.
>
> This is something that we should probably fix one way or the other.
>
>
>> +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
>>


  parent reply	other threads:[~2020-10-02 19:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 17:11 Heinrich Schuchardt
2020-10-02 17:21 ` Ard Biesheuvel
2020-10-02 17:50   ` Heinrich Schuchardt
2020-10-02 19:14   ` Heinrich Schuchardt [this message]
2020-10-02 19:21     ` Ard Biesheuvel
2020-10-02 20:04       ` Heinrich Schuchardt
2020-10-02 23:26         ` Atish Patra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9899cc58-c856-38ca-3a89-4b545c973a4f@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=ardb@kernel.org \
    --cc=corbet@lwn.net \
    --cc=francois.ozog@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®