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

Simon Glass Wed, 23 Mar 2022 11:46:24 -0700

Hi Tom,

On Wed, 23 Mar 2022 at 08:05, Tom Rini <tr...@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
- gets rid of the scripts which are a confusing mess
- provides proper high-level concepts of boot device and boot method
- 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
- allows non-UEFI boot cases like Chrome OS, which is currently just a
hack for one board[1]
- provides a programmatic base for A/B boot, etc.

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?

Regards,
Simon

[1] CONFIG_BOOTCOMMAND="tpm init; tpm startup TPM2_SU_CLEAR; read mmc
0:2 100000 0 80; setexpr loader *001004f0; setexpr size *00100518;
setexpr blocks $size / 200; read mmc 0:2 100000 80 $blocks; setexpr
setup $loader - 1000; setexpr cmdline_ptr $loader - 2000; setexpr.s
cmdline *$cmdline_ptr; setexpr cmdline gsub %U \\\\${uuid}; if part
uuid mmc 0:2 uuid; then zboot start 100000 0 0 0 $setup cmdline; zboot
load; zboot setup; zboot dump; zboot go;fi"

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

Reply via email to