[PATCH v5 3/8] bootstd: Support booting EFI where multiple options exist
Tom Rini
trini at konsulko.com
Mon Apr 3 16:17:42 CEST 2023
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.
--
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/20230403/8e104b6b/attachment.sig>
More information about the U-Boot
mailing list