[PATCH v2 31/41] bootstd: Add an implementation of EFI boot

[Ilias Apalodimas]

Hi Simon,

On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote:
> Hi Ilias,
> 
> On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas
> <ilias.apalodimas at linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Sun, 24 Oct 2021 at 02:27, Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Add a bootmeth driver which handles EFI boot, using EFI_LOADER.
> > >
> > > In effect, this provides the same functionality as the 'bootefi' command
> > > and shares the same code. But the interface into it is via a bootmeth,
> > > so it does not require any special scripts, etc.
> > >
> > > For now this requires the 'bootefi' command be enabled. Future work may
> > > tidy this up so that it can be used without CONFIG_CMDLINE being enabled.
> >
> > I'll leave this up to Heinrich, but personally I wouldn't include this
> > patch at all. EFI has it's bootmgr which can handle booting just fine.
> > I don't see why we should duplicate the functionality.  The new boot
> > method can just have an entry called 'EFI' and then let the existing
> > EFI code to decide.
> 
> This is needed so that EFI boot is actually invoked. If bootmgr starts
> being used then it can still be invoked from standard boot. The point
> is that there is a standard way of booting that supports EFI and other
> things.

This patch tries to reason about the default naming EFI imposes on it's 
boot files. distro_efi_read_bootflow() will try to find files following the
EFI naming convention (e.g bootaarch64.efi, bootarm.efi etc).  If those are 
found it will try to boot them right?  That's not the right thing to do though.
On the EFI spec these files are tried if no Boot#### variables are found.  
So we can get rid of this entirely,  add a dummy entry on the bootflow that 
says 'boot the efi manager' (which is what the next patch does).  

The efibootmgr then will check Boot#### variables and if none are found,
it's going to fallback into loading bootaarch64.efi, bootarm.efi etc
essentially offering identical functionality.

Regards
/Ilias
> 
> This series is about replacing the scripts we currently have with a
> proper C implementation that uses driver model.
> 
> > Regards
> > /Ilias
> >
> [..]
> 
> Regards,
> Simon