[PATCH v3 30/31] bootstd: doc: Add documentation

[Simon Glass]

Hi Tom,

On Fri, 21 Jan 2022 at 08:31, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Jan 21, 2022 at 08:20:17AM -0700, Simon Glass wrote:
> > Hi,
> >
> > On Fri, 21 Jan 2022 at 08:08, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Wed, Jan 19, 2022 at 12:39:03PM +0100, Heinrich Schuchardt wrote:
> > > > On 1/19/22 02:43, Simon Glass wrote:
> [snip]
> > > > > +Introduction
> > > > > +------------
> > > > > +
> > > > > +Standard boot provides a built-in way for U-Boot to automatically boot
> > > > > +an Operating System without custom scripting and other customisation. It
> > > > > +introduces the following concepts:
> > > > > +
> > > > > +   - bootdev  - a device which can hold or access a distro (e.g. MMC, Ethernet)
> > > > > +   - bootmeth - a method to scan a bootdev to find bootflows (e.g. distro boot)
> > > > > +   - bootflow - a description of how to boot (provided by the distro)
> > > > > +
> > > > > +For Linux, the distro (Linux distribution, e.g. Debian, Fedora) is responsible
> > > > > +for creating a bootflow for each kernel combination that it wants to offer.
> > > >
> > > > This gets it completely wrong. There is one standardized boot flow: UEFI.
> > > > All major distros support this. U-Boot has to offer UEFI booting out of the
> > > > box.
> > >
> > > I want to jump up and down and emphasize this part as well.  While I
> > > believe our UEFI bootmgr is still missing the normal scan code, that's
> > > something that has been promised to be implemented.  And that turns the
> > > bootcmd for platforms that just want to support modern off the shelf
> > > distros in to something fairly small.
> >
> > Sigh...
> >
> > UEFI is a bootflow in this model, one of many. If we don't support the
> > others, then U-Boot is not U-Boot anymore, it is just EFI Boot.
>
> No one is talking about removing anything else.  But a major part of
> your motivation here seems to be "discovering what to boot where is a
> pain" and that's solved (or at least defined, I'm poking Ilias about the
> status of that off-list).  And I want to emphasize discover.

But only if you use EFI boot manager, right? Even then I'm not sure we
have a deterministic way of listing the available bootdevs, which is
something that this series provides.

>
> > If we get EFI bootmgr going, then are you saying you want to disable
> > everything else?
>
> Not at all.

OK, good.

>
> > You say 'major distros' but there are many that don't use it,
> > particularly in the embedded space. I'll go out on a limb and say that
> > the vast majority of embedded devices in the world don't use it. Are
> > you really saying we should drop support for everything else? Even the
> > distro stuff supports other options.
>
> I don't know about buildroot off-hand, but I've had OpenEmbedded spit
> out UEFI-compatible aarch64 images no problem.  If you're talking about
> embedded Debian/Ubuntu/Fedora, that goes back up to "wants UEFI boot
> flow".  Armbian is the biggest distro I know of off-hand that doesn't
> do UEFI boot for U-Boot targets and I would love to talk with someone
> there and find out why (but I guess it's all the 32bit platforms).
>
> But I'd also say the vast majority of embedded devices don't need the
> complexity you're adding here, but DO need the ability to implement A/B
> things as easily in U-Boot as they can in grub.  And that in turn is
> because it's a pain to modify the default environment in U-Boot and easy
> to drop in another script for grub.

My feeling is the complexity is already there, just in scripts, which
are harder to understand (from personal experience trying to
understand what they do) and don't have tests. They are also very hard
to build on top of (e.g. verified boot).

I can't really say that this series is more complex than EFI bootmgr,
if that is what you are suggesting. I think the bootdev uclass is
well-motivated and will prove useful even for EFI.

Also A/B/recovery is a lot easier to implement in code than in
scripts. I have linked to the proposed design there.

Anyway if we can agree that we are not going to disable the non-EFI
flows, then how about we focus on replacing the distro boot scripts,
dropping the config.h files, and leave EFI bootmgr out of this
discussion?

Regards,
Simon