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

[François Ozog]

Hi Tom

Le jeu. 28 oct. 2021 à 20:27, Tom Rini <trini at konsulko.com> a écrit :

> On Thu, Oct 28, 2021 at 08:17:50PM +0200, François Ozog wrote:
> > Hi Tom,
> >
> > Le jeu. 28 oct. 2021 à 19:59, Tom Rini <trini at konsulko.com> a écrit :
> >
> > > On Thu, Oct 28, 2021 at 06:50:02PM +0100, Peter Robinson wrote:
> > > > On Thu, Oct 28, 2021 at 6:47 PM Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > 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?
> > > >
> > > > Is this question from the board PoV, the developer of U-Boot or the
> > > > distro trying to boot?
> > > >
> > > > If you mean from a boot flow PoV for UEFI to find the HW that
> contains
> > > > the OS to boot I thought that was handled elsewhere in the series.
> > >
> > > What I mean is that today looking at Pi we have:
> > > #define BOOT_TARGET_DEVICES(func) \
> > >         BOOT_TARGET_MMC(func) \
> > >         BOOT_TARGET_USB(func) \
> > >         BOOT_TARGET_PXE(func) \
> > >         BOOT_TARGET_DHCP(func)
> > >
> > > As the board maintainer set that as the list of places to start looking
> > > for the next payload (say the GRUB EFI binary).  Simon's series
> replaces
> > > that with I think he said "bootflow scan -b".  And then the above env
> > > portion is replaced with, well, what's documented in patch #40 if you
> > > don't just want to rely on device probe order.
> > >
> > > Because we need to have _something_ that says where to look for what,
> > > yes?
> >
> > Shouldn’t we describe the user point of view ?
>
> No, because to extend the x86 metaphor we're talking about the defaults
> here, not what the user has configured later on.  The user has and
> continues to be able to configure the system afterwards, if desired.
>
Sorry , missed this “detail”…

>
> --
> Tom
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog