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

From: Simon Glass <sjg@chromium.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: "Michal Simek" <michal.simek@xilinx.com>,
	"Tom Rini" <trini@konsulko.com>,
	"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
	"Daniel Schwierzeck" <daniel.schwierzeck@gmail.com>,
	"Steffen Jaeckel" <jaeckel-floss@eyet-services.de>,
	"Marek Behún" <marek.behun@nic.cz>,
	"Lukas Auer" <lukas.auer@aisec.fraunhofer.de>,
	"Dennis Gilmore" <dennis@ausil.us>,
	"Jaehoon Chung" <jh80.chung@samsung.com>,
	"Marek Vasut" <marex@denx.de>,
	"Masahiro Yamada" <yamada.masahiro@socionext.com>,
	"Pavel Herrmann" <morpheus.ibis@gmail.com>,
	"Peng Fan" <peng.fan@nxp.com>,
	"Stephen Warren" <swarren@nvidia.com>,
	"Stephen Warren" <swarren@wwwdotorg.org>,
	"François Ozog" <francois.ozog@linaro.org>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	"U-Boot Mailing List" <u-boot@lists.denx.de>
Subject: Re: [PATCH v2 00/41] Initial implementation of standard boot
Date: Wed, 27 Oct 2021 12:33:19 -0600	[thread overview]
Message-ID: <CAPnjgZ0tbpwMix7vv6YL2G0KCd10-aG_HTJprc-LF7VFCvC1Vw@mail.gmail.com> (raw)
In-Reply-To: <3fde4b98-e7c0-71c3-d7c4-22c6f43eae31@canonical.com>

Hi Heinrich,

On Wed, 27 Oct 2021 at 05:38, Heinrich Schuchardt
<heinrich.schuchardt@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.
> >
> >
[..]