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

[Tom Rini]

On Fri, Jan 21, 2022 at 09:02:13AM -0700, Simon Glass wrote:
> 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.

I'll let someone else that knows the EFI boot manager code / design
speak to this.  But yes, for the discoverable case I'm not seeing where
"use EFI boot manager" isn't the reasonable answer.

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

Yes, the scripts that live in the environment based boot flow is
complex.  It's also been a huge step forward from what we had before and
has been a great help.

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

No, what I'm suggesting is that I see this as "current boot script stuff
is too complex, lets replace it".  And I also see the big part of the
complexity there being the discover where to boot from side of things.

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

Show me what implementing Mender or RAUC or swupdate looks like with
your proposal.  Those are some of the real A/B use cases today and have
had to take various approaches to dealing with our environment, and also
supporting x86 and so started dealing with grub.

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

The primary use case for the distro boot work is EFI boot, and the "make
this logic clearer" solution is "use EFI bootmgr".  That's where we get
stuck in a loop here.  There's no "the distro must create .." because
the distro is already creating what's needed.

-- 
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/20220121/b274e568/attachment.sig>