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 48B3EC433EF for ; Fri, 21 Jan 2022 19:23:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 79B6A8302D; Fri, 21 Jan 2022 20:23: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="EasY1iHd"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E73A3830B9; Fri, 21 Jan 2022 20:23:45 +0100 (CET) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 652AB80FA4 for ; Fri, 21 Jan 2022 20:23:42 +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-x731.google.com with SMTP id o135so11053519qke.8 for ; Fri, 21 Jan 2022 11:23:42 -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=UG42m6jbd3xQfwJI4gtw1PwNWw53aQ7X1qsHDKmHIzA=; b=EasY1iHd07tA09m2qFbbZhKMAuy2KtbOppFwOECZtC8WTcE+xB2MaE2IqiteX0DdXv GnjJiwgzQmYnq9L4MNq7eCK+5JkNT6T5d4efW2wCsvpaqj6GX9tNtFvQfMg9Dhcc6F4M qR6hJaOKQc63OVj8LG1ASvCWOm9LylbeJhD4c= 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=UG42m6jbd3xQfwJI4gtw1PwNWw53aQ7X1qsHDKmHIzA=; b=0I4OdBvek0xRGelfAIZ35hmd3YOkTEHhZ0Wiz0vAbCy7/0v3KEHVEfp5KnIsl0dQ5S LK2/tkTFxW5od8dpUM7PZpvMKAV/SuZT4zZ+LBClP1X6dpTT3b0VdAIqgTJaykQTcN2A vVLlfQ+sB+FjEbdjgJkEdIo+Be5ocO4Exjcma9YelB8/y70xkXT66YxXyGNjUn36r9Kx a4kieXj92C8Q2hdrHE0uuxk8QWiTRWTmUKDDLUJSCAWOxw9xehxV6UnlU8K0OCsNZ2cm RVBT0vOrosFtOqQMad3F+w5n786Xr7GvPkhnDk7Lp/xhEwL4VM2yiYM8eT/Faelingkp 0mIQ== X-Gm-Message-State: AOAM530kA5i+WxvVMCwzeG7N4Bcv6Ni/4cqL+sICjTzrtgy5IRik/DYS vwC3tnO1yMjOwOIkl56bCJUNcg== X-Google-Smtp-Source: ABdhPJxMZ9Tin5SK+u1fpFvZ97Y0Va77zJxciTcMW6uoJHyD88HolMzI2u32kG+R89WOucMP1oLa9g== X-Received: by 2002:a05:620a:15d6:: with SMTP id o22mr3779669qkm.393.1642793021199; Fri, 21 Jan 2022 11:23:41 -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 h17sm3510182qtk.19.2022.01.21.11.23.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jan 2022 11:23:40 -0800 (PST) Date: Fri, 21 Jan 2022 14:23:38 -0500 From: Tom Rini To: Simon Glass Cc: Heinrich Schuchardt , Ilias Apalodimas , Daniel Schwierzeck , Dennis Gilmore , Steffen Jaeckel , Lukas Auer , Michal Simek , U-Boot Mailing List Subject: Re: [PATCH v3 30/31] bootstd: doc: Add documentation Message-ID: <20220121192338.GM7004@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> <20220121153126.GW7004@bill-the-cat> <20220121180949.GY7004@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Vwmj/TXzE7NEH899" 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 --Vwmj/TXzE7NEH899 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 21, 2022 at 12:14:22PM -0700, Simon Glass wrote: > Hi Tom, >=20 > On Fri, 21 Jan 2022 at 11:09, Tom Rini wrote: > > > > On Fri, Jan 21, 2022 at 09:02:13AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 21 Jan 2022 at 08:31, Tom Rini wrote: > > > > > > > > On Fri, Jan 21, 2022 at 08:20:17AM -0700, Simon Glass wrote: > > > > > Hi, > > > > > > > > > > On Fri, 21 Jan 2022 at 08:08, Tom Rini wrote: > > > > > > > > > > > > On Wed, Jan 19, 2022 at 12:39:03PM +0100, Heinrich Schuchardt w= rote: > > > > > > > On 1/19/22 02:43, Simon Glass wrote: > > > > [snip] > > > > > > > > +Introduction > > > > > > > > +------------ > > > > > > > > + > > > > > > > > +Standard boot provides a built-in way for U-Boot to automa= tically boot > > > > > > > > +an Operating System without custom scripting and other cus= tomisation. 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 bootflo= ws (e.g. distro boot) > > > > > > > > + - bootflow - a description of how to boot (provided by = the distro) > > > > > > > > + > > > > > > > > +For Linux, the distro (Linux distribution, e.g. Debian, Fe= dora) is responsible > > > > > > > > +for creating a bootflow for each kernel combination that i= t wants to offer. > > > > > > > > > > > > > > This gets it completely wrong. There is one standardized boot= flow: UEFI. > > > > > > > All major distros support this. U-Boot has to offer UEFI boot= ing out of the > > > > > > > box. > > > > > > > > > > > > I want to jump up and down and emphasize this part as well. Wh= ile I > > > > > > believe our UEFI bootmgr is still missing the normal scan code,= that's > > > > > > something that has been promised to be implemented. And that t= urns the > > > > > > bootcmd for platforms that just want to support modern off the = shelf > > > > > > distros in to something fairly small. > > > > > > > > > > Sigh... > > > > > > > > > > UEFI is a bootflow in this model, one of many. If we don't suppor= t the > > > > > others, then U-Boot is not U-Boot anymore, it is just EFI Boot. > > > > > > > > No one is talking about removing anything else. But a major part of > > > > your motivation here seems to be "discovering what to boot where is= a > > > > pain" and that's solved (or at least defined, I'm poking Ilias abou= t the > > > > status of that off-list). And I want to emphasize discover. > > > > > > But only if you use EFI boot manager, right? Even then I'm not sure we > > > have a deterministic way of listing the available bootdevs, which is > > > something that this series provides. > > > > I'll let someone else that knows the EFI boot manager code / design > > speak to this. But yes, for the discoverable case I'm not seeing where > > "use EFI boot manager" isn't the reasonable answer. >=20 > With bootdev you have a proper driver and device tree node where > configuration can be provided. The default ordering for bootdevs can > be provided. We can deal with the quirks of particular subsystems, > like MMC. I think there will be other benefits apparent as this all > matures. >=20 > But let's see. Perhaps it doesn't really matter anyway, since it seems > that EFI boot manager is doing its own thing for now. >=20 > > > > > > > If we get EFI bootmgr going, then are you saying you want to disa= ble > > > > > everything else? > > > > > > > > Not at all. > > > > > > OK, good. > > > > > > > > > > > > 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= that > > > > > the vast majority of embedded devices in the world don't use it. = Are > > > > > you really saying we should drop support for everything else? Eve= n the > > > > > distro stuff supports other options. > > > > > > > > I don't know about buildroot off-hand, but I've had OpenEmbedded sp= it > > > > out UEFI-compatible aarch64 images no problem. If you're talking a= bout > > > > embedded Debian/Ubuntu/Fedora, that goes back up to "wants UEFI boot > > > > flow". Armbian is the biggest distro I know of off-hand that doesn= 't > > > > do UEFI boot for U-Boot targets and I would love to talk with someo= ne > > > > there and find out why (but I guess it's all the 32bit platforms). > > > > > > > > But I'd also say the vast majority of embedded devices don't need t= he > > > > complexity you're adding here, but DO need the ability to implement= A/B > > > > things as easily in U-Boot as they can in grub. And that in turn is > > > > because it's a pain to modify the default environment in U-Boot and= easy > > > > to drop in another script for grub. > > > > > > My feeling is the complexity is already there, just in scripts, which > > > are harder to understand (from personal experience trying to > > > understand what they do) and don't have tests. They are also very hard > > > to build on top of (e.g. verified boot). > > > > Yes, the scripts that live in the environment based boot flow is > > complex. It's also been a huge step forward from what we had before and > > has been a great help. > > > > > I can't really say that this series is more complex than EFI bootmgr, > > > if that is what you are suggesting. I think the bootdev uclass is > > > well-motivated and will prove useful even for EFI. > > > > No, what I'm suggesting is that I see this as "current boot script stuff > > is too complex, lets replace it". And I also see the big part of the > > complexity there being the discover where to boot from side of things. >=20 > OK, so shall we replace the scripts, or not? I'm still looking to be convinced that something is better than the scripts, or that the problem is the scripts and not the pain involved with modifying the U-Boot environment. > > > Also A/B/recovery is a lot easier to implement in code than in > > > scripts. I have linked to the proposed design there. > > > > Show me what implementing Mender or RAUC or swupdate looks like with > > your proposal. Those are some of the real A/B use cases today and have > > had to take various approaches to dealing with our environment, and also > > supporting x86 and so started dealing with grub. >=20 > That sounds like an interesting project. For mendor I found this: >=20 > https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-cor= e/recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch >=20 > More scripts... Yes. Mender, RAUC and swupdate (iirc) all have some form of environment based bootcmd to Do The Right Thing and boot A or B or detect failure and fall back. Show me how what you're doing improves integration for that case. That's a case that's not covered by "use UEFI boot manager" directly. I know for Mender a huge pain point for integration is "drop _this_ script in to the default environment". RAUC is similar. Show me something that makes that much easier to integrate, like it is with grub. > > > Anyway if we can agree that we are not going to disable the non-EFI > > > flows, then how about we focus on replacing the distro boot scripts, > > > dropping the config.h files, and leave EFI bootmgr out of this > > > discussion? > > > > The primary use case for the distro boot work is EFI boot, and the "make > > this logic clearer" solution is "use EFI bootmgr". That's where we get > > stuck in a loop here. There's no "the distro must create .." because > > the distro is already creating what's needed. >=20 > So let me ask again. Is EFI bootmgr the only thing U-Boot is going to > support? I thought you said no. Maybe we're talking at cross purposes. I'm not going to drop booti/bootm/bootz/bootelf. I'm not going to drop setting bootcmd to whatever the user / board developer knows is best for them. > Are you saying you want to keep the environment boot scripts, or not? As I said in the previous iteration on this series, I'm not convinced this is a win over other clean-ups that can be done with what we have today, or that it solves the problems that I often see popping up. --=20 Tom --Vwmj/TXzE7NEH899 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmHrCDMACgkQFHw5/5Y0 tywoLAwAr3jvk0Zcm+UxZNH8HnDrWq04f3TpbXvqqvE6GV4G/c0uZ2kAqyDu33fZ 01FJT0LTHEI+oywjfS/tCHJHChlWc1pPly/ouiBL9GGp9CRQR4wan307m+9hgMBU T/0HwvyEknjHuAX+2lOrj2/Znd1d2+VdIkz1UL0lxK7AsngZ7hLbEY0JfC6Mhz/+ v4zutaGy9eTT0vz+TcSPer7J5La1EURiRrvWoizymVU/H0MH10DHxhTG5mi/nrco 12zW3RNB1m+iZmaKOyl4SGj8AmCWcjl33D+hvD2r8HDQp6nipfZweHmk3y607PfJ SzAnHPrPwfd4dr50A8Vq0Ud+B1wfBQhPkvkunMsS6uoZQNIyKmUjfIZn3AMpQDrr YJSy2g16Y7ADtlcJAruw9xety/Hspjp1UNvPhK78MiMFojX/4DrOpZJL7aiNJTyy 2J4KDuzOCj+/wOmThNQKg0MhTEBO4xSkdnGUwzPp27q3zArbOLD3aQxkTtL+rhlT 4DFpQuvS =VSKx -----END PGP SIGNATURE----- --Vwmj/TXzE7NEH899--