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

[Tom Rini]

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.

> 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.

> 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".

> 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.

> 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").

> 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211028/60907b78/attachment.sig>