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 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) if you want different combinations of kernel/initrds (as described in a) you can add another Boot#### variable. 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. 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
