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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 3169 bytes --]

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

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

Not at all.

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

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]