From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFC97C4338F for ; Wed, 25 Aug 2021 11:04:42 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8329B611C9 for ; Wed, 25 Aug 2021 11:04:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8329B611C9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bidouilliste.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id F2E3382DB2; Wed, 25 Aug 2021 13:04:27 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=bidouilliste.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=bidouilliste.com header.i=@bidouilliste.com header.b="quYD72UP"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8A54080ECC; Wed, 25 Aug 2021 12:45:30 +0200 (CEST) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 2746D82986 for ; Wed, 25 Aug 2021 12:45:25 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=bidouilliste.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=manu@bidouilliste.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1629888323; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Zj0dVFoTUlBDTsVCL/ZpQPmcPI8yoV0JMnbsctPo120=; b=quYD72UPX65DNdYfmx+hI4t3bNUsPwpbg0QdltpU4ofh/MvWP8kEAbKFaUFe1j5PvSi9to mTKuCi0rzQSCCssZX4PVr7WYOso7Rim+xK6GSHH3dmpYXSU6FidJND1KlD2bfu4vxqj9eP zFunJV9bi1rSxuRSsDR6r2JtR6+ap4A= Received: from amy (lfbn-idf2-1-644-4.w86-247.abo.wanadoo.fr [86.247.100.4]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 0d0cf451 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 25 Aug 2021 10:45:23 +0000 (UTC) Date: Wed, 25 Aug 2021 12:45:23 +0200 From: Emmanuel Vadot To: Mark Kettenis Cc: Tom Rini , sjg@chromium.org, u-boot@lists.denx.de, ilias.apalodimas@linaro.org, jaeckel-floss@eyet-services.de, michal.simek@xilinx.com, dennis@ausil.us, daniel.schwierzeck@gmail.com, lukas.auer@aisec.fraunhofer.de, jh80.chung@samsung.com, mbrugger@suse.com, peng.fan@nxp.com, swarren@nvidia.com, swarren@wwwdotorg.org Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow Message-Id: <20210825124523.abf62a19a25e7491a4b4dae1@bidouilliste.com> In-Reply-To: <561412964a77c660@bloch.sibelius.xs4all.nl> References: <20210819034601.1618773-1-sjg@chromium.org> <56140f0c4976b9f9@bloch.sibelius.xs4all.nl> <20210823200146.GG858@bill-the-cat> <561412964a77c660@bloch.sibelius.xs4all.nl> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 Aug 2021 13:04:24 +0200 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Tue, 24 Aug 2021 12:22:42 +0200 (CEST) Mark Kettenis wrote: > > Date: Mon, 23 Aug 2021 16:01:46 -0400 > > From: Tom Rini > > > > On Mon, Aug 23, 2021 at 11:25:42AM -0600, Simon Glass wrote: > > > Hi Mark, > > > > > > On Mon, 23 Aug 2021 at 05:54, Mark Kettenis wrote: > > > > > > > > > From: Simon Glass > > > > > Date: Wed, 18 Aug 2021 21:45:33 -0600 > > > > > > > > > > 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 > > > > > > > > How does the user control the order in which devices are scanned/booted? > > > > > > That is not supported in distroboot at present, at least so far as I > > > can see. For Fedora it seems to happen in grub. Do I have that right? > > > > Well, there's "find the next stage", which is boot_targets environment > > variable, and then "where that next stage looks for stuff" which is > > OS-dependent. Sometimes the ESP grub.cfg file is just enough to tell > > grub to find the full grub.cfg file elsewhere, and sometimes it's a full > > grub.cfg file. I think Mark is talking about the former, and you've > > said it's not part of this series, yet, but on the TODO list. > > Right. With the current distroboot code the order of the devices that > appears in boot_targets is determined by per-board/SOC/machine config > files and the order isn't the same for all of them. Users can change > the order if necessary by modifying the environment variable and > saving the environment. And for a one-off boot from a different > device they can simply run an appropriate boot command. The > boot_targets variable in particular is documented in various install > documents so it would probably be good of the new "bootmethod" code > would respect this variable. > > For OpenBSD I'm not really interested in the bootflow part. As I > explained in the past, that part of the problem is solved in a > (mostly) uniform way across platforms by the OpenBSD bootloader which > can read an /etc/boot.conf that allows bootflow customization. So as > long as the default of the new code still results in > \EFI\BOOT\BOOT{machine type short-name}.EFI being loaded and run if > there is no U-Boot specific bootflow configured, I'm happy. Mostly the same for FreeBSD, as long as the efi boot.efi is loaded and run by default (respecting the boot_targets order) we will be fine. > I can't speak for the other BSDs, but my impression is that they are > pretty much in the same position. The FreeBSD bootloader for example > supports a high-degree of "bootflow" customization and I doubt that > taking it out of the loop is a viable option for most users. > > > -- > > Tom > > > > [2:application/pgp-signature Show Save:signature.asc (659B)] > > -- Emmanuel Vadot