[PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot####

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

> > > > > >  
[...]
> > > > > >  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 I correctly remember, you had some discussions about this point
> that UEFI specification is ambiguous here. Right?

Yea, just by reading it wasn't clear if the delimiter between FilePathList[]
array elements was supposed to be 0xff or 0x01.
We finally figured out the spec means 0xff though, so that's (hopefully) clear
now.

> 
[...]
> > > > 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
> > > 
> > > What is the semantics?
> > > Which do you want to do?
> > > a) boot one of combinations:
> > >      1.kernel+initrd1+dtb1, or
> > >      2.kernel+initrd2+dtb2
> > > b) boot
> > >      kernel + (initrd1 + initrd2) + (dtb1 + dtb2)
> > > 
> > > I assume you meant (a).
> > > In that case, how can you specify (a-1) or (a-2) at boot time?
> > > 
> > > Is there any clear description about that?
> > > (I"m simply asking here.)
> > 
> > it's b) 
> 
> OK.
> 
> > if you want different combinations of kernel/initrds (as described in a) you
> > can add another Boot#### variable.
> 
> Indeed.
> 
> > So let's assume you got three boot options
> > Boot0000, Boot0001 and Boot0002
> > 
> > Boot0000 efi_load_options: kernel1 + (initrd1 + initrd2) + (dtb1 + dtb2). 
> > The bootloader will concat initrd1+initrd2 when the kernel requests it.
> > Similar behavior can be coded for dtb before installing the table.
> 
> My understanding is that none of existing boot loaders has not yet
> supported such a concatenation (of either initrd or dtb) right now.
> Do you (or linux's efistub?) intend to add a new feature?

For u-boot we intend to add it in the future. I just wanted to keep the
initial patchset simpler, since 99.9% of the use cases are for a single
initrd.

The efistub doesn't have to add anything to support this, that's the whole
point of trying to standardize this.
Since there's some confusion around let me try and explain that here as well.

The EFI stub does two things.  It searches for the protocol with a specific 
DP (which includes a unique GUID). The DP our case is <VenMedia for initrd>/<end node>.
Since locate protocol will strip the first part, the stub now calls LoadFile2 
protocol with a device end node and a kernel provided buffer (and there's a 
mechanism to discover the size).
It's pretty much tells the bootloader 'gimme my initrd'.  So it's entirely up
to the bootloader to select a mechanism for discovering were those initrds
are and concatenate them


Cheers
/Ilias

> 
> -Takahiro Akashi
> 
> 
> > Boot0001: kernel1 + initrd1 + dtb1
> > Load a kernel with a single initrd and dtb.
> > 
> > Boot0002: kernel2 + initrd2 + dtb2
> > ditto.
> > 
> > Hope that's clear now
> > 
> > Cheers
> > /Ilias
> > 
> > 
> > > 
> > > -Takahiro Akashi
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > -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