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

[Emmanuel Vadot]

On Tue, 24 Aug 2021 12:22:42 +0200 (CEST)
Mark Kettenis <mark.kettenis at xs4all.nl> wrote:

> > Date: Mon, 23 Aug 2021 16:01:46 -0400
> > From: Tom Rini <trini at konsulko.com>
> > 
> > On Mon, Aug 23, 2021 at 11:25:42AM -0600, Simon Glass wrote:
> > > 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?
> > 
> > Well, there's "find the next stage", which is boot_targets environment
> > variable, and then "where that next stage looks for stuff" which is
> > OS-dependent.  Sometimes the ESP grub.cfg file is just enough to tell
> > grub to find the full grub.cfg file elsewhere, and sometimes it's a full
> > grub.cfg file.  I think Mark is talking about the former, and you've
> > said it's not part of this series, yet, but on the TODO list.
> 
> Right.  With the current distroboot code the order of the devices that
> appears in boot_targets is determined by per-board/SOC/machine config
> files and the order isn't the same for all of them.  Users can change
> the order if necessary by modifying the environment variable and
> saving the environment.  And for a one-off boot from a different
> device they can simply run an appropriate boot command.  The
> boot_targets variable in particular is documented in various install
> documents so it would probably be good of the new "bootmethod" code
> would respect this variable.
> 
> For OpenBSD I'm not really interested in the bootflow part.  As I
> explained in the past, that part of the problem is solved in a
> (mostly) uniform way across platforms by the OpenBSD bootloader which
> can read an /etc/boot.conf that allows bootflow customization.  So as
> long as the default of the new code still results in
> \EFI\BOOT\BOOT{machine type short-name}.EFI being loaded and run if
> there is no U-Boot specific bootflow configured, I'm happy.

 Mostly the same for FreeBSD, as long as the efi boot<arch>.efi is
loaded and run by default (respecting the boot_targets order) we will
be fine.

> I can't speak for the other BSDs, but my impression is that they are
> pretty much in the same position.  The FreeBSD bootloader for example
> supports a high-degree of "bootflow" customization and I doubt that
> taking it out of the loop is a viable option for most users.
> 
> > -- 
> > Tom
> > 
> > [2:application/pgp-signature Show Save:signature.asc (659B)]
> > 


-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at FreeBSD.org>