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 C0E64C433F5 for ; Fri, 21 Jan 2022 21:47:04 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id B27E482135; Fri, 21 Jan 2022 22:47:01 +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="IYUSYc5y"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8900F83041; Fri, 21 Jan 2022 22:46:59 +0100 (CET) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 B055980378 for ; Fri, 21 Jan 2022 22:46:55 +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-x72b.google.com with SMTP id d24so11493052qkk.5 for ; Fri, 21 Jan 2022 13:46:55 -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=t0t2wnnyczRWhMtJfOJgitVkV7g9OwZlbw5qkRM3PxA=; b=IYUSYc5yZucU+11DSJ/BMpOxu0TOWSvlDfbjqXMNemzh0OJfuJ8y5j57T7mAKW88+c zhfRuypPUQB1ma2zjX5hRSZAyk02GtVvuGI+dthz5+ASF/24QGYKM8jrExO5pA+tFF9z 5ZrX2EXiqFls6xSODH1RBFQtm8pZTPy8lhH6c= 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=t0t2wnnyczRWhMtJfOJgitVkV7g9OwZlbw5qkRM3PxA=; b=c2dVyRP6U5EQWZ+HdjUwHUxkZx7KHP8v+i8uGasN+s7mO1S/CFCa6nVlM/IqYMoWFZ LjTBxnuY/CJ8ztuwKtIQDXXMWUHs6J9ewBxTRVbQ7Wz1kDEh7kIqfKQueUDOBwnoxEWA 15q3HK2zPFTK+4LHMwXdn/Lw+V/x/pHwz+daE6oanun655MCEgGUK0o0NzVO5ZE8B5s3 OWiRFCgsgmqL2miZlWk3aXv0lB8esN7J8FmbOkOyklw/W4o6MDqk0K8YL1fNmPc/Tvf8 fcB9Dp3a2IgPdttdewp3wzw1novlM79Jjhx9sGyS8RtiZ5Ju5kGzVn95nwv3VBwUw+dC a9BQ== X-Gm-Message-State: AOAM532BizP0qT9RhaeAyygHOT625ezwE9A3E1zHR1m2o2UTh6+drrLE FoasoUjCh1qua0SvJ3QlPrENmg== X-Google-Smtp-Source: ABdhPJwND0z+dREl/OzO5ikjc1slyy18UbmbVF7ui7rYEv8IEzE9m9WFKbrTkUJ1g7JLgcTLjM/mmA== X-Received: by 2002:a05:620a:2481:: with SMTP id i1mr4413407qkn.436.1642801614444; Fri, 21 Jan 2022 13:46:54 -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 bm23sm3814962qkb.25.2022.01.21.13.46.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jan 2022 13:46:53 -0800 (PST) Date: Fri, 21 Jan 2022 16:46:51 -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: <20220121214651.GN7004@bill-the-cat> References: <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> <20220121192338.GM7004@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FDHWeTQvEq+9/CPf" 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 --FDHWeTQvEq+9/CPf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 21, 2022 at 02:15:24PM -0700, Simon Glass wrote: > Hi Tom, >=20 > On Fri, 21 Jan 2022 at 12:23, Tom Rini wrote: > > > > On Fri, Jan 21, 2022 at 12:14:22PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > 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 w= rote: > > > > > > > > > > > > > > > > On Wed, Jan 19, 2022 at 12:39:03PM +0100, Heinrich Schuchar= dt wrote: > > > > > > > > > On 1/19/22 02:43, Simon Glass wrote: > > > > > > [snip] > > > > > > > > > > +Introduction > > > > > > > > > > +------------ > > > > > > > > > > + > > > > > > > > > > +Standard boot provides a built-in way for U-Boot to au= tomatically boot > > > > > > > > > > +an Operating System without custom scripting and other= customisation. It > > > > > > > > > > +introduces the following concepts: > > > > > > > > > > + > > > > > > > > > > + - bootdev - a device which can hold or access a di= stro (e.g. MMC, Ethernet) > > > > > > > > > > + - bootmeth - a method to scan a bootdev to find boo= tflows (e.g. distro boot) > > > > > > > > > > + - bootflow - a description of how to boot (provided= by the distro) > > > > > > > > > > + > > > > > > > > > > +For Linux, the distro (Linux distribution, e.g. Debian= , Fedora) is responsible > > > > > > > > > > +for creating a bootflow for each kernel combination th= at it 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 = booting out of the > > > > > > > > > box. > > > > > > > > > > > > > > > > I want to jump up and down and emphasize this part as well.= While I > > > > > > > > believe our UEFI bootmgr is still missing the normal scan c= ode, that's > > > > > > > > something that has been promised to be implemented. And th= at turns 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 su= pport the > > > > > > > others, then U-Boot is not U-Boot anymore, it is just EFI Boo= t. > > > > > > > > > > > > No one is talking about removing anything else. But a major pa= rt of > > > > > > your motivation here seems to be "discovering what to boot wher= e is a > > > > > > pain" and that's solved (or at least defined, I'm poking Ilias = about 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 su= re 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 w= here > > > > "use EFI boot manager" isn't the reasonable answer. > > > > > > 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. > > > > > > 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. > > > > > > > > > > > > > > If we get EFI bootmgr going, then are you saying you want to = disable > > > > > > > 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?= Even the > > > > > > > distro stuff supports other options. > > > > > > > > > > > > I don't know about buildroot off-hand, but I've had OpenEmbedde= d spit > > > > > > out UEFI-compatible aarch64 images no problem. If you're talki= ng about > > > > > > embedded Debian/Ubuntu/Fedora, that goes back up to "wants UEFI= boot > > > > > > flow". Armbian is the biggest distro I know of off-hand that d= oesn't > > > > > > do UEFI boot for U-Boot targets and I would love to talk with s= omeone > > > > > > there and find out why (but I guess it's all the 32bit platform= s). > > > > > > > > > > > > But I'd also say the vast majority of embedded devices don't ne= ed the > > > > > > complexity you're adding here, but DO need the ability to imple= ment A/B > > > > > > things as easily in U-Boot as they can in grub. And that in tu= rn 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, w= hich > > > > > 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 befor= e and > > > > has been a great help. > > > > > > > > > I can't really say that this series is more complex than EFI boot= mgr, > > > > > 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 t= he > > > > complexity there being the discover where to boot from side of thin= gs. > > > > > > 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. >=20 > Well luckily, someone has gone to all the trouble of providing an > alternative that we can try :-) >=20 > > > > > > > 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. > > > > > > That sounds like an interesting project. For mendor I found this: > > > > > > https://github.com/mendersoftware/meta-mender/blob/master/meta-mender= -core/recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch > > > > > > 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. >=20 > The obvious answer would be to create a boot method for Mender. In > that you can do anything, including using the standard bootmethods to > obtain things to boot, etc. Also perhaps a 'recovery' bootdev which is > invoked last, when other things have failed, or first if recovery mode > is selected. Both could be done without any scripting, so could be > enabled on any board with just enabling CONFIG_MENDER, I suspect. OK. So please show that this will improve things for this case, rather than speculate. > > > > > Anyway if we can agree that we are not going to disable the non-E= FI > > > > > flows, then how about we focus on replacing the distro boot scrip= ts, > > > > > 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 .." becau= se > > > > the distro is already creating what's needed. > > > > > > 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. >=20 > Maybe. My confusion is that EFI seems to be blocking progress in the > general booting domain. When innovation is suggested, the answer is > 'well EFI does this so why bother'. When the boot scripts are > mentioned, we can apparently limp along with them and iterate there, > since EFI is the only thing that matters anyway. >=20 > Perhaps the real difference here is that I am not focused on EFI as > the solution to all things. I know that is where many distros are and > I believe you feel I am wasting my time. But that is where I am. From > my vantage point I see a lot of improvements we can make with booting, > independent of EFI. My high level concern is that yes, I don't see this as improving anything yet. This isn't an improvement over what EFI has for booting generic distributions. And this one of the areas where the boot scripts complex, but can be simplified. Another area where they could be simplified is for any of the existing A/B style update mechanisms. That's an interesting case that could show value here. > > > 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 > Previously you were worried about the size growth. I am pretty > confident this will make a lot of boot-related things more structured > and easier over the medium term. But we do need something to build on. > I believe the concepts are sound, and applicable to various boot > scenarios. In fact I think the lack of a 'bootdev' is something we > should have thought to create a while back. >=20 > I certainly think it is better than building more and more on the boot sc= ripts. Alright, so rpi_3_32b grew as: arm: (for 1/1 boards) all +6908.0 data +920.0 rodata -2664.0 text +8= 652.0 rpi_3_32b : all +6908 data +920 rodata -2664 text +8652 u-boot: add: 101/0, grow: 3/-2 bytes: 8662/-160 (8502) with this series, and I corrected the minor problems due to '@return' becoming "Return:". That's a problem. Environment space is cheap (it's a file, or it needs to have some pretty big these days alignment requirements to have physical redundancy, if you need that). The biggest problem I see with boot scripts is that defining them in a header file where we have to deal with escaping stuff in a header, and you resolved that with the environment cleanup series you did before. The series (that I keep failing to find the time to reply to, but was happy to see!) that updates hush to a modern copy is another good step in the right direction. Being able to write the script but more as plain text rather than escaped strings in C is I suspect why Armbian does what it does. --=20 Tom --FDHWeTQvEq+9/CPf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmHrKcUACgkQFHw5/5Y0 tywCRAv/fDGYTvjj8QKGyVBAa1H5DYQWvOe97Zf0ZqekUIWfUZZnsgvREM+FLdBp u5FSySLZZlF/nRh1hFfBpP6vmhTlDNglXmugR0IS5xK9mFLMCzvT7QrJOB2UvWaZ ZPsf4xvrVf7QzuBxebzl38hOyYnWoIdsjGz73VHg5Bpx8ur0AIdnQY/yu+VzVQxL 78UU6dM+a7LzisLVRk/MdKfA5Vq4W03OAJl3XhtrovMZkoW4i+3AMkiM9i9o6AXO fJR+bf+PrS/82PmVTDYN1EZ2Jdfkvbn9Ayhj7C8iUBHloSUISbmmG0GBdnpl87Gh lrRbZjVzllXBqMEcmH42MkZKSM5isCTCMQC5BKHM+D7qARUes4mW3ppLBnikxEjm YuTeRDwqJKtEA0NJGG3G/I/nll7KpmFrVYY9N5EYuE+HpRxvWc5UohiRakrh5ZxO juUlS0TS89yNvGqspzqKL8LcCBCdLqeLgiA94OT5+djeisvaeMTKHY0S+v6d2g0B bOl9bCVQ =pN4v -----END PGP SIGNATURE----- --FDHWeTQvEq+9/CPf--