> From: Simon Glass <s...@chromium.org> > Date: Thu, 7 Sep 2023 09:57:34 -0600 > > Hi Mark, > > On Thu, 7 Sept 2023 at 07:08, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > > From: Simon Glass <s...@chromium.org> > > > Date: Thu, 7 Sep 2023 06:23:10 -0600 > > > > > > Hi Mark, > > > > > > On Sun, 3 Sept 2023 at 14:40, Mark Kettenis <kette...@openbsd.org> wrote: > > > > > > > > Enable the bootflow based on this bootmeth if the BootOrder EFI > > > > variable is set. > > > > > > > > Signed-off-by: Mark Kettenis <kette...@openbsd.org> > > > > --- > > > > > > > > ChangeLog: > > > > > > > > v2: - Initialize EFI subsystem to populate EFI variables > > > > > > > > > > > > boot/bootmeth_efi_mgr.c | 17 ++++++++++++++++- > > > > 1 file changed, 16 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/boot/bootmeth_efi_mgr.c b/boot/bootmeth_efi_mgr.c > > > > index e9d973429f..e6c42d41fb 100644 > > > > --- a/boot/bootmeth_efi_mgr.c > > > > +++ b/boot/bootmeth_efi_mgr.c > > > > @@ -14,6 +14,8 @@ > > > > #include <bootmeth.h> > > > > #include <command.h> > > > > #include <dm.h> > > > > +#include <efi_loader.h> > > > > +#include <efi_variable.h> > > > > > > > > /** > > > > * struct efi_mgr_priv - private info for the efi-mgr driver > > > > @@ -46,13 +48,26 @@ static int efi_mgr_check(struct udevice *dev, > > > > struct bootflow_iter *iter) > > > > static int efi_mgr_read_bootflow(struct udevice *dev, struct bootflow > > > > *bflow) > > > > { > > > > struct efi_mgr_priv *priv = dev_get_priv(dev); > > > > + efi_status_t ret; > > > > + efi_uintn_t size; > > > > + u16 *bootorder; > > > > > > > > if (priv->fake_dev) { > > > > bflow->state = BOOTFLOWST_READY; > > > > return 0; > > > > } > > > > > > > > - /* To be implemented */ > > > > + ret = efi_init_obj_list(); > > > > > > Doesn't this start up the whole EFI system? Is there a cheaper way to > > > see if the variable subsystem exists, or can work? > > > > A fair bit of it at least. With the possible exception of launching > > EFI capsules (which shouldn't happen for a "normal" boot), I don't > > think this is very expensive though. > > > > There currently isn't a way to only initialize the variable subsystem; > > we can't just call efi_init_variables() here since we have to also > > call efi_disks_register() and a later efi_init_obj_list() call would > > call efi_init_variables() again, which would leak memory. > > > > Alternatively we could just unconditionally declare the efi_mgr > > bootmeth as "ready" (like you already do for sandbox). That would > > postpone initialization of the EFI subsystem until we actually execute > > this bootmeth. > > > > But we need to do something before we switch more targets to standard > > boot since otherwise booting through the EFI boot manager is just > > plain broken. > > Yes... > > I don't have any great ideas on this. If we could get the EFI code > better integrated into U-Boot then perhaps we would not need this > 'monolithm' init?
You'll have to take that up with the maintainers of the EFI loader subsystem. I just want to repair the breakage that was introduced with bootstd.