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

[François Ozog]

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 ?

Even before EFI existed on x86 it went like (this is not intending to be
exhaustive or even exact):
Start a non installed system: the boot goes through a device list much like
distro_boot_CMd works except if the user select a manual boot selection
(the boot devices goes into a menu)
When the installer finishes it “informs” the firmware with the desired boot
target.
When the OS runs it can select the next boot (transient or permanent)
option. This usually involves grub rather than firmware but the user can
decide if the boot target change is driven by the firmware.
(For SystemReady we want to have an option to live without shim and grub so
the boot target change will involve setting BootXXXX.)

I think it is first important to describe the observable behavior before
jumping into implementation. Scenarios involving développer systems may be
different from the ones for consumer products.

Or should that be replaced entirely with efi vars and
> BootOrder/BootXXX and "bootefi bootmgr $fdt_addr_r" ?

for EFI there is also the last resort /BOOT/BOOT${arch}.efi in ESP


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