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

[Ilias Apalodimas <ilias.apalodimas@linaro.org>]

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@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@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.

Regards/Ilias
> I've been trying to tease out the rules around finding the image and
> the devicetree files, and this is what I've got it.
>
> Regards,
> Simon