[PATCH v2 00/41] Initial implementation of standard boot

[Simon Glass]

Hi Tom,

On Thu, 28 Oct 2021 at 10:27, Tom Rini <trini at konsulko.com> wrote:
>
> On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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.
>
> I'm going to break my feedback down in to a few threads, to hopefully
> not confuse things too much.  My first comment is that rpi_arm64 grows
> in size by 17 kilobytes, with the whole series (pxe, env, this) applied.
> And while there's a few small changes in the pxe cleanup I'm going to
> re-investigate on their own, it's really just this series, right here,
> adding tons of code.  To replace an admittedly complex bit of
> environment scripting, with C.  It's not even the earlier parts of the
> series to clean up / prepare, it starts at "bootstd: Add the bootstd
> uclass and core implementation" and keeps going from there.

Yes it does add a lot of code, although it is a lot less if the
commands are disabled or simplified, e.g. to only support 'bootflow
scan -b'. At the moment it enables all dev features.

It does save a small amount of data. E.g. rpi_3_32b environment goes
drops by 3.5KB.

We should compare this with the EFI support which is about 90KB, as I recall.

If we continue down the path of making this feature use U-Boot
functions directly, instead the command line, I suspect we can save
quite a bit more, since there is a lot of overhead with these
commands. At present it is impossible to boot without CONFIG_CMDLINE
enabled, for example.

In any case, I think this feature is filling a gap in U-Boot since at
present everything about boot is ad-hoc. This gives us a base to build
on. Nothing is for free.

Anyway, I can look at what the minimum size is with the above points
and send that info through.

Regards,
Simon