[PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist

[Tom Rini]

On Sat, Apr 08, 2023 at 06:55:20AM +1200, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 6 Apr 2023 at 02:48, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, Apr 05, 2023 at 05:28:07PM +1200, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 4 Apr 2023, 02:17 Tom Rini, <trini at konsulko.com> wrote:
> > >
> > > > On Mon, Apr 03, 2023 at 12:56:49PM +0300, Ilias Apalodimas wrote:
> > > > > On Sat, Apr 01, 2023 at 07:31:49PM +1300, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Sat, 1 Apr 2023 at 07:02, Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Fri, Mar 31, 2023 at 10:25:56AM +1300, Simon Glass wrote:
> > > > > > >
> > > > > > > > The current EFI implementation has a strange quirk where it watches
> > > > > > > > loaded files and uses the last-loaded file to determine the device
> > > > that
> > > > > > > > is being booted from.
> > > > > > > >
> > > > > > > > This is confusing with bootstd, where multiple options may exist.
> > > > Even
> > > > > > > > loading a device tree will cause it to go wrong. There is no API
> > > > for
> > > > > > > > passing this information, since the only entry into booting an EFI
> > > > image
> > > > > > > > is the 'bootefi' command.
> > > > > > > >
> > > > > > > > To work around this, call efi_set_bootdev() for EFI images, if
> > > > possible,
> > > > > > > > just before booting.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > > > >
> > > > > > > Shouldn't this all be a simple wrapper around the EFI Standard
> > > > > > > BootDeviceOrder or whatever that's called?
> > > > > >
> > > > > > I think you are referring to boot manager, which isn't used here. This
> > > > > > is replicating the existing distroboot functionality in standard boot.
> > > > >
> > > > > The distroboot functionality *was* trying to behave like the EFI spec
> > > > > expects the bootmanager to behave.  Unfortunately I haven't had time to
> > > > > review the distroboot patches closely, but back when this started, my
> > > > point
> > > > > was that EFI doesn't need anything.  Whenever the EFI flow is added
> > > > bootstd
> > > > > should 'just' call the bootmanager.
> > > >
> > > > Yes, this. We're trying make things cleaner overall, so the EFI portion
> > > > of bootstd distro boot should just be "call EFI bootmanager" as that has
> > > > a well defined standard way to specify what devices to try in what
> > > > order.
> > > >
> > >
> > > We already call bootmgr in standard boot, if it is enabled.
> > >
> > > But I am not sure how widely that is used...
> > >
> > > This patch is about corner cases in the distro scripts. If we are to turn
> > > these down we do need to try to do the same thing.
> >
> > We probably need some distro people to chime in about what they're doing
> > / expecting at this point in time? I would have sworn that the long term
> > part of EFI "distro boot" would be using bootmgr since that's the
> > standards based way to set boot order. And if you don't have a device
> > tree in U-Boot, and want the distribution one, aren't you then using
> > something like grub which has a "dtb" keyword to handle that on its own?
> > That's not saying that "distro boot" doesn't need to load the device
> > tree, for when it's then calling booti/bootz/bootm, but not for the EFI
> > case these days? Or no?
> 
> That's all fine, but the goal here is to match the functionality we
> have today, i.e. the distroboot scripts. If people move to bootmgr for
> EFI at some point, that's a separate thing from this patch. If I am
> misunderstanding something, please let me know.

Well, I'm going to change my mind (about a few things at this point) and
say yes, OK, we'll go with replicating the current behavior first and
make improvements on certain parts of the flow be a follow-up.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230407/e0be7efd/attachment.sig>