Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow

From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Steffen Jaeckel <jaeckel-floss@eyet-services.de>,
	Michal Simek <michal.simek@xilinx.com>,
	Dennis Gilmore <dennis@ausil.us>,
	Daniel Schwierzeck <daniel.schwierzeck@gmail.com>,
	Lukas Auer <lukas.auer@aisec.fraunhofer.de>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Matthias Brugger <mbrugger@suse.com>, Peng Fan <peng.fan@nxp.com>,
	Stephen Warren <swarren@nvidia.com>,
	Stephen Warren <swarren@wwwdotorg.org>
Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
Date: Thu, 19 Aug 2021 09:59:44 -0400	[thread overview]
Message-ID: <20210819135944.GX858@bill-the-cat> (raw)
In-Reply-To: <20210819034601.1618773-1-sjg@chromium.org>

[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]

On Wed, Aug 18, 2021 at 09:45:33PM -0600, Simon Glass wrote:

> Bootmethod and bootflow provide a built-in way for U-Boot to automatically boot
> an Operating System without custom scripting and other customisation:
> 
>   - bootmethod - a method to scan a device to find bootflows (owned by U-Boot)
>   - bootflow - a description of how to boot (owned by the distro)
> 
> This series provides an initial implementation of these, enable to scan
> for bootflows from MMC and Ethernet. The only bootflow supported is
> distro boot, i.e. an extlinux.conf file included on a filesystem or
> tftp server. 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.
> 
> It is intended that this approach be expanded to support mechanisms other
> than distro boot, including EFI-related ones. With a standard way to
> identify boot devices, these features become easier. It also should
> support U-Boot scripts, for backwards compatibility only.
> 
> The first patch of this series moves boot-related code out of common/ and
> into a new boot/ directory. This helps to collect these related files
> in one place, as common/ is quite large.
> 
> Like sysboot, this feature makes use of the existing PXE implementation.
> Much of this series consists of cleaning up that code and refactoring it
> into something closer to a module that can be called, teasing apart its
> reliance on the command-line interpreter to access filesystems and the
> like. Also it now uses function arguments and its own context struct
> internally rather than environment variables, which is very hard to
> follow. No core functional change is included in the included PXE patches.
> 
> For documentation, see the 'doc' patch.
> 
> There is quite a long list of future work included in the documentation.
> One question is the choice of naming. Since this is a bootloader, should
> we just call this a 'method' and a 'flow' ? The 'boot' prefix is already
> shared by other commands like bootm, booti, etc.
> 
> The design is described here:
> 
> https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing
> 
> The series is available at u-boot-dm/bmea-working

My question / concern is this.  Would the next step here be to
implement the generic UEFI boot path?  Today, I can write Fedora 34 for
AArch64 to a USB stick, boot U-Boot off of uSD card and the installer
automatically boots.  I'm sure I could do the same with the BSDs.
Reading the documentation left me with the impression that every OSV
would be expected to write something, so that their installer / OS boot.
But there's already standards for that, which they do, and we should be
implementing (and do, via the current distro_boot) or making easier to
enable.  Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]