[PATCH 00/28] Initial implementation of bootmethod/bootflow

[Simon Glass]

Hi Mark,

On Mon, 23 Aug 2021 at 05:54, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Simon Glass <sjg at chromium.org>
> > Date: Wed, 18 Aug 2021 21:45:33 -0600
> >
> > Bootmethod and bootflow provide a built-in way for U-Boot to automatically boot
> > an Operating System without custom scripting and other customisation:
> >
> >   - bootmethod - a method to scan a device to find bootflows (owned by U-Boot)
> >   - bootflow - a description of how to boot (owned by the distro)
> >
> > This series provides an initial implementation of these, enable to scan
> > for bootflows from MMC and Ethernet. The only bootflow supported is
> > distro boot, i.e. an extlinux.conf file included on a filesystem or
> > tftp server. It works similiarly to the existing script-based approach,
> > but is native to U-Boot.
> >
> > With this we can boot on a Raspberry Pi 3 with just one command:
> >
> >    bootflow scan -lb
> >
> > which means to scan, listing (-l) each bootflow and trying to boot each
> > one (-b). The final patch shows this.
> >
> > It is intended that this approach be expanded to support mechanisms other
> > than distro boot, including EFI-related ones. With a standard way to
> > identify boot devices, these features become easier. It also should
> > support U-Boot scripts, for backwards compatibility only.
> >
> > The first patch of this series moves boot-related code out of common/ and
> > into a new boot/ directory. This helps to collect these related files
> > in one place, as common/ is quite large.
> >
> > Like sysboot, this feature makes use of the existing PXE implementation.
> > Much of this series consists of cleaning up that code and refactoring it
> > into something closer to a module that can be called, teasing apart its
> > reliance on the command-line interpreter to access filesystems and the
> > like. Also it now uses function arguments and its own context struct
> > internally rather than environment variables, which is very hard to
> > follow. No core functional change is included in the included PXE patches.
> >
> > For documentation, see the 'doc' patch.
> >
> > There is quite a long list of future work included in the documentation.
> > One question is the choice of naming. Since this is a bootloader, should
> > we just call this a 'method' and a 'flow' ? The 'boot' prefix is already
> > shared by other commands like bootm, booti, etc.
> >
> > The design is described here:
> >
> > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing
> >
> > The series is available at u-boot-dm/bmea-working
>
> How does the user control the order in which devices are scanned/booted?

That is not supported in distroboot at present, at least so far as I
can see. For Fedora it seems to happen in grub. Do I have that right?

Anyway this feature is beyond scope of the current series, which is
just to put in the basic plumbing. We need a non-volatile config file
to hold this information (in VBE this is called NVdata).

>
> And how do we define the default order?

With distro boot this is done with an environment variable, as I
understand it. That is not implemented in this series, but is easy to
do and is in the TODO. For now it can only be done with aliases to set
the order of the bootmethods and that requires adding to the DT, so I
don't think it scales well. I'm open to ideas though.

Regards,
SImon