On Wed, Apr 05, 2023 at 11:56:59PM +0200, Mark Kettenis wrote: > > Date: Wed, 5 Apr 2023 10:47:59 -0400 > > From: Tom Rini <tr...@konsulko.com> > > > > On Wed, Apr 05, 2023 at 05:28:07PM +1200, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, 4 Apr 2023, 02:17 Tom Rini, <tr...@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 <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. > > > > > > > > > > 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? > > The short anserwer is no. > > The long answer: > > OpenBSD requires EFI (booti/bootz/bootm only support booting Linux > kernels in various forms) but also relies on a proper device tree > being provided to its EFI bootloader. While we have made significant > progress in having U-Boot provide a fully synched up device tree for > most of the SoCs that OpenBSD supports, we're not quite there yet, so > some people rely on U-Boot loading (and tweaking) an updated > device-tree from the EFI System Partition. > > Our bootloader does have a "mach dtb" command to load a device tree > from the OpenBSD root partition, but this is considered to be a > debugging command and can't load a device tree from the EFI System > Partition. Loading a device tree this way means the device tree does > not get tweaked by U-Boot, which is problematic on some SoCs/boards. > > We now have the EFI_DT_FIXUP_PROTOCOL, but our bootloader doesn't use > this yet. If the consensus is that distroboot-with-efiboot needs to > deprecated I can work on supporting that protocol in our bootloader. > But a release of OpenBSD with support for that will not be available > until november 2023. > > Alternatively bootmgr could implement the device tree loading and > fixup. Or the bootstd stuff could do this before starting bootmgr. I > understand the concerns about loading device trees from disk when > secure boot is enabled. So maybe this should only be done when secure > boot is disabled. > > Also note that setting the BootOrder EFI variable from inside the OS > isn't supported by most (all?) boards currently supported by U-Boot. > So a convenient way to set the BootOrder EFI variable from within > U-Boot is needed. > > Cheers, > > Mark > > P.S. Does grub support the EFI_DT_FIXUP_PROTOCOL these days? If not > (or if your Linux distro still ships with an older version of > grub) you'll face the same issue as OpenBSD regarding the lack of > fixups for loaded devictrees.
I just want to chime in and say thanks for explaining your use case, so we can make sure what we're doing will actually work for everyone. -- Tom
signature.asc
Description: PGP signature