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

[Tom Rini]

On Thu, Oct 28, 2021 at 06:37:42PM +0100, Peter Robinson wrote:
> On Wed, Oct 27, 2021 at 3:11 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > 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?
> > >
> > > 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?
> > >
> > > You still have an open discussion with Linaro about the source of
> > > devicetrees. This discussion needs to be finalized before considering
> > > this series.
> > >
> > > 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.
> >
> > There is actually no need to use devicetree here. I think you might
> > have the wrong end of the stick. It is certainly possible to add nodes
> > to configure things, if needed, but it works find without any changes
> > to the devicetree, as you can see from the rpi_3 patch.
> >
> > There are several aims with this effort:
> >
> > - Provide a standard way to boot anything on U-Boot, that everyone can
> > plug into (distros, board vendors, people using a custom flow)
> 
> I as a distro maintainer don't want this, we already get the "standard
> way to boot" from UEFI, this just feels like another unnecessary
> abstraction to that.

Right.  But part of the problem is "How do I find UEFI".  Something
somewhere needs to be configurable to say where to look, yes?

-- 
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/20211028/dd671f7c/attachment.sig>