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 09684C433F5 for ; Wed, 23 Mar 2022 14:05:27 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id B5A8483CFD; Wed, 23 Mar 2022 15:05:17 +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="OI03jP2H"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 799C483CD8; Wed, 23 Mar 2022 15:05:11 +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 3B58083CF3 for ; Wed, 23 Mar 2022 15:05:05 +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 c4so1197943qtx.1 for ; Wed, 23 Mar 2022 07:05:05 -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=sHx9RDX5weWWHEuba5q8HL81evcueAX6P4FKVPk3rTQ=; b=OI03jP2HgBoS6+jYfww2voifLJXaKTu+Z1k7MpNUtVScTw9NcYxQsc/TrzuQp5x1JS MVK8456OTqIAF/UYzMp5/fxnsk8Dq+C06Ml1xbb/VSoo6KkDORHh6SAvXgpxk/2ZS1FW 3EIyGTYdOnrwypijvWJTzEXH/JvuOM5n/Jw+Q= 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=sHx9RDX5weWWHEuba5q8HL81evcueAX6P4FKVPk3rTQ=; b=qCutD6++w6whOjJ3Urad86is7VB/ih8os79So0a49MJfYnc1uKC3mloIRjCXa6x4vB WjKleikTPyVgq1wKJrm2j3s1yL3UZQmOUheU5cqw3F4gA35AtNGGYZZ6oWGZSH1aBgET dF84a48L1L0dkIeXirC0EaW40+eqPBBYVhAkPyKrPVDA/4Yf0Ikw4gWE1dSKGbXY8qG+ t7z9frXOfphEPi2/L4bIxkDVy6JKf2Ey3/QOhTnjyl6URDr6uq+3j8ToVFfjkoB+Ec51 yR2ww5Qcyu3QhcETahkuhte3YfE/EBvHX99Oc810Jaame34Or94Txa84MjwfQu/fJw3W 8pCw== X-Gm-Message-State: AOAM533kT5sE+XehHwuO+vLKCx6h+zjQp4c+Yh+6cmOqotdx3qXrSKXu gSGpuoChZrZFNIbNdH+a3MqFYBYP6v6FNlxC X-Google-Smtp-Source: ABdhPJxtaTKn/FmWAAZX+exukjqqO/QAgtptibzkVmcV17n2wSJyjp/lKW8s4PpFjuD0ii1mYcpNnA== X-Received: by 2002:ac8:4e51:0:b0:2e2:1621:c258 with SMTP id e17-20020ac84e51000000b002e21621c258mr10430068qtw.376.1648044303761; Wed, 23 Mar 2022 07:05:03 -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 e20-20020ac84e54000000b002e06753cf70sm140957qtw.6.2022.03.23.07.05.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 07:05:02 -0700 (PDT) Date: Wed, 23 Mar 2022 10:05:00 -0400 From: Tom Rini To: Simon Glass Cc: 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: <20220323140500.GF2226424@bill-the-cat> References: <20220306125016.3133737-1-sjg@chromium.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sHH6Fs2aY7VPW+Vm" Content-Disposition: inline In-Reply-To: <20220306125016.3133737-1-sjg@chromium.org> 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 --sHH6Fs2aY7VPW+Vm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 06, 2022 at 05:49:43AM -0700, Simon Glass wrote: >=20 > The bootflow feature provide a built-in way for U-Boot to automatically > 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. >=20 > It introduces the following concepts: >=20 > - 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) >=20 > This series provides an implementation of these, enabled to scan 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. >=20 > With this we can boot on a Raspberry Pi 3 with just one command: >=20 > bootflow scan -lb >=20 > which means to scan, listing (-l) each bootflow and trying to boot each > one (-b). The final patch shows this. >=20 > With a standard way to identify boot devices, booting become easier. It > also should be possible to support U-Boot scripts, for backwards > compatibility only. >=20 > This series relies on the PXE clean-up series, posted here: >=20 > https://patchwork.ozlabs.org/project/uboot/list/?series=3D267078 >=20 > For documentation, see the 'doc' patch. >=20 > For version 2, a new naming scheme is used as above: >=20 > - 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 times in > U-Boot >=20 > 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 creating a > bootmeth for it and implementing the read_file() and boot() methods. >=20 > 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. >=20 > The design is described in these two documents: >=20 > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?us= p=3Dsharing >=20 > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?us= p=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 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 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, 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. 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 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. --=20 Tom --sHH6Fs2aY7VPW+Vm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmI7KQkACgkQFHw5/5Y0 tywxgAv/ca2oJR36F+jOsNVe+zz5P1OSrHl/nAzMtnURaVR8B5jknUuyQZA63agc BvSqnhjvwC4OsHyz602fvFMgldH/b7913WGjgfmKfuaS/6iTV1bbQmKT4W2otQJv wnwRw89kkAbQFGKAuPbUn2DCCqxG81vB4bdoRQ04WetTD8S+SPd0cbgAQgSNQUC8 8wa+a1jbF8F3EdaHU15pnHKtL6u0ivsj8HYMkACUkmlNABYhfphxV6sWWoZDRchz AUBjSLmYa4zM4eh7sZgtl8kK1LdbErIUoGApP4yerjBZw9rK4muD0xWvXcu3wjwD Sj0F8x/GkJdwQ94CKqMvXApTrMTw0xJkpR7rV7Hv/47rM4zUi7MS5LwNgwKWWmEw b2lb7SMp6HH21nQTU6u+n2rv49bZVOUZ3C/jW4w1vpP1KyONPiOcUF9QsYMCbQXA 9RhX6g7m0UpqF/0Hqy7kewWai3MGRi0PIJZp26axIdZIWuGre9JEDZiyiS/L8f2w 1b2RsQ21 =8Dmz -----END PGP SIGNATURE----- --sHH6Fs2aY7VPW+Vm--