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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 92669C4338F for ; Wed, 25 Aug 2021 14:56:51 +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 C4D5360F42 for ; Wed, 25 Aug 2021 14:56:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C4D5360F42 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.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 4217482986; Wed, 25 Aug 2021 16:56:48 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.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=konsulko.com header.i=@konsulko.com header.b="rudrcCwj"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B983782986; Wed, 25 Aug 2021 16:56:45 +0200 (CEST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id BFB1680612 for ; Wed, 25 Aug 2021 16:56:40 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf2b.google.com with SMTP id j9so1507qvt.4 for ; Wed, 25 Aug 2021 07:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=mHyIHcLqfYU/D8UnFzh0ea7AHtQfllbYx9pQeCw1xYw=; b=rudrcCwjgeJHnVGLc69HIWwHpu39pApd/sFJNJdmpHbTO023qBeRYEK/TABuu+aQuK xzOYzHab8uFl+NZpRF7eoDwk+DWWkoeMBgH7ee/6CWJ6B+2xiABczfxgtzEheAoZVGsX 1SywzgHYnDzSTKfaRjuOdrQ149cVNuNkn0/CA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=mHyIHcLqfYU/D8UnFzh0ea7AHtQfllbYx9pQeCw1xYw=; b=Kvy35auvy0ifxHou74TF1EcZBI5hS1Xk6gG6QWofEhC4MwerJDUhRfjBM9Lsyp9QDx rimLkA3MZELKA3hywRt/M0JluzOREQ97FKf0CddHczM/XDraM7xIZ5Wj7fzEnzDEqcBG 7W7+GG2KeomzTIzOaMaf72Xo6zuKwuN8iJIj+t/hLW00P+2qRp3dP26cWOcMpZ+Xc5/F 1vEf7rv35T9Ban12GLvMaMew02qfXreRMvzRMzpQGfeYv78KXO+HSLZOSZV/NucYBycw i4M58i/Cy/Dl/BeTnUQVvqdx7emXhrUEhfCxh/J3Rwj6NF3Casqn+U3yO/gYKZ6e2xLr 30rg== X-Gm-Message-State: AOAM532+ZCss0HR4+BzS4uLrwQvO2HxmQoj8m1JcNcg3U61aLfY2W2VZ Ik0HxuINkA5XwVG/PtW2iipaWQ== X-Google-Smtp-Source: ABdhPJyV6ozayPO41MLo1xyxFGSMPNNs0V092zftpA8XFGJ9c9sSl8pcu11ZIBgMSsLWrpu/8+GR+Q== X-Received: by 2002:a0c:cb8f:: with SMTP id p15mr12868998qvk.2.1629903399233; Wed, 25 Aug 2021 07:56:39 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-519a-4843-2801-9790.res6.spectrum.com. [2603:6081:7b01:cbda:519a:4843:2801:9790]) by smtp.gmail.com with ESMTPSA id o63sm167844qkf.4.2021.08.25.07.56.37 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 25 Aug 2021 07:56:38 -0700 (PDT) Date: Wed, 25 Aug 2021 10:56:35 -0400 From: Tom Rini To: AKASHI Takahiro Cc: Simon Glass , Emmanuel Vadot , Mark Kettenis , U-Boot Mailing List , Ilias Apalodimas , Steffen Jaeckel , Michal Simek , Dennis Gilmore , Daniel Schwierzeck , Lukas Auer , Jaehoon Chung , Matthias Brugger , Peng Fan , Stephen Warren , Stephen Warren Subject: Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow Message-ID: <20210825145635.GV858@bill-the-cat> References: <20210819034601.1618773-1-sjg@chromium.org> <56140f0c4976b9f9@bloch.sibelius.xs4all.nl> <20210823200146.GG858@bill-the-cat> <561412964a77c660@bloch.sibelius.xs4all.nl> <20210825124523.abf62a19a25e7491a4b4dae1@bidouilliste.com> <20210825144251.GB89209@laputa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tUtFoo1osds/9xhw" Content-Disposition: inline In-Reply-To: <20210825144251.GB89209@laputa> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) 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 --tUtFoo1osds/9xhw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 25, 2021 at 11:42:51PM +0900, AKASHI Takahiro wrote: > Simon, >=20 > On Wed, Aug 25, 2021 at 07:11:44AM -0600, Simon Glass wrote: > > Hi, > >=20 > > On Wed, 25 Aug 2021 at 04:45, Emmanuel Vadot wr= ote: > > > > > > 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 t= o automatically boot > > > > > > > > an Operating System without custom scripting and other cust= omisation: > > > > > > > > > > > > > > > > - bootmethod - a method to scan a device to find bootflow= s (owned by U-Boot) > > > > > > > > - bootflow - a description of how to boot (owned by the d= istro) > > > > > > > > > > > > > > > > This series provides an initial implementation of these, en= able to scan > > > > > > > > for bootflows from MMC and Ethernet. The only bootflow supp= orted is > > > > > > > > distro boot, i.e. an extlinux.conf file included on a files= ystem or > > > > > > > > tftp server. It works similiarly to the existing script-bas= ed approach, > > > > > > > > but is native to U-Boot. > > > > > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one com= mand: > > > > > > > > > > > > > > > > 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 me= chanisms other > > > > > > > > than distro boot, including EFI-related ones. With a standa= rd way to > > > > > > > > identify boot devices, these features become easier. It als= o 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 rel= ated files > > > > > > > > in one place, as common/ is quite large. > > > > > > > > > > > > > > > > Like sysboot, this feature makes use of the existing PXE im= plementation. > > > > > > > > Much of this series consists of cleaning up that code and r= efactoring it > > > > > > > > into something closer to a module that can be called, teasi= ng apart its > > > > > > > > reliance on the command-line interpreter to access filesyst= ems and the > > > > > > > > like. Also it now uses function arguments and its own conte= xt struct > > > > > > > > internally rather than environment variables, which is very= hard to > > > > > > > > follow. No core functional change is included in the includ= ed PXE patches. > > > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > > > There is quite a long list of future work included in the d= ocumentation. > > > > > > > > One question is the choice of naming. Since this is a bootl= oader, should > > > > > > > > we just call this a 'method' and a 'flow' ? The 'boot' pref= ix is already > > > > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > > > > > > > The design is described here: > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4= ZkNC12/view?usp=3Dsharing > > > > > > > > > > > > > > > > The series is available at u-boot-dm/bmea-working > > > > > > > > > > > > > > How does the user control the order in which devices are scan= ned/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 enviro= nment > > > > > 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 t= hat > > > > appears in boot_targets is determined by per-board/SOC/machine conf= ig > > > > files and the order isn't the same for all of them. Users can chan= ge > > > > 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 whi= ch > > > > 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. > >=20 > > OK thanks for the info. My expectation is that bootmethod/bootflow can > > support this easily enough (it is actually simpler than distro boot). > >=20 > > > > > > > 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 examp= le > > > > supports a high-degree of "bootflow" customization and I doubt that > > > > taking it out of the loop is a viable option for most users. > >=20 > > I think the same may happen with grub. E.g. with Ubuntu I see quite a > > bit of code in the grub.cfg file and it's not clear to me that it can > > be replaced with a 'data instead of code' approach. Still, a valid > > bootflow is simply to jump to an EFI app, which seems to be what is > > happening here. The bootflow side is really just about describing what > > to do, and this case is no different. For now I see three types of > > bootflow, PXE/syslinux, EFI boot manager and EFI app. >=20 > By "EFI app", do you mean a way of booting "/efi/boot/bootXX.efi" > (default file name in case that no image path is specified)? >=20 > In fact, this behavior, or removable media support, is defined > as part of UEFI boot manager in UEFI specification. (See section 3.5) > What this means is that the boot order, including a removable media > case and user-provided BootXXXX cases, should be controlled solely > by "BootOrder" variable. > So the current combination of distro_bootcmd + UEFI boot manger doesn't > fully comply with the specification. >=20 > Even if those two cases are integrated, I don't know how "BootOrder" > semantics can be preserved in your approach. I think the high level answer is that whereas today part of distro_bootcmd (and so iterating over boot_targets) "bootefi bootmgr" gets run, with what Simon is proposing we would have an easier / quicker way to get over to just running that. Perhaps a clean-up to just use that, even? Or are we not to the point yet where we could remove the direct fall-back to /efi/boot/bootXX.efi ? --=20 Tom --tUtFoo1osds/9xhw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmEmWiAACgkQFHw5/5Y0 tywpOAv/UOI5Sm0RRmho5CUgBkYv5o2kVC8y5Pwf6CUX0d9h7aNgrXofKffkHNM9 ja+yJwAeWrZbColVrswcjKjoRDs3ELiFIxQ7Dn5KsRXxk9V4R9CR6/2nb0Ptp5dW /gPFuuphkRgX2lSn2XuNXBD2zyqrISPU04GanzmRWG/l5LXhfB0BtiIk36VXu2AA mNYpl/YMQe72qBSqBwpueqQSm0nMVk5TWN8WY8J5X4TOPvG7iWsDBOX5Lvv1qcwH xSHFfV3tEa/LDpVMmk4VKiwREKx+mKRZzIs7mRCOmfVoYNPBLHq9w/8F3lLC1jQm igYLl/GsqoMo5fDUSq47z7LdjKAfLHEKQoSUUpAwGxvmeZvhr+dqLwy3+0LFwZV6 jYlSER2gonpHKg+5G/Gsq74MlC3+MvgKMEvUK9p5DqmFl6k39dV3uxRO7j8Xghqd KE8Yk2GSq5w2/PSAWqP+LoVHk3X4/D+Sg7EBaOWHTx07OKlTpdXFqT7X8Xp9FoV6 dyH/00vn =UvXc -----END PGP SIGNATURE----- --tUtFoo1osds/9xhw--