[U-Boot] [PATCH v0 20/20] efi_loader: add bootmgr

[Peter Jones]

On Fri, Aug 04, 2017 at 04:28:05PM -0400, Rob Clark wrote:
> On Fri, Aug 4, 2017 at 4:06 PM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > On 08/04/2017 09:32 PM, Rob Clark wrote:
> >> Similar to a "real" UEFI implementation, the bootmgr looks at the
> >> BootOrder and BootXXXX variables to try to find an EFI payload to load
> >> and boot.  This is added as a sub-command of bootefi.
> >>
> >> The idea is that the distro bootcmd would first try loading a payload
> >> via the bootmgr, and then if that fails (ie. first boot or corrupted
> >> EFI variables) it would fallback to loading bootaa64.efi.  (Which
> >> would then load fallback.efi which would look for \EFI\*\boot.csv and
> >> populate BootOrder and BootXXXX based on what it found.)
> >
> >
> > I wonder if this implementation is Fedora specific.
> >
> > For Debian I could not find any reference to boot.csv.
> > And it is not mentioned in the UEFI 2.7 spec.
> >
> > Please, provide the specification that your work is based on.
> 
> The references to boot.csv are based on looking at how shim/fallback
> work.. perhaps that is not standardized.  I'll let Peter Jones comment
> on that if he knows better what windows and other linux distro's do.

The boot.csv parts are part of fallback.efi, which is part of shim.
It's not distro specific, though not every distro uses it (though I
thought debian had started doing so very recently), and fallback.efi +
boot.csv is still strictly optional.  But as Rob says below - the boot
methodology fallback employs is based on what the spec says the boot
manager will do.  A distro could also just stick a second copy of their
normal bootloader in /EFI/BOOT/BOOTAA64.EFI and it would boot through
the recovery path every time until somebody manually created a boot
variable.  fallback is just shim's method of setting the variables
automatically, and it is fairly widely deployed.  I'm pretty sure SuSE
and Ubuntu both use it, for example.

> The bootmanager implementation is based on UEFI spec (sect 3.1 in
> v2.7), which does not depend on boot.csv or how shim/fallback program
> the BootOrder/BootXXXX variables.  But simply that they do.  I'm not
> particularly familiar with the boot chain on Debian, it is entirely
> possible that it works differently.  My comments about boot.csv where
> merely to try to provide context (and are quite possibly misleading on
> some distro's), but are irrelevant to the bootmgr implementation which
> only cares about BootOrder/BootXXXX, as described in sect 3.1.
> 
> (There are a lot of details that I skipped over in the bootmgr
> implementation, simply because secure boot or setting of efi variables
> from the OS is not implemented, so they are not yet relevant.)

This is still all correct.

-- 
  Peter