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

[Simon Glass]

Hi Tom,

On Thu, 28 Oct 2021 at 11:52, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote:
> > 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.
>
> OK, for the next go-round yes, please show what a typical enablement
> would look like on Pi, for example.

OK. Do understand that conceiving of this and implementing it is quite
a bit of effort. At some point I just send things out, to get feedback
and to think some more. Apart from anything else, there is a risk of
going into the weeds or never finishing it.

>
> > It does save a small amount of data. E.g. rpi_3_32b environment goes
> > drops by 3.5KB.
>
> So we're replacing 3.5KB of scripts with 17KB of code.  That is not a
> win.

Certainly not on size! On testing, debug, visibility and control of
the boot process, there are wins.

>
> > We should compare this with the EFI support which is about 90KB, as I recall.
>
> No, we shouldn't.  This isn't about replacing EFI, this is about
> replacing the generic distro boot macros, so that's what the size
> comparison is to.  At the end of the day, and looking towards non-legacy
> uses, a big common use case is "Find the EFI app to run".

I just mean that EFI has been accepted as part of U-Boot and adds 90KB.

>
> > 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.
>
> Yes, this should be using the API and not the command interface.

Right, but that's not something I am taking on right now. The PXE
refactoring gives an idea of what is needed. I did that work mainly
because I don't like adding to code that desperately needs
refactoring. We need to do the same for dhcp, EFI and bootm/zboot, but
that might take a year.

>
> > 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.
>
> I disagree.  At present, booting is either intentionally per-board, or
> it's using the generic distro boot framework.  That framework is what to
> further build on or perhaps make more readily simplified (for example,
> making it just be "scan around for EFI" or just be "scan around of
> extlinux.conf").

Well if the Universal Bootloader is only going to exist to boot EFI,
then we should rename it :-)

I am not sure that anyone wants something intentionally per-board,
it's just that everything about the boot in U-Boot is really low-level
(bootm, fixed addresses, etc.) We need the layer on top that can deal
with these silly details. For example, yes there is a Chrome OS boot
script in chromebook_coral, but it is the same on all devices. I would
rather just enable that bootmethod so that if Chrome OS is present it
will boot.

Re the memory side, i don't like the vars that define the kernel
address, FDT address, etc. It seems to me that most/all are
unnecessary, if there is something able to deal with memory allocatoin
automatically. Perhaps we should use malloc() more, or use LMB more
proactively.

Even for custom flows, creating a bootmethod will have advantages, I think.

The other thing is that this allows further innovation. For verified
boot, it makes it possible to sensibly deal with A/B;recovery, whereas
at present that is all just scripting, certainly not handled by distro
boot.

>
> > Anyway, I can look at what the minimum size is with the above points
> > and send that info through.
>
> I looked at the PXE stuff, and I think the minimal growth there ends up
> being reasonable, fwiw.  It comes down to adding sanity checks in places
> where the code wasn't always sanity checking, as you reduced
> duplication.

Yes and perhaps the growth can be reduced, too.

Regards,
Simon