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 <tr...@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 <s...@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
signature.asc
Description: PGP signature