[PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot####
Ilias Apalodimas
ilias.apalodimas at linaro.org
Fri Mar 12 05:10:29 CET 2021
Akashi-san,
On Fri, Mar 12, 2021 at 11:50:32AM +0900, AKASHI Takahiro wrote:
> Ilias,
>
> I may have missed your past discussions, but any way,
It's on the boot-architecture mailing list [1]
>
> On Thu, Mar 11, 2021 at 01:36:04PM +0200, Ilias Apalodimas wrote:
> > >
[...]
> > > My understanding is that we have:
> > >
> > > kernel path,end(0xff),
> > > VenMedia(), /* no end node here */
> > > initrd1, end(0x01),
> > > initrd2, end(0xff)
> >
> > No, the structure is added in cmd/efidebug.c code.
> > It's created with efi_dp_append_instance() on
> > - const struct efi_initrd_dp id_dp
> > - file path of initrd
> >
> > which will create:
> > kernel path,end(0xff),
> > VenMedia(), end(0x01),
> > initrd1, end(0x01),
> > initrd2, end(0xff)
>
> What is the difference between end(0xff) and end(0x01)?
>
0xff is a subtype of 'end the entire device path', while 0x01 is an 'end of
instance of a device path and start a new device path'
> If the first argument of a load option is a list of device paths,
> I would expect the format would look like:
> kernel path,end(0xff),
> VenMedia(INITRD),initrd1 path,end(0xff),
> VenMedia(INITRD),initrd2 path,end(0xff),
>
> so that VenMedia can work as an identify of the succeeding path.
> Is it simple enough, isn't it?
It's essentially the same thing. It has an effect on the EFI spec and how you
interpret it, but honestly it feels as an implementation detail to me, since
none of those are standardized anyway.
In fact what you are saying was part of my proposal in the original mail
(check proposal 1.)
Anyway the difference between the two is that what I coded looks like this:
FilePathList[0] -> kernel
FilePathList[1] -> initrd1 - initrdn
while whe other is
FilePathList[0] -> kernel
FilePathList[1] -> initrd1
FilePathList[2] -> initrd2
FilePathList[n] -> initrdn
If we ever manage to wire in the DTBs in there as well it may look like:
FilePathList[0] -> kernel
FilePathList[1] -> initrd1 - initrdn
FilePathList[2] -> dtb1 - dtbn
Vs
FilePathList[0] -> kernel
FilePathList[1] -> initrd1
FilePathList[2] -> initrd2
FilePathList[3] -> dtb1
FilePathList[n] -> initrdn
FilePathList[n+1] -> dtb2
>
> -Takahiro Akashi
>
> > I know I originally proposed the one you have, but it seemed cleaner adding
> > an extra instance between VenMedia and the first initrd.
> >
> > >
> > > Please, document the structure.
> > >
> >
> > Sure
> >
> > > Best regards
> > >
> > > Heinrich
> >
> > Thanks
> > /Ilias
[1] https://lists.linaro.org/pipermail/boot-architecture/2021-February/001686.html
Cheers
/Ilias
More information about the U-Boot
mailing list