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 8D662C433EF for ; Fri, 25 Mar 2022 14:50:30 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 592FE82DD7; Fri, 25 Mar 2022 15:50:28 +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="mZbI0/0p"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DDC3082A3A; Fri, 25 Mar 2022 15:50:26 +0100 (CET) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 ED74D841BA for ; Fri, 25 Mar 2022 15:50:22 +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-qv1-xf2f.google.com with SMTP id jo24so6387388qvb.5 for ; Fri, 25 Mar 2022 07:50:22 -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=Fb6XZWNR30+LDWe2bESySBIMqul9H677ZkbAvwHLB8U=; b=mZbI0/0pIaY2oEp5Yd3/geIi+fzru3EWRdYt+TZaEY7GuV7XsJUVv6u8fZPBbeYhno Q0+DAAFblBD/9CFg7qZiPYAO8Cx+ueBFG0sC+yVT5ZWXpXhzCeuWpxooHc6YzMjO8a5u xw7Dc3qV/KTgz0a4V7xfm6D+a+j+H25iZ/qp0= 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=Fb6XZWNR30+LDWe2bESySBIMqul9H677ZkbAvwHLB8U=; b=EZSQnc2nIL4Rza+MO+ceMnEXYY9cBMasuriPnZzrlTUI3vHAaClvQWwAzm1lTuyHUJ D/+JdTSYtgq7uozOOJ3kWyO5d7BRZXIwFfDlBMqI0lpbpLECq7h6SY8/vSD1AfOAzeJF 2Uh0RH1lwL1QXKGpg6F3S8oFifV3f/jYVDyo5ymzrsoioMs2PSr1906kmGq7cB3xP2Nd ng0a5/9HW4rj/mpubVBYst0RKW0uEzefABWEZBqmKb8vRB32B3Kz4FYHrYlTjH64g5o6 4YR+2on1ew5kD+tVixTtXI13j1EhKsBiaYIHRL/81XlBh4sat2p/QnL2f7dDZIolLjkX Z59g== X-Gm-Message-State: AOAM5313rIWgtQnXJYND5IF/PwJCy1Y2k3S43aAQwCTq/KPnIRSBdrtt PHIxFLk1K3ATHPcXYjmIeICYNA== X-Google-Smtp-Source: ABdhPJwWy43gInvbBeSzY98d+bn7ZtL0s950XyHRJbto1G5T18WKm4im1CoIKTAgs8OGXlGV9nMdLA== X-Received: by 2002:ad4:5dc9:0:b0:441:56ad:8d93 with SMTP id m9-20020ad45dc9000000b0044156ad8d93mr9260738qvh.76.1648219821305; Fri, 25 Mar 2022 07:50:21 -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 21-20020ac85715000000b002e1ce9605ffsm5450919qtw.65.2022.03.25.07.50.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 07:50:20 -0700 (PDT) Date: Fri, 25 Mar 2022 10:50:18 -0400 From: Tom Rini To: Michael Nazzareno Trimarchi Cc: Simon Glass , 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: <20220325145018.GY2226424@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9rrfksQwzphoq1W+" 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 --9rrfksQwzphoq1W+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2022 at 03:36:24PM +0100, Michael Nazzareno Trimarchi wrote: > Hi Tom >=20 >=20 > On Wed, Mar 23, 2022 at 9:07 PM Tom Rini wrote: > > > > On Wed, Mar 23, 2022 at 08:57:36PM +0100, Michael Nazzareno Trimarchi w= rote: > > > Hi Tom > > > > > > On Wed, Mar 23, 2022 at 8:30 PM Tom Rini wrote: > > > > > > > > On Wed, Mar 23, 2022 at 08:21:22PM +0100, Michael Nazzareno Trimarc= hi wrote: > > > > > Hi Tom > > > > > > > > > > On Wed, Mar 23, 2022 at 7:46 PM Simon Glass wr= ote: > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > On Wed, 23 Mar 2022 at 08:05, Tom Rini wro= te: > > > > > > > > > > > > > > On Sun, Mar 06, 2022 at 05:49:43AM -0700, Simon Glass wrote: > > > > > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to a= utomatically > > > > > > > > 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 bootflow= s (owned by > > > > > > > > U-Boot) > > > > > > > > - bootflow - a description of how to boot (owned by the = distro) > > > > > > > > > > > > > > > > This series provides an implementation of these, enabled to= scan for > > > > > > > > bootflows from MMC, USB and Ethernet. It supports the exist= ing distro > > > > > > > > boot as well as the EFI loader flow (bootefi/bootmgr). It w= orks > > > > > > > > similiarly to the existing script-based approach, but is na= tive 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. > > > > > > > > > > > > > > > > With a standard way to identify boot devices, booting becom= e easier. It > > > > > > > > also should be possible to support U-Boot scripts, for back= wards > > > > > > > > compatibility only. > > > > > > > > > > > > > > > > This series relies on the PXE clean-up series, posted here: > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series= =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 'device= ' is overused, > > > > > > > > is everywhere in U-Boot, can be confused with udevice > > > > > > > > - bootmeth - because 'method' is too vanilla, appears 13= 00 times in > > > > > > > > U-Boot > > > > > > > > > > > > > > > > Also in version 2, drivers are introduced for the boot meth= ods, to make > > > > > > > > it more extensible. Booting a custom OS is simply a matter = of creating a > > > > > > > > bootmeth for it and implementing the read_file() and boot()= methods. > > > > > > > > > > > > > > > > Version 4 makes some minor improvements and leaves out the = RFC patch for > > > > > > > > rpi conversion, in the hope of getting the base support app= lied sooner > > > > > > > > rather than later. > > > > > > > > > > > > > > > > The design is described in these two documents: > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4= ZkNC12/view?usp=3Dsharing > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3W= YG6FF9/view?usp=3Dsharing > > > > > > > > > > > > > > I keep putting off commenting more here, but, I still feel th= is is the > > > > > > > wrong direction. What problems do we have today with distro = boot? > > > > > > > Well, we haven't figured out how to move configuring it out o= f the board > > > > > > > config.h file. But that's just one of a half dozen or so exa= mples of > > > > > > > how we haven't figured out a good solution to configuring the= default > > > > > > > environment. And only some of those other examples are boot = related > > > > > > > (the NXP chain of trust booting stuff is another boot example= , ETHPRIME, > > > > > > > HOSTNAME, etc, are non-boot examples). > > > > > > > > > > > > > > We also aren't improving testing of "can we boot" here, becau= se what > > > > > > > THAT needs is setting up LAVA and booting some installers on = some > > > > > > > hardware (and some QEMU). That's testing that Linux boot wor= ks. 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. T= his adds > > > > > > > tests for itself, which is good. > > > > > > > > > > > > > > And I still don't see an example of where this demonstrates t= hat > > > > > > > existing non-UEFI boot cases are now easier to handle or clea= ner to > > > > > > > handle or otherwise better. > > > > > > > > > > > > > > In that this is an attempt to tackle one of the long standing= needed > > > > > > > migrations (be able to drop board config.h files), something = here needs > > > > > > > doing. But I don't see this as the right direction, sorry. > > > > > > > > > > > > Does anyone have a better idea for all of this? This is a solid= base > > > > > > we can build on but we can't make any progress while this is ju= st > > > > > > patches. What not apply it and we can move forward? > > > > > > > > > > > > > > > > I agree with Simon. Having a well documented flow, help to integr= ate > > > > > products and have a standard > > > > > way to handle the booting flow > > > > > > > > > > > - solves the env problem for distro boot in that we don't need = the scripts > > > > > > - gets rid of the scripts which are a confusing mess > > > > > > - provides proper high-level concepts of boot device and boot m= ethod > > > > > > - allows testing of the U-Boot part of 'can we boot' because we= have > > > > > > tests for all the cases - we can expand this over time > > > > > > - allows non-UEFI boot cases like Chrome OS, which is currently= 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 every day > > > > > with crazy script > > > > > to handle situation like [1] and I think that company that integr= ates > > > > > their product can > > > > > benefits on those changes. They can be improved with other people > > > > > 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_CLEAR; = read mmc > > > > > > 0:2 100000 0 80; setexpr loader *001004f0; setexpr size *001005= 18; > > > > > > setexpr blocks $size / 200; read mmc 0:2 100000 80 $blocks; set= expr > > > > > > setup $loader - 1000; setexpr cmdline_ptr $loader - 2000; setex= pr.s > > > > > > cmdline *$cmdline_ptr; setexpr cmdline gsub %U \\\\${uuid}; if = part > > > > > > uuid mmc 0:2 uuid; then zboot start 100000 0 0 0 $setup cmdline= ; zboot > > > > > > load; zboot setup; zboot dump; zboot go;fi" > > > > > > > > OK, and what does your example here look like on top of Simon's ser= ies? > > > > 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 makes > > 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 that's > > already being re-done via the UEFI boot manager series that implements > > what the spec says to do for that. >=20 > 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 Tom --9rrfksQwzphoq1W+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmI91qYACgkQFHw5/5Y0 tyzmoAv9G4JlnNWTkWJYoNKUfyzxLvFUdC6z0u7PEwWFwBETSafO41WZhlV9S0qF 6UgEKCsq33Dqtk2wuAjfyCiMhqr3+I8HHcHd8qtnCXHYj07dqQirTby85/HFbbzt JCcm74VtUu08H3eqXiiA8w3tDj1hQ47aOzORqxsbnn/1+9Xu+Pf3AX5sDO/ZaoAK keV1pObcwij96i/JFS7lgDndqZwWklun9EpVezydVPUl9qx8TpHFu0GrvLePj6tW 12dJdN0PY4oaT5rfl1U//a8BPv0LH3fl2GfTc+rmXz27lwzPfvpRYrX5uZuzWNaF SHR4Zj5UjRDbpnK3LZ6XgVwFo4CI6rLEfazd4Y83bgqw3beFT4gE0oKW2GcLJroz J/nynjo7A9PmTkDxbvcERPi9LhyYRGXRrJ2uUhnOgPvbdCVHrU16HcV0FSsPzEG+ TISjHQDENF2DMQRm8yW4joOPC/uHRg2c1I9DDr7Mor9re8gKC3djONq6xmytaD09 WNvZJK2L =jcD9 -----END PGP SIGNATURE----- --9rrfksQwzphoq1W+--