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 CAA05C433F5 for ; Wed, 23 Mar 2022 20:07:18 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 744C683AAA; Wed, 23 Mar 2022 21:07:16 +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="AFRv6of2"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 45A0283F8A; Wed, 23 Mar 2022 21:07:13 +0100 (CET) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 54E6B83AAA for ; Wed, 23 Mar 2022 21:07:08 +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-x835.google.com with SMTP id a11so2156005qtb.12 for ; Wed, 23 Mar 2022 13:07:08 -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=VZwfMVGVKZXclcVrJLWf2G7D7+NKoBrzUBa+iFNQ0VM=; b=AFRv6of2VL3XkkNJkdHJtygdcWg1eTqfxJLeqeMRPU1Uk667wcGjwQj7QMODteSXrr GJDrjnoXpg3X/baAqS28PDXppKNRZ8LcGm/Q+GVVqbLi/D6U6rhNSig8ytgafgnwN/Mw oQLoQi8YNVCUN5F7MiNNcjomppkq+uwB3Qp+g= 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=VZwfMVGVKZXclcVrJLWf2G7D7+NKoBrzUBa+iFNQ0VM=; b=2VCCDdzESZHfVJvsax9BFL4zNwsBsRfjMxGnPp4RxqoMBpqg13pPdoXx1RnpCRR95G lEz1Wv1FVywOM7XZlEjhLp1BnfFRHkF6oV2ta9tJ5tqssuWPOl7SUM3eAqkm7bTH6t+F PMrQU4FpCI5Incw/yMknyADgPpAn2VmjzGSFV8yKXpKCPdyiiB9Ie/dyn2M0BEoOzvhK EFsKK5MNO+pnOwGP7PbxjF+XIuHNRUwi3lNNzOvT8BHYQhvfNo7KDxuvCtzo+bEPI9uX ImhKX/kLkks9xA5ItBu5yTuO6tDk6qQ2b5hLRnaFpY/vDtndaY7BLGRpOSOk9lkLTCPm oc6w== X-Gm-Message-State: AOAM530xxAQekaDCuR5nyHyoL22qaQu/Yaxq253Ejh5UdTj5hj7+VbqF 3zFf/upv34tkKzNfquQ2S6Dn2Q== X-Google-Smtp-Source: ABdhPJxuvuLPBn45oa+mAjQn3OeVplMDGf7eDPAMRnRnAH651fovwNacVe7bV/PCVoCHASUtYl3vow== X-Received: by 2002:ac8:7fc2:0:b0:2e1:a407:b1f1 with SMTP id b2-20020ac87fc2000000b002e1a407b1f1mr1374678qtk.399.1648066026898; Wed, 23 Mar 2022 13:07:06 -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 g1-20020ae9e101000000b0067d4bfffc57sm451875qkm.117.2022.03.23.13.07.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 13:07:06 -0700 (PDT) Date: Wed, 23 Mar 2022 16:07:03 -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: <20220323200703.GN2226424@bill-the-cat> References: <20220306125016.3133737-1-sjg@chromium.org> <20220323140500.GF2226424@bill-the-cat> <20220323193013.GM2226424@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Xc2zRdLclVh020+J" 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 --Xc2zRdLclVh020+J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 23, 2022 at 08:57:36PM +0100, Michael Nazzareno Trimarchi wrote: > Hi Tom >=20 > On Wed, Mar 23, 2022 at 8:30 PM Tom Rini wrote: > > > > On Wed, Mar 23, 2022 at 08:21:22PM +0100, Michael Nazzareno Trimarchi w= rote: > > > 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 wrote: > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to autom= atically > > > > > > boot an Operating System without custom scripting and other cus= tomisation. > > > > > > 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 bootflows (o= wned by > > > > > > U-Boot) > > > > > > - bootflow - a description of how to boot (owned by the dist= ro) > > > > > > > > > > > > This series provides an implementation of these, enabled to sca= n for > > > > > > bootflows from MMC, USB and Ethernet. It supports the existing = distro > > > > > > boot as well as the EFI loader flow (bootefi/bootmgr). 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 b= oot each > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > With a standard way to identify boot devices, booting become ea= sier. It > > > > > > also should be possible to support U-Boot scripts, for backwards > > > > > > compatibility only. > > > > > > > > > > > > This series relies on the PXE clean-up series, posted here: > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=3D26= 7078 > > > > > > > > > > > > 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 1300 t= imes 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 matter of c= reating a > > > > > > bootmeth for it and implementing the read_file() and boot() met= hods. > > > > > > > > > > > > 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__vBkj3l61L2dav4ZkNC= 12/view?usp=3Dsharing > > > > > > > > > > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6F= F9/view?usp=3Dsharing > > > > > > > > > > I keep putting off commenting more here, but, I still feel this i= s the > > > > > wrong direction. What problems do we have today with distro boot? > > > > > Well, we haven't figured out how to move configuring it out of th= e board > > > > > config.h file. But that's just one of a half dozen or so example= s of > > > > > how we haven't figured out a good solution to configuring the def= ault > > > > > environment. And only some of those other examples are boot rela= ted > > > > > (the NXP chain of trust booting stuff is another boot example, ET= HPRIME, > > > > > HOSTNAME, etc, are non-boot examples). > > > > > > > > > > We also aren't improving testing of "can we boot" here, because w= hat > > > > > 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. This = adds > > > > > tests for itself, which is good. > > > > > > > > > > And I still don't see an example of where this demonstrates 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 standing nee= ded > > > > > 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 just > > > > patches. What not apply it and we can move forward? > > > > > > > > > > I agree with Simon. Having a well documented flow, help to integrate > > > 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 method > > > > - 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 jus= t 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-t= ree > > > > 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 integrates > > > 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 *00100518; > > > > setexpr blocks $size / 200; read mmc 0:2 100000 80 $blocks; setexpr > > > > setup $loader - 1000; setexpr cmdline_ptr $loader - 2000; setexpr.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; zb= oot > > > > 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? >=20 > 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 Tom --Xc2zRdLclVh020+J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmI7feQACgkQFHw5/5Y0 tyx6kQv+LpqoDZSpt/w6znNEISRSYPYBCS2DSwTRh1lcq3iOtLp41NM78EgT1mw0 GTDFdnvFpFBQAAu0NBwXNRCdS8Pv9W+Ge7vnAf1Z97EscdaL8CVWxOzOTR/Qc2rn mSrdbuPFx/VOs/F5xi/YbDpCJr9k1+OkYrrpY8kUsElR9Pjf2ZhQ3e4dvHY31n34 R7aOhmqQgxhco39xg23HVdjmYs6r+qJq7nQyFoFMg9p7UO5f9JxLbSaP/FhektMq oKrhsoVHbSJ3y/UHgqUKl0MNMhsiR3FPUEt6R6YZyFlgPqug/ia1ApxzGWEg4jQ4 nk7mJzeszqKXmlY+0TuUxxLhxRj9tomta0hniPuyzT4gXAhSyr5uPhnUa0HmQcjp H6l98RvnQru90pKpOS7biojT7qWoxBfYFoSfTIJ1wzPkzu8KHkw4F4pWhPSl91Nx HGaOouPsbd/DooFl7szIHENMphxMnD0OO2STQ4Ii9kjREVTJIVdwv1NQsiD4Dlbp euLxWAFZ =pBYS -----END PGP SIGNATURE----- --Xc2zRdLclVh020+J--