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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4BCF6C433F5 for ; Sat, 26 Mar 2022 19:58:57 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 716F0841AB; Sat, 26 Mar 2022 20:58:55 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (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="SfeveO4+"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B8620841B0; Sat, 26 Mar 2022 20:58:53 +0100 (CET) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 DC02E84054 for ; Sat, 26 Mar 2022 20:58:49 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x82b.google.com with SMTP id v2so9229974qtc.5 for ; Sat, 26 Mar 2022 12:58:49 -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; bh=6YqGVyXGdXu2u0U/6+82q5LdBbUHVW1bP4p3W3wZJhk=; b=SfeveO4+/tC+YcGcuMfUuxtNjOZzMOKAehyazrL07X1l0GkKLeoBBa8OCRGGbBFbIJ A18RWkBOgCT6M/VbiKZyKZMXW95Nl9reTmCzftgp6VmEKolcZRfDQSw55Am8KzItlGeC LuN2WOS30TMaSvxkWurbvmQRsRRBi+rArpbzE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6YqGVyXGdXu2u0U/6+82q5LdBbUHVW1bP4p3W3wZJhk=; b=r00wFjKELIJoSSBjwkAiizBDmMrh01AEcFMm37AF8F/sUFWIfXytbXgc5khdelkWHd BRqTZK/u3rcGy1mb3LA1Q40Uo7vNGJRhn5g2kBUK8UjYaq8HQvPc+OA2UblaNra+aP53 VLGoQ3cJ/od1/uB9oUt+CuWbK21aYRJ0Eruad/+9NC9btJ0nK30IqsbLe+6ZXMGBWvc2 cqxfuSvN6WYa5KYq3SPvLDIPkigqpDNOyap8CFKdgSUZYB/6AD9wouN3yE0FLWk4a55e IbLXFw9hA2Cu2bMoQEYYgLg8EEqnty7WZcmr621Vi9z9CcKuK4dEcLKFIEO27LAvyznW ck4g== X-Gm-Message-State: AOAM532MayP+u2up2ttBXlnNFh6o4vb6m4W4obc8b1Jp7FAm3F9jdmIW yFDgGeQ0gTq/f0cHT5NvwbbgiQ== X-Google-Smtp-Source: ABdhPJy6OwgF4VNYPnRS+mUYaawpFSyxAmdm7Ch6VbieOesvywDqj+DpOcWt4wcy2zw8K13S4mfvwQ== X-Received: by 2002:ac8:59c9:0:b0:2e2:2d9c:7561 with SMTP id f9-20020ac859c9000000b002e22d9c7561mr15134895qtf.419.1648324728428; Sat, 26 Mar 2022 12:58:48 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-2ef0-5dff-fedb-a8ba.res6.spectrum.com. [2603:6081:7b01:cbda:2ef0:5dff:fedb:a8ba]) by smtp.gmail.com with ESMTPSA id h27-20020a05620a13fb00b0067b3615e4acsm5185695qkl.70.2022.03.26.12.58.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Mar 2022 12:58:47 -0700 (PDT) Date: Sat, 26 Mar 2022 15:58:45 -0400 From: Tom Rini To: Simon Glass Cc: Michael Nazzareno Trimarchi , U-Boot Mailing List , Dennis Gilmore , Ilias Apalodimas , Lukas Auer , Heinrich Schuchardt , Michal Simek , Daniel Schwierzeck , Steffen Jaeckel , Jaehoon Chung , Marek Vasut , Pavel Herrmann , Peng Fan Subject: Re: [PATCH v4 00/33] Initial implementation of standard boot Message-ID: <20220326195845.GP2284289@bill-the-cat> References: <20220306125016.3133737-1-sjg@chromium.org> <20220323140500.GF2226424@bill-the-cat> <20220323193013.GM2226424@bill-the-cat> <20220323200703.GN2226424@bill-the-cat> <20220325145018.GY2226424@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dT+85zccSFkyJC53" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean --dT+85zccSFkyJC53 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 26, 2022 at 01:56:36PM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Fri, 25 Mar 2022 at 08:50, Tom Rini wrote: > > > > On Fri, Mar 25, 2022 at 03:36:24PM +0100, Michael Nazzareno Trimarchi w= rote: > > > Hi Tom > > > > > > > > > On Wed, Mar 23, 2022 at 9:07 PM Tom Rini wrote: > > > > > > > > On Wed, Mar 23, 2022 at 08:57:36PM +0100, Michael Nazzareno Trimarc= hi wrote: > > > > > Hi Tom > > > > > > > > > > On Wed, Mar 23, 2022 at 8:30 PM Tom Rini wro= te: > > > > > > > > > > > > On Wed, Mar 23, 2022 at 08:21:22PM +0100, Michael Nazzareno Tri= marchi wrote: > > > > > > > Hi Tom > > > > > > > > > > > > > > On Wed, Mar 23, 2022 at 7:46 PM Simon Glass wrote: > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Wed, 23 Mar 2022 at 08:05, Tom Rini = wrote: > > > > > > > > > > > > > > > > > > On Sun, Mar 06, 2022 at 05:49:43AM -0700, Simon Glass wro= te: > > > > > > > > > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot = to automatically > > > > > > > > > > boot an Operating System without custom scripting and o= ther customisation. > > > > > > > > > > This is called 'standard boot' since it provides a stan= dard 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 boot= flows (owned by > > > > > > > > > > U-Boot) > > > > > > > > > > - bootflow - a description of how to boot (owned by = the distro) > > > > > > > > > > > > > > > > > > > > This series provides an implementation of these, enable= d to scan for > > > > > > > > > > bootflows from MMC, USB and Ethernet. It supports the e= xisting distro > > > > > > > > > > boot as well as the EFI loader flow (bootefi/bootmgr). = It works > > > > > > > > > > similiarly to the existing script-based approach, but i= s 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 try= ing to boot each > > > > > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > > > > > > > > > With a standard way to identify boot devices, booting b= ecome easier. It > > > > > > > > > > also should be possible to support U-Boot scripts, for = backwards > > > > > > > > > > compatibility only. > > > > > > > > > > > > > > > > > > > > This series relies on the PXE clean-up series, posted h= ere: > > > > > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?ser= ies=3D267078 > > > > > > > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > > > > > > > For version 2, a new naming scheme is used as above: > > > > > > > > > > > > > > > > > > > > - bootdev is used instead of bootdevice, because 'de= vice' is overused, > > > > > > > > > > is everywhere in U-Boot, can be confused with ud= evice > > > > > > > > > > - bootmeth - because 'method' is too vanilla, appear= s 1300 times in > > > > > > > > > > U-Boot > > > > > > > > > > > > > > > > > > > > Also in version 2, drivers are introduced for the boot = methods, to make > > > > > > > > > > it more extensible. Booting a custom OS is simply a mat= ter of creating a > > > > > > > > > > bootmeth for it and implementing the read_file() and bo= ot() methods. > > > > > > > > > > > > > > > > > > > > Version 4 makes some minor improvements and leaves out = the RFC patch for > > > > > > > > > > rpi conversion, in the hope of getting the base support= applied sooner > > > > > > > > > > rather than later. > > > > > > > > > > > > > > > > > > > > The design is described in these two documents: > > > > > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2= dav4ZkNC12/view?usp=3Dsharing > > > > > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9= TY3WYG6FF9/view?usp=3Dsharing > > > > > > > > > > > > > > > > > > I keep putting off commenting more here, but, I still fee= l this is the > > > > > > > > > wrong direction. What problems do we have today with dis= tro boot? > > > > > > > > > Well, we haven't figured out how to move configuring it o= ut of the board > > > > > > > > > config.h file. But that's just one of a half dozen or so= examples of > > > > > > > > > how we haven't figured out a good solution to configuring= the default > > > > > > > > > environment. And only some of those other examples are b= oot related > > > > > > > > > (the NXP chain of trust booting stuff is another boot exa= mple, ETHPRIME, > > > > > > > > > HOSTNAME, etc, are non-boot examples). > > > > > > > > > > > > > > > > > > We also aren't improving testing of "can we boot" here, b= ecause what > > > > > > > > > THAT needs is setting up LAVA and booting some installers= on some > > > > > > > > > hardware (and some QEMU). That's testing that Linux boot= works. Today > > > > > > > > > we have tests for hush parsing, and if distro boot makes = use of > > > > > > > > > something we don't have a test for, we need a test for it= =2E This adds > > > > > > > > > tests for itself, which is good. > > > > > > > > > > > > > > > > > > And I still don't see an example of where this demonstrat= es that > > > > > > > > > existing non-UEFI boot cases are now easier to handle or = cleaner to > > > > > > > > > handle or otherwise better. > > > > > > > > > > > > > > > > > > In that this is an attempt to tackle one of the long stan= ding needed > > > > > > > > > migrations (be able to drop board config.h files), someth= ing here needs > > > > > > > > > doing. But I don't see this as the right direction, sorr= y. > > > > > > > > > > > > > > > > Does anyone have a better idea for all of this? This is a s= olid base > > > > > > > > we can build on but we can't make any progress while this i= s just > > > > > > > > patches. What not apply it and we can move forward? > > > > > > > > > > > > > > > > > > > > > > I agree with Simon. Having a well documented flow, help to in= tegrate > > > > > > > products and have a standard > > > > > > > way to handle the booting flow > > > > > > > > > > > > > > > - solves the env problem for distro boot in that we don't n= eed the scripts > > > > > > > > - gets rid of the scripts which are a confusing mess > > > > > > > > - provides proper high-level concepts of boot device and bo= ot method > > > > > > > > - allows testing of the U-Boot part of 'can we boot' becaus= e we have > > > > > > > > tests for all the cases - we can expand this over time > > > > > > > > - allows non-UEFI boot cases like Chrome OS, which is curre= ntly just a > > > > > > > > hack for one board[1] > > > > > > > > - provides a programmatic base for A/B boot, etc. > > > > > > > > > > > > > > > > I feel the same way with Takahiro's series, which has been = out-of-tree > > > > > > > > for too long. > > > > > > > > > > > > > > I don't see the problem in having it merged. I'm dealing ever= y day > > > > > > > with crazy script > > > > > > > to handle situation like [1] and I think that company that in= tegrates > > > > > > > their product can > > > > > > > benefits on those changes. They can be improved with other pe= ople > > > > > > > wants to use it > > > > > > > in their products. > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > > > > > Please reconsider this. What do we have to lose? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Simon > > > > > > > > > > > > > > > > [1] CONFIG_BOOTCOMMAND=3D"tpm init; tpm startup TPM2_SU_CLE= AR; read mmc > > > > > > > > 0:2 100000 0 80; setexpr loader *001004f0; setexpr size *00= 100518; > > > > > > > > setexpr blocks $size / 200; read mmc 0:2 100000 80 $blocks;= setexpr > > > > > > > > setup $loader - 1000; setexpr cmdline_ptr $loader - 2000; s= etexpr.s > > > > > > > > cmdline *$cmdline_ptr; setexpr cmdline gsub %U \\\\${uuid};= if part > > > > > > > > uuid mmc 0:2 uuid; then zboot start 100000 0 0 0 $setup cmd= line; zboot > > > > > > > > load; zboot setup; zboot dump; zboot go;fi" > > > > > > > > > > > > OK, and what does your example here look like on top of Simon's= series? > > > > > > Or do you just mean ChromeOS boot? > > > > > > > > > > I can use some of our boards and move on to the Simon patchset. In > > > > > that case, are you happy with it? > > > > > > > > No, I'm not saying I'll take this if someone uses it somewhere. But > > > > I've been asking for in previous iterations for showing that it mak= es > > > > some existing use case easier. And I don't see any implementations= of > > > > that in v4. Adding UEFI boot to this isn't a good example since th= at's > > > > already being re-done via the UEFI boot manager series that impleme= nts > > > > what the spec says to do for that. > > > > > > I don't think that a lot of real use cases in embedded devices are > > > using distro boot but > > > they have proper customized boot flow and update, recovery. What you > > > call A, B and C. > > > Then we have a special recovery path that instead of using emmc , uses > > > a usb pen drive. Having > > > some more structure boot flow with documentation and some use cases > > > will help to have in uboot what it's in > > > private repositories. > > > > Exactly. My concern is that this does, or will end up, spending a lot > > of effort to replicate the "find an arbitrary bootable thing" logic the > > UEFI boot manager stuff has to do to that spec rather than making it > > easier to handle the common everything else cases where the developer > > knows the valid cases for normal boot and recovery boot and needs to do > > whatever validation is required there. Maybe that's where some of the > > hang up is. >=20 > I'm actually not sure where the hang-up is. We seem to be enforcing > UEFI everywhere in U-Boot. That must make some people very happy, but > it is not the right approach to take for a general purpose, > open-source, Universal Boot Loader. >=20 > If U-Boot is to remain a boot loader for non-UEFI cases, then I think > bootstd is an important step forward. There is more work to do, but it > sets up the basic abstractions and is a strong base to work from. >=20 > Or is U-Boot for UEFI only, with only 'boot manager' allowed to have a > structured boot? >=20 > I hope not, but I'm struggling to read much else from this thread. Perhaps you and I need to have a call at some point soon then? It is not my intention to make UEFI the only, or only well supported, way of booting things. --=20 Tom --dT+85zccSFkyJC53 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmI/cHEACgkQFHw5/5Y0 tyxdbwv+NsFsZQ0X9x/LcVYukIXZP6X/uOzNAPb0KobFXRO1EzKNmgqSNsEO7WIp 4YrOCxi8Mg+j8UNTs+ZD1FxH1rUXQfSDpNUNHQr7ofEIiBSbDeopEec/iL5x/Y+d 6yfD3Sy8OdMHzJWG3ZCDM6GDsOglGLhKD83v6sS5xoHGJS3RsS74z/g9RlSGaucP CQ/fk8p0bLsQUXdq7r/W35+NVASR9K9CXuAxNVvdSxlMIABODwwExQAQ6NLeZUQq EHkWWoQvoawjsfeDjfZfjswIfquaoN+iaUx4EUJQBHPQkDZz2ZUHN3h3cKBsO0uC nXR+OlMEynEw48hPGVdcJN3fe7oF+7rrIzl+mVS/CK8YWT7lB20MJc+SG0k1Vk/3 kSb0A3VqcCM0/EVt4F90oizGxOVTIa1pT6vaRazFlUeDvhCqcs15wo7NMi9hVbPU +nYvLhWSRXPoXB39vZav6Z6O8UOPQV6coHbnm1mjYreETUpINOHYJ8dIdSIYvKIT 8y7VAJyK =WnkX -----END PGP SIGNATURE----- --dT+85zccSFkyJC53--