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 E5CDFC433F5 for ; Fri, 21 Jan 2022 18:41:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 71FA0820AC; Fri, 21 Jan 2022 19:41:47 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (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="ojOcSFXJ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A79F582149; Fri, 21 Jan 2022 19:41:46 +0100 (CET) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 9741D81E25 for ; Fri, 21 Jan 2022 19:41:43 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x732.google.com with SMTP id 193so10848816qkh.13 for ; Fri, 21 Jan 2022 10:41:43 -0800 (PST) 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=tbM/ze6xl2OJ0prufDHACrS8Krf3cio4kRXPCpqAP7k=; b=ojOcSFXJn6gdutUgirgilE+KcotJgBxmoY9Xbj+oTPlHnA3gs5mkA6r9xlbs9LjDC7 R8WsxnP2Aj4w+blufEtrTAIl6dG8BhwwJSbEDf/oZaIQa38vslNWe7KVrPF68y16JPrr 2sJAHR5VUyOg8as5s/WXzTEEgLWSMvjyfp1eY= 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=tbM/ze6xl2OJ0prufDHACrS8Krf3cio4kRXPCpqAP7k=; b=vpUqKT2Lg6OX4UCvKftOjaDoTSw0VGzQuZJ0ga5qdAKCkApodvJI1rlSOYvlXvSnS2 C3XzO48Vict6ow3iK+ZLcD3pH3z++CpinTpjTax1pcsSZ6xEiWVrj3SCpNUgJf2OqFSl RF5AbKcfRhkujNYnjfunVjMLd5iYqJzs3i3ubzCeW9lCf1dF7DGQ0oJ9i2yiij8NQq3a pH9ogOO/iRV1vqsVvqSeK3qvnPMFUxbQ3LGPnWZEAfcsy/AHqrv1sVsvKP4aSiljErAt hvkeGzc11eByeGRkkayX7ny1XOS/WGkHFP7Vh8IKClYB6K+Wxnk1J28pzJScE+EfMfn1 dpoQ== X-Gm-Message-State: AOAM533QA0cbTiwnkkyHYAXDVbF9XkRSe5sJr3uk3VRBJgnSGt8LHLfC RHzIq/vBazSoNT+yXdZQemBC7Q== X-Google-Smtp-Source: ABdhPJx7EUd5V1CkwW7A8AHmqbBfgMOrjPyHD6ZMbLjSGeNcYXOJVDhnJOoqFwb4KswAsrh3tzImfw== X-Received: by 2002:a05:620a:25d0:: with SMTP id y16mr3743278qko.602.1642790502324; Fri, 21 Jan 2022 10:41:42 -0800 (PST) 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 o21sm3569024qtv.68.2022.01.21.10.41.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jan 2022 10:41:41 -0800 (PST) Date: Fri, 21 Jan 2022 13:41:39 -0500 From: Tom Rini To: Mark Kettenis Cc: Simon Glass , heinrich.schuchardt@canonical.com, ilias.apalodimas@linaro.org, daniel.schwierzeck@gmail.com, dennis@ausil.us, jaeckel-floss@eyet-services.de, lukas.auer@aisec.fraunhofer.de, michal.simek@xilinx.com, u-boot@lists.denx.de Subject: Re: [PATCH v3 30/31] bootstd: doc: Add documentation Message-ID: <20220121184139.GA7004@bill-the-cat> References: <20220119014315.1938157-1-sjg@chromium.org> <20220119014315.1938157-20-sjg@chromium.org> <28d88952-e1aa-46cd-fd60-ac52cd2ab43b@canonical.com> <20220121150850.GT7004@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VxBmi9VgMIlnmxn8" 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 --VxBmi9VgMIlnmxn8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 21, 2022 at 07:22:55PM +0100, Mark Kettenis wrote: > > From: Simon Glass > > Date: Fri, 21 Jan 2022 09:53:37 -0700 > >=20 > > Hi Mark, > >=20 > > On Fri, 21 Jan 2022 at 09:03, Mark Kettenis w= rote: > > > > > > > From: Simon Glass > > > > Date: Fri, 21 Jan 2022 08:20:17 -0700 > > > > > > > > Hi, > > > > > > > > On Fri, 21 Jan 2022 at 08:08, Tom Rini wrote: > > > > > > > > > > On Wed, Jan 19, 2022 at 12:39:03PM +0100, Heinrich Schuchardt wro= te: > > > > > > On 1/19/22 02:43, Simon Glass wrote: > > > > > > > Add documentation for this feature, including the commands an= d full > > > > > > > devicetree bindings. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > --- > > > > > > > > > > > > > > Changes in v3: > > > > > > > - Update docs for "bootmeths" and "boot_targets" env vars > > > > > > > > > > > > > > MAINTAINERS | 4 + > > > > > > > doc/develop/bootstd.rst | 638 +++++++++++++++= +++++++++++ > > > > > > > doc/develop/distro.rst | 3 + > > > > > > > doc/develop/index.rst | 1 + > > > > > > > doc/device-tree-bindings/bootdev.txt | 18 + > > > > > > > doc/device-tree-bindings/bootmeth.txt | 31 ++ > > > > > > > doc/device-tree-bindings/bootstd.txt | 8 + > > > > > > > doc/usage/bootdev.rst | 135 ++++++ > > > > > > > doc/usage/bootflow.rst | 427 +++++++++++++++= ++ > > > > > > > doc/usage/bootmeth.rst | 108 +++++ > > > > > > > doc/usage/index.rst | 3 + > > > > > > > 11 files changed, 1376 insertions(+) > > > > > > > create mode 100644 doc/develop/bootstd.rst > > > > > > > create mode 100644 doc/device-tree-bindings/bootmeth.txt > > > > > > > create mode 100644 doc/usage/bootdev.rst > > > > > > > create mode 100644 doc/usage/bootflow.rst > > > > > > > create mode 100644 doc/usage/bootmeth.rst > > > > > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > > > > index 8ad70d3d968..c2af8ada3c9 100644 > > > > > > > --- a/MAINTAINERS > > > > > > > +++ b/MAINTAINERS > > > > > > > @@ -669,6 +669,10 @@ F: boot/bootmeth*.c > > > > > > > F: boot/bootstd.c > > > > > > > F: cmd/bootdev.c > > > > > > > F: cmd/bootflow.c > > > > > > > +F: doc/develop/bootstd.rst > > > > > > > +F: doc/usage/bootdev.rst > > > > > > > +F: doc/usage/bootflow.rst > > > > > > > +F: doc/usage/bootmeth.rst > > > > > > > F: drivers/mmc/mmc_bootdev.c > > > > > > > F: include/bootdev.h > > > > > > > F: include/bootflow.h > > > > > > > diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst > > > > > > > new file mode 100644 > > > > > > > index 00000000000..1b65a806efb > > > > > > > --- /dev/null > > > > > > > +++ b/doc/develop/bootstd.rst > > > > > > > @@ -0,0 +1,638 @@ > > > > > > > +.. SPDX-License-Identifier: GPL-2.0+: > > > > > > > + > > > > > > > +U-Boot Standard Boot > > > > > > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > + > > > > > > > +Introduction > > > > > > > +------------ > > > > > > > + > > > > > > > +Standard boot provides a built-in way for U-Boot to automati= cally boot > > > > > > > +an Operating System without custom scripting and other custo= misation. It > > > > > > > +introduces the following concepts: > > > > > > > + > > > > > > > + - bootdev - a device which can hold or access a distro (= e.g. MMC, Ethernet) > > > > > > > + - bootmeth - a method to scan a bootdev to find bootflows= (e.g. distro boot) > > > > > > > + - bootflow - a description of how to boot (provided by th= e distro) > > > > > > > + > > > > > > > +For Linux, the distro (Linux distribution, e.g. Debian, Fedo= ra) is responsible > > > > > > > +for creating a bootflow for each kernel combination that it = wants to offer. > > > > > > > > > > > > This gets it completely wrong. There is one standardized boot f= low: UEFI. > > > > > > All major distros support this. U-Boot has to offer UEFI bootin= g out of the > > > > > > box. > > > > > > > > > > I want to jump up and down and emphasize this part as well. Whil= e I > > > > > believe our UEFI bootmgr is still missing the normal scan code, t= hat's > > > > > something that has been promised to be implemented. And that tur= ns the > > > > > bootcmd for platforms that just want to support modern off the sh= elf > > > > > distros in to something fairly small. > > > > > > > > Sigh... > > > > > > > > UEFI is a bootflow in this model, one of many. If we don't support = the > > > > others, then U-Boot is not U-Boot anymore, it is just EFI Boot. > > > > > > > > If we get EFI bootmgr going, then are you saying you want to disable > > > > everything else? > > > > > > > > You say 'major distros' but there are many that don't use it, > > > > particularly in the embedded space. I'll go out on a limb and say t= hat > > > > the vast majority of embedded devices in the world don't use it. Are > > > > you really saying we should drop support for everything else? Even = the > > > > distro stuff supports other options. > > > > > > And U-Boot supports a wide variety of CPUs and some of those don't > > > even have official UEFI support. > > > > > > However, on arm64 (and possibly riscv64) even the embedded folks > > > should seriously consider using the UEFI bootflow. Linux now supports > > > physical address randomization when loaded via the UEFI stub, which is > > > something that can't really be implemented using the legacy boot path. > > > Note that you don't have to use a separate UEFI bootloader as U-Boot > > > can directly boot kernels with the UEFI stub. > >=20 > > 'legacy'? Isn't it just a case of relocating the kernel to a random > > address? I'm pretty sure U-Boot can do that :-) >=20 > The problem is that the legacy boot protocol for the Linux arm64 > kernel requires a 2MB aligned kernel base, which reduces the number of > randomized bits. That also means that virtual addresses are not fully > randomized as the kernel uses large mappings to map itself. My > understanding is that the UEFI stub can relocate the kernel to any 64K > aligned address. I suppose it is possible to add code to achieve the > same thing for the legacy boot path, but I don't think the arm64 > maintainers are really interested in doing that. >=20 > But yes, U-Boot should certainly try to load arm64 kernels at a random > address instead hardcoding the load address ;) Well, it sounds like "bootefi" should be used over "booti" directly, these days on aarch64 kernels. --=20 Tom --VxBmi9VgMIlnmxn8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmHq/mAACgkQFHw5/5Y0 tywaYgwAuWYVnbMzO/3tdQMogiZsQCN4RfTHqw0RHw5QNNL5CovfH1KrjLDmkosD wfxroSwrDJtZXO6MOVwCo8zFvqojXwUb3/SBLy+rSf5f6TKK47Q1BVTLq06dE+mt D7NWGI1a9DbI0L4GfhAJg+6ZP+OmsANY1DE9PYbSYgimYZ94YJF7eF+XV798gqTL ZQ/uwU4JSkMunqyHczhe1gb1bFUX4Oa0f43MbXWeNyFStVV8Yh6iQ/ChJapSR5GD 5sGSklgecNNiYR2WW9hb1L0oCS0I43HdHwz5WbTvK9koVCwhDM5On1+4pwl7AT2J WY65JMShlW+GOsArQTKnm5ipgMUkMVtB+j15sM3dvlcPknze3rMJgbYnZGMDPgNI ih2aDswRcpb47wOkXq2/nUU5XzK3yS0Rq/lfdIiG9pAd7LeoAfJeXUf9zxGKe8Zh TKmFGatF5dcw33BsX+e9Z86+hWli9iWIdYOKd9tD+iEo+DsdJXBds4Z05qA/Jh1Z zJhCpCez =vs2B -----END PGP SIGNATURE----- --VxBmi9VgMIlnmxn8--