From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Sun, 14 Mar 2021 11:02:40 +0200
Subject: [PATCH 6/6 v2] doc: Update uefi documentation for initrd loading
 options
In-Reply-To: <8a5a1bc6-ff36-beca-25fe-7bd097c54708@gmx.de>
References: <20210313214738.3257922-1-ilias.apalodimas@linaro.org>
 <20210313214738.3257922-7-ilias.apalodimas@linaro.org>
 <8a5a1bc6-ff36-beca-25fe-7bd097c54708@gmx.de>
Message-ID: <CAC_iWjLZmAC9X3iyg1UonpoBj3rNvo5qJDZsT7s5xSO+r8CJVw@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Sun, 14 Mar 2021 at 09:53, Heinrich Schuchardt <xypron.glpk@gmx.de>
wrote:

> On 3/13/21 10:47 PM, Ilias Apalodimas wrote:
> > Document the command line options for efidebug and initrd loading
> >
> > Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> > ---
> >   doc/uefi/uefi.rst | 21 ++++++++++++++++++++-
> >   1 file changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/uefi/uefi.rst b/doc/uefi/uefi.rst
> > index b3494c22e073..76402bc5cfaa 100644
> > --- a/doc/uefi/uefi.rst
> > +++ b/doc/uefi/uefi.rst
> > @@ -180,6 +180,12 @@ Set up boot parameters on your board::
> >
> >       efidebug boot add -b 1 HELLO mmc 0:1 /helloworld.efi.signed ""
> >
> > +Since kernel 5.7 there's an alternative way of loading an initrd using
> > +LoadFile2 protocol if CONFIG_EFI_LOAD_FILE2_INITRD is enabled.
> > +The initrd path can be specified with::
> > +
> > +    efidebug boot add -b ABE0 'kernel' mmc 0:1 Image -i mmc 0:1 initrd
> > +
> >   Now your board can run the signed image via the boot manager (see
> below).
> >   You can also try this sequence by running Pytest, test_efi_secboot,
> >   on the sandbox
> > @@ -484,7 +490,20 @@ The load file 2 protocol can be used by the Linux
> kernel to load the initial
> >   RAM disk. U-Boot can be configured to provide an implementation with::
> >
> >       EFI_LOAD_FILE2_INITRD=y
> > -    EFI_INITRD_FILESPEC=interface dev:part path_to_initrd
>
> Thanks for adding the description. Some nitpicky comments below:
>
> > +
> > +When the options is enabled the user can add the initrd path with the
> efidebug
>
> %s/options/option/
>
> > +command.
> > +The Boot#### option has a FilePathList[] in it's EFI_LOAD_OPTION.
>
> Load options Boot#### have a FilePathList[] member.
>
> > +The first element of the array (FilePathList[0]) is the loded image.
>
> is the EFI binary to execute.
>
> > +When an initrd is specified the Device Path for the initrd is denoted
> by a
> > +VenMedia node with the EFI_INITRD_MEDIA_GUID. Each entry of the array is
> > +terminated by the 'end of entire device path' subtype. If the user
> wants to
>
> Below you have (0x01). So add (0xff) here.
>
> > +define multiple initrds those must by separated by the 'end of this
> instance'
>
> %s/initrds/initrds,/
>
> > +identifier of the end node (0x01).
> > +
> > +So our final format of the FilePathList[] is::
> > +
> > +    Loaded image - end node (0xff) - VenMedia - initrd1 - end node
> (0x01) initrd2 - end node (0xff)
>
> Loaded image - end node (0xff) - VenMedia - initrd_1 -
> [end node (0x01) - initrd_n ...] - end node (0xff)
>
> There can be any number of initrds?
>

I dont see any limitation on the spec.

>
> Best regards
>
> Heinrich
>
> >
> >   Links
> >   -----
> >
>