From mboxrd@z Thu Jan 1 00:00:00 1970 From: AKASHI Takahiro Date: Fri, 12 Mar 2021 13:32:50 +0900 Subject: [PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot#### In-Reply-To: References: <20210305222303.2866284-1-ilias.apalodimas@linaro.org> <20210305222303.2866284-2-ilias.apalodimas@linaro.org> <3b72f7c0-5fc5-5dc9-c93f-43c40de9bdd4@gmx.de> <3c7bca26-b4d6-88c5-611a-aaca1f224d39@gmx.de> <20210312025032.GA15112@laputa> Message-ID: <20210312043250.GB15112@laputa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Mar 12, 2021 at 06:10:29AM +0200, Ilias Apalodimas wrote: > 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 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.) -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