[PATCH v4 00/33] Initial implementation of standard boot

[Simon Glass]

Hi Tom,

On Wed, 23 Mar 2022 at 14:09, Tom Rini <trini at konsulko.com> wrote:
>
> On Wed, Mar 23, 2022 at 12:45:50PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 23 Mar 2022 at 08:05, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Sun, Mar 06, 2022 at 05:49:43AM -0700, Simon Glass wrote:
> > > >
> > > > The bootflow feature provide a built-in way for U-Boot to automatically
> > > > boot an Operating System without custom scripting and other customisation.
> > > > This is called 'standard boot' since it provides a standard way for
> > > > U-Boot to boot a distro, without scripting.
> > > >
> > > > It introduces the following concepts:
> > > >
> > > >    - bootdev - a device which can hold a distro
> > > >    - bootmeth - a method to scan a bootdev to find bootflows (owned by
> > > >                 U-Boot)
> > > >    - bootflow - a description of how to boot (owned by the distro)
> > > >
> > > > This series provides an implementation of these, enabled to scan for
> > > > bootflows from MMC, USB and Ethernet. It supports the existing distro
> > > > boot as well as the EFI loader flow (bootefi/bootmgr). 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.
> > > >
> > > > With a standard way to identify boot devices, booting become easier. It
> > > > also should be possible to support U-Boot scripts, for backwards
> > > > compatibility only.
> > > >
> > > > This series relies on the PXE clean-up series, posted here:
> > > >
> > > >    https://patchwork.ozlabs.org/project/uboot/list/?series=267078
> > > >
> > > > For documentation, see the 'doc' patch.
> > > >
> > > > For version 2, a new naming scheme is used as above:
> > > >
> > > >    - bootdev is used instead of bootdevice, because 'device' is overused,
> > > >        is everywhere in U-Boot, can be confused with udevice
> > > >    - bootmeth - because 'method' is too vanilla, appears 1300 times in
> > > >        U-Boot
> > > >
> > > > Also in version 2, drivers are introduced for the boot methods, to make
> > > > it more extensible. Booting a custom OS is simply a matter of creating a
> > > > bootmeth for it and implementing the read_file() and boot() methods.
> > > >
> > > > Version 4 makes some minor improvements and leaves out the RFC patch for
> > > > rpi conversion, in the hope of getting the base support applied sooner
> > > > rather than later.
> > > >
> > > > The design is described in these two documents:
> > > >
> > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing
> > > >
> > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing
> > >
> > > I keep putting off commenting more here, but, I still feel this is the
> > > wrong direction.  What problems do we have today with distro boot?
> > > Well, we haven't figured out how to move configuring it out of the board
> > > config.h file.  But that's just one of a half dozen or so examples of
> > > how we haven't figured out a good solution to configuring the default
> > > environment.  And only some of those other examples are boot related
> > > (the NXP chain of trust booting stuff is another boot example, ETHPRIME,
> > > HOSTNAME, etc, are non-boot examples).
> > >
> > > We also aren't improving testing of "can we boot" here, because what
> > > THAT needs is setting up LAVA and booting some installers on some
> > > hardware (and some QEMU).  That's testing that Linux boot works.  Today
> > > we have tests for hush parsing, and if distro boot makes use of
> > > something we don't have a test for, we need a test for it.  This adds
> > > tests for itself, which is good.
> > >
> > > And I still don't see an example of where this demonstrates that
> > > existing non-UEFI boot cases are now easier to handle or cleaner to
> > > handle or otherwise better.
> > >
> > > In that this is an attempt to tackle one of the long standing needed
> > > migrations (be able to drop board config.h files), something here needs
> > > doing.  But I don't see this as the right direction, sorry.
> >
> > Does anyone have a better idea for all of this? This is a solid base
> > we can build on but we can't make any progress while this is just
> > patches. What not apply it and we can move forward?
> >
> > - solves the env problem for distro boot in that we don't need the scripts
>
> Solves what problem?  That distro boot is done in hush?  Yes, we have
> many examples of needing to define the default environment in a
> non-static way.  This is not a solution to that problem.

It removes the need for the boot scripts that are currently in the
environment. I'm not sure what you mean by defining a default
environment in a non-static way.

>
> > - gets rid of the scripts which are a confusing mess
>
> Yes, a generic "figure out where a bootable might be, boot it" is
> complex.  That's basically why the UEFI boot manager code exists, and
> replaces that logic.

I thought we already decided that U-Boot was going to continue to
support non-UEFI booting?

>
> > - provides proper high-level concepts of boot device and boot method
>
> I don't see the inherent value.  Or maybe to put things another way, the
> "now go boot" API has always been implemented via hush, even when the
> interactive part is disabled.  You're providing a programatic way of
> doing it instead.  And I'm not seeing it being more flexible / easier to
> implement.  It's really sounded harder, not easier, than #define
> BOOT_TARGET_DEVICES.

It is easier in that you don't need to define the boot targets. It is
done automatically using the devices that are available.

>
> > - allows testing of the U-Boot part of 'can we boot' because we have
> > tests for all the cases - we can expand this over time
>
> No, it doesn't.  It provides a different interface and tests for itself.
> If it's not LAVA (or something like that) booting real Linux
> distribution images it's not a real can we boot test.

I didn't say it would test booting linux or real distros. You
obviously need LAVA (or something like that) for doing that.

But it does provide tests for the boot flow which are completely
lacking at present. So at least we are testing the code booting code.

>
> > - allows non-UEFI boot cases like Chrome OS, which is currently just a
> > hack for one board[1]
>
> I don't see a Chrome OS example in your series.

Would that help? I don't mind doing it if we can make some progress,
but your previous objection was about code size. I addressed that and
have not heard any comment about that.

>
> > - provides a programmatic base for A/B boot, etc.
>
> And I've noted before that I don't see how this makes life easier for
> any of the existing A/B mechanisms.  Some of which are just going with
> "Hey, just UEFI boot and let grub deal with it".

It makes it much easier since we now have the means to locate and read
in boot flows. Then it is just a case of selecting the one we want,
e.g. by examining the list of bootflows and selecting one. It is a
helpful division of labour.

>
> > I feel the same way with Takahiro's series, which has been out-of-tree
> > for too long.
> >
> > Please reconsider this. What do we have to lose?
>
> What we'll gain seems to be another chunk of code that needs boards to
> migrate to, maybe.  And I don't see examples where this, now, or in the
> next iteration, provides a smaller, or clearer implementation of
> something.

Yes it requires boards to migrate, although in fact the migration can
be driven by features rather than board-by-board. For example, we
could migrate boards that use USB, MMC, etc. first, and then migrate
more as we add more features.

But at least it is a chunk of code, with full tests. The scripts are
just a pain.

Regards,
Simon