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 6898EC433EF for ; Wed, 23 Mar 2022 19:30:28 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3BB97800C2; Wed, 23 Mar 2022 20:30:26 +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="VV6Szc0G"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7EA2A83F99; Wed, 23 Mar 2022 20:30:23 +0100 (CET) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 5A39483F8A for ; Wed, 23 Mar 2022 20:30:18 +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-qk1-x729.google.com with SMTP id i65so1896993qkd.7 for ; Wed, 23 Mar 2022 12:30:18 -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=y9DFZ1A34cE2x/FNyUIq9kxfkU2vre74Pf65NWj5+1w=; b=VV6Szc0Gxy/VDoeyxfEp27+tlM+2dhIeKPGds644ybtntZMZn8ZHcalAYFh1XTatiD ZGQggtYkm/wUz1J0PNJBeyJrigN2BOMOGtJf2X/3xGq2p/MR68rc9QjP51mCBrlA4nNd 0D7gGFQzHkr2kXuPYRCF8el9Tk1eMdX/cjKPc= 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=y9DFZ1A34cE2x/FNyUIq9kxfkU2vre74Pf65NWj5+1w=; b=AOh1OvA7YQtqMK9n1Q+xcE/RsSixfx9hi1X0Im+PXs9MpZKkhgw9Daxhj0mx5Udi+o 1Z1KYwcqmbK3gB2xGcobac1rrcs7U+1D2cAF3hD0oxUg3p6rUNX37bk7Ec7BPi2gxv1k ldo4vcR0ynTu/kgqOvO1chTgZIB2iZpe9DzkWNkSMIwpTmrnuv5YjFGDfa5gtNLxr3oO 4yMnROXiKyWgk2k5hCaskdOuiC/eNJKSnjT1Ksy8eacYYZeNlJeJ4CMmIia7/NiWki6N FAOd/tCYnpGCKiwF38XlXtfVyUHBPQpqdgAbQFrBzJ1Q2WQ6mvcAOOSwa0cxwGZanEwm DmJw== X-Gm-Message-State: AOAM5323YbGRaBokU0pepyVfAEq/ueF8NYsIC0Q0VrNsciD9tkOGO46p AKIgpQus8jXFhsjY6FOm04pmow== X-Google-Smtp-Source: ABdhPJzW6AOejJMmqDrYtOIEA+pRJQs++gUrwMxLyurOysCupMxgR1avCxWr1jURyArj8En/kR921g== X-Received: by 2002:a05:620a:1aa4:b0:67d:52ab:b1dd with SMTP id bl36-20020a05620a1aa400b0067d52abb1ddmr1001911qkb.773.1648063817054; Wed, 23 Mar 2022 12:30:17 -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 h8-20020ac87d48000000b002e1c6faae9csm634436qtb.28.2022.03.23.12.30.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 12:30:16 -0700 (PDT) Date: Wed, 23 Mar 2022 15:30:13 -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: <20220323193013.GM2226424@bill-the-cat> References: <20220306125016.3133737-1-sjg@chromium.org> <20220323140500.GF2226424@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rKOd0RGqnoxbj4so" 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 --rKOd0RGqnoxbj4so Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 23, 2022 at 08:21:22PM +0100, Michael Nazzareno Trimarchi wrote: > Hi Tom >=20 > 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 automatic= ally > > > > boot an Operating System without custom scripting and other customi= sation. > > > > 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 (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 existing dist= ro > > > > 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 boot = each > > > > one (-b). The final patch shows this. > > > > > > > > With a standard way to identify boot devices, booting become easier= =2E 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=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 ove= rused, > > > > is everywhere in U-Boot, can be confused with udevice > > > > - bootmeth - because 'method' is too vanilla, appears 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 matter of creat= ing a > > > > bootmeth for it and implementing the read_file() and boot() methods. > > > > > > > > Version 4 makes some minor improvements and leaves out the RFC patc= h for > > > > rpi conversion, in the hope of getting the base support applied soo= ner > > > > rather than later. > > > > > > > > The design is described in these two documents: > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/v= iew?usp=3Dsharing > > > > > > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/v= iew?usp=3Dsharing > > > > > > I keep putting off commenting more here, but, I still feel this 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 of the bo= ard > > > 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 boot related > > > (the NXP chain of trust booting stuff is another boot example, ETHPRI= ME, > > > HOSTNAME, etc, are non-boot examples). > > > > > > We also aren't improving testing of "can we boot" here, because what > > > THAT needs is setting up LAVA and booting some installers on some > > > hardware (and some QEMU). That's testing that Linux boot works. Tod= ay > > > 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 needed > > > migrations (be able to drop board config.h files), something here nee= ds > > > 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? > > >=20 > I agree with Simon. Having a well documented flow, help to integrate > products and have a standard > way to handle the booting flow >=20 > > - solves the env problem for distro boot in that we don't need the scri= pts > > - 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 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. >=20 > 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. >=20 > Michael >=20 > > > > 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; 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? --=20 Tom --rKOd0RGqnoxbj4so Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmI7dUMACgkQFHw5/5Y0 tyx4xgv+JRP8YthceyP44Y4QgQwz9/0ncIN0om6z+vnTGtj62wmyZdDLNeu5xrqZ WTNj1uMZAR3vJF/LQKMuHZEvrJtGiSZMccn+I2L32wUkL4lKMYEg7EPUlomfGFQa wCiothfqWQZzoUajqYsRtKjR7sq3I4FV2P7HThRlBiDiiuCx9gOM3AErzrBrCqI0 /lQOSodPXdxHLN1jWnHkF6Rwm6vdH0mcWFdAgtMT1r+n/kIhIwKAdL+ziiLF3D9g rWW2iK6pEhS8eS/IJym9vPACJH+dheVY78kteGUmeo12TdabeyWrcy49lg8dN4QT kGGiyHw1NKdp8P1smEJyVbUS3hLR9/oX31jEEnM5w1fsLzAMWRoT5CxkzEl0GS6k 6Af/CMdJLUuzmd4hlAgz+5moJDVWI8By0hks9xjrGPVhHebwkOr/x3XzTKBIO3Zn Q+OEhWnBFFtg2fFB0Z72GvIQbCKz6mJcWYo5P0tbN6QvWW4EL/xESmW3WPiCUdwd IRjjTkzf =BU8N -----END PGP SIGNATURE----- --rKOd0RGqnoxbj4so--