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 D48E3C433EF for ; Fri, 21 Jan 2022 18:10:00 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4B6FD820F0; Fri, 21 Jan 2022 19:09:58 +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="osBuBfRB"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id CB64B820AC; Fri, 21 Jan 2022 19:09:56 +0100 (CET) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 DDDE0820AC for ; Fri, 21 Jan 2022 19:09:53 +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-x72a.google.com with SMTP id d11so10758627qkj.12 for ; Fri, 21 Jan 2022 10:09:53 -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=YU8xQ1PE5FHF/F7C+tadJtQLjjAyP0F68pXq8RdtwVk=; b=osBuBfRBCAqEbOKnng9R3aNwq054mWAgIyx7AS/9j+bDXN4Bu/lpAAeICcvtN/SMxu KcvH2BfmfFP7qsDX/DRrchBEC600UyRr4+PfAXb8LgWQTice/95+fTJ1IFPlkz1gQ83H U8IlSL7Bhtwgw1mvVVMGnJLk2MckOJ9Sjw6MQ= 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=YU8xQ1PE5FHF/F7C+tadJtQLjjAyP0F68pXq8RdtwVk=; b=DXEHJ/9ETmgrcA52dJY/3x83+kHjTWoqajMY1OiJHKiRl4a92hcbm5QVCThamPYSG6 0kNJ1sMHMYbaX3a41JejuJzmZxuV5UaD4DGG0BWKfJrkAh0cds5WJmGJ/tcGHvMdWEvG hnEl3mXbep6EKEloRIRaiP4MX/Zh3QKUQYbltYaCKXdSo++QTVL98cWWl1nNlXr7b1RQ cKDXekhfFozMTCtI+HKnwoxLa/NKS241jS1PUaZm7J2h+XYWEsScHU39qNSZfZUk/CFK bbWjPpZW4gvYPt+rlItTkm7aztd4uqgoSWP8JkJSzjS7OHgg609fnnjil2Kmxl2TU0H7 eQJw== X-Gm-Message-State: AOAM532WWMmL/wKPUgXDvJ7umPLciPw3umserVijal0ouiL0y1bWKsLD xsmD4k3YbU/MbdnxnAL2X8f4Ug== X-Google-Smtp-Source: ABdhPJxg3FWNdfn/0V5dPx7onl9ikCHHJyOXZ4qF3c13Oi1AxmBUuazr9ZrrvhzYB6SIRBns7NQp6Q== X-Received: by 2002:a05:620a:29d2:: with SMTP id s18mr3605219qkp.604.1642788592451; Fri, 21 Jan 2022 10:09:52 -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 u9sm3548617qko.110.2022.01.21.10.09.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jan 2022 10:09:51 -0800 (PST) Date: Fri, 21 Jan 2022 13:09:49 -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: <20220121180949.GY7004@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="K6Vt3zCKtaqyTnPU" 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 --K6Vt3zCKtaqyTnPU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 21, 2022 at 09:02:13AM -0700, Simon Glass wrote: > Hi Tom, >=20 > 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 wrote: > > > > > On 1/19/22 02:43, Simon Glass wrote: > > [snip] > > > > > > +Introduction > > > > > > +------------ > > > > > > + > > > > > > +Standard boot provides a built-in way for U-Boot to automatica= lly boot > > > > > > +an Operating System without custom scripting and other customi= sation. 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 the = distro) > > > > > > + > > > > > > +For Linux, the distro (Linux distribution, e.g. Debian, Fedora= ) is responsible > > > > > > +for creating a bootflow for each kernel combination that it wa= nts to offer. > > > > > > > > > > This gets it completely wrong. There is one standardized boot flo= w: 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 code, tha= t's > > > > something that has been promised to be implemented. And that 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 support 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 about the > > status of that off-list). And I want to emphasize discover. >=20 > 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. > > > If we get EFI bootmgr going, then are you saying you want to disable > > > everything else? > > > > Not at all. >=20 > OK, good. >=20 > > > > > 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 OpenEmbedded spit > > out UEFI-compatible aarch64 images no problem. If you're talking 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 doesn't > > do UEFI boot for U-Boot targets and I would love to talk with someone > > 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 the > > 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. >=20 > 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. > 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. > 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 Tom --K6Vt3zCKtaqyTnPU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmHq9uoACgkQFHw5/5Y0 tyzMTQv7Bkfr2cIxbBz8fL7EM/GkiF45SxfAYGj+fCuoKOJWhGV+Pkjy0z+v8naV edRZ3xjUqYfQXm1kbGCgDnM7BCUcGWaPSfyyAGJ70sZYY25j6t6J9aL1m9Mrw4qL XJkU7ZSvekDBPL+D7zJ6bucsLGFgg+T21KDRV3XZZsGW7j50da9x88Sn/gKMM9Q5 0LVW7Es/2PryaBPmNwAL/HWp+PPiUt8PemMiiH0merkGcLgwuu/4SRqj9G4p04Le beFZI17QIN3EwnrWhGxtjAOi0EMyKFvYAnB5jkB54EZJALdItf04PRy1/nzSogU7 eRboAttk0yuATEdZcdWcZYFeOQtRnJPALey6GlF7IY+nKvyMgWXOk34lOVieyldu Sn5k4b09f1WEGV/cdlCx9TpFZEL99Bm4A7pP1d+tW2QZOhPSPFhMMn6IatmWbf+/ Zt3dKCbRAh/wTgnrYf2DmZkPIGUMETioL6mryhuNS43XUHgA+AQLFmzjpC4y9IjU arTkHA1m =R3a9 -----END PGP SIGNATURE----- --K6Vt3zCKtaqyTnPU--