All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot####
Date: Fri, 12 Mar 2021 14:02:56 +0900	[thread overview]
Message-ID: <20210312050256.GD15112@laputa> (raw)
In-Reply-To: <YErxJs+Z6zvlLfo7@apalos.home>

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

  reply	other threads:[~2021-03-12  5:02 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05 22:22 [PATCH 1/6] efi_selftest: Remove loadfile2 for initrd selftests Ilias Apalodimas
2021-03-05 22:22 ` [PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot#### Ilias Apalodimas
2021-03-11  7:50   ` Heinrich Schuchardt
2021-03-11  9:10     ` Ilias Apalodimas
2021-03-11 11:00       ` Heinrich Schuchardt
2021-03-11 11:36         ` Ilias Apalodimas
2021-03-11 11:44           ` Heinrich Schuchardt
2021-03-11 12:31             ` Heinrich Schuchardt
2021-03-11 12:39               ` Ilias Apalodimas
2021-03-11 12:44                 ` Heinrich Schuchardt
2021-03-11 12:49                   ` Ilias Apalodimas
2021-03-11 13:31             ` Ilias Apalodimas
2021-03-11 20:25               ` Heinrich Schuchardt
2021-03-12  2:50           ` AKASHI Takahiro
2021-03-12  4:10             ` Ilias Apalodimas
2021-03-12  4:32               ` AKASHI Takahiro
2021-03-12  4:42                 ` Ilias Apalodimas
2021-03-12  5:02                   ` AKASHI Takahiro [this message]
2021-03-12  5:19                     ` Ilias Apalodimas
2021-03-05 22:22 ` [PATCH 3/6] efi_loader: Introduce helper functions for EFI Ilias Apalodimas
2021-03-11  9:15   ` Heinrich Schuchardt
2021-03-05 22:23 ` [PATCH 4/6] efi_loader: Replace config option for initrd loading Ilias Apalodimas
2021-03-11 12:23   ` Heinrich Schuchardt
2021-03-11 12:30     ` Ilias Apalodimas
2021-03-11 12:50       ` Heinrich Schuchardt
2021-03-05 22:23 ` [PATCH 5/6] efidebug: add multiple device path instances on Boot#### Ilias Apalodimas
2021-03-11 12:38   ` Heinrich Schuchardt
2021-03-11 12:42     ` Ilias Apalodimas
2021-03-12  4:44   ` AKASHI Takahiro
2021-03-12  4:55     ` Ilias Apalodimas
2021-03-12  5:23       ` AKASHI Takahiro
2021-03-12  5:37         ` Ilias Apalodimas
2021-03-12  5:58           ` AKASHI Takahiro
2021-03-12  7:19             ` Ilias Apalodimas
2021-03-12 16:25     ` Heinrich Schuchardt
2021-03-05 22:23 ` [PATCH 6/6] doc: Update uefi documentation for initrd loading options Ilias Apalodimas
2021-03-11 12:39   ` Heinrich Schuchardt
2021-03-11  7:26 ` [PATCH 1/6] efi_selftest: Remove loadfile2 for initrd selftests Heinrich Schuchardt
2021-03-13 21:47 [PATCH 0/6 v2] Loadfile2 for initrd loading Ilias Apalodimas
2021-03-13 21:47 ` [PATCH 2/6] efi_loader: Add device path related functions for initrd via Boot#### Ilias Apalodimas
2021-03-14  7:19   ` Heinrich Schuchardt
2021-03-14  7:32     ` Ilias Apalodimas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210312050256.GD15112@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.