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

Simon Glass sjg at chromium.org
Wed Oct 27 20:33:19 CEST 2021


Hi Heinrich,

On Wed, 27 Oct 2021 at 05:38, Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
>
>
> On 10/24/21 01:25, 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)
>
> Please, describe why you are suggesting this change.
>
> Replacing a script by a devicetree chunk is just decreasing flexibility
> and increasing complexity. Where is the benefit?

See previous email in thread. Continuing here on a few of your other points...

>
> I am missing a description here of where and how a boot flow shall be
> defined. Describing some device-tree binding in patch 40/41 does not
> replace describing the development and usage workflow. Who will provide
> which bootflow information when?

We already have this with distro boot, so nothing really changes
there. Think of this as a generalised 'standard boot' implementation,
which can support distro boot and anything else we need in the future.

There is nothing required in the devicetree for normal operation.

>
> You still have an open discussion with Linaro about the source of
> devicetrees. This discussion needs to be finalized before considering
> this series.

Why is that? They don't seem to be at all related to me.

>
> In my view bootflows cannot be defined in the devicetree because prior
> firmware providing a devicetree is completely independent of any distro
> and therefore cannot provide a distro specific bootflow.

See previous post, they are not defined in the devicetree. Can you
suggest how I can change the language to make that clear?

Regards,
Simon

>
> >
> > 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.
> >
> > With this we can boot on a Raspberry Pi 3 with just one command:
> >
> >     bootflow scan -lb
> >
> > which means to scan, listing (-l) each bootflow and trying to boot each
> > one (-b). The final patch shows this.
> >
> > With a standard way to identify boot devices, booting become easier. It
> > also should be possible to support U-Boot scripts, for backwards
> > compatibility only.
> >
> >
[..]


More information about the U-Boot mailing list