On Fri, Mar 12, 2021 at 06:42:14AM +0200, Ilias Apalodimas wrote: > On Fri, Mar 12, 2021 at 01:32:50PM +0900, AKASHI Takahiro 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 I correctly remember, you had some discussions about this point that UEFI specification is ambiguous here. Right? > > > > > > > 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 > > > > 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? -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
