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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36A37C433F5 for ; Thu, 28 Oct 2021 19:19:21 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 0E8C86108F for ; Thu, 28 Oct 2021 19:19:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0E8C86108F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8F1AE832AF; Thu, 28 Oct 2021 21:19:17 +0200 (CEST) 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="BH1Vk4MW"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 3D42282FE7; Thu, 28 Oct 2021 21:19:15 +0200 (CEST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 3E92E832AF for ; Thu, 28 Oct 2021 21:19:08 +0200 (CEST) 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-qt1-x834.google.com with SMTP id g17so6799652qtk.8 for ; Thu, 28 Oct 2021 12:19:08 -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=BK28GMzgbn9uGAo3++joJQsUFdtkR52iStwUsJg3nNU=; b=BH1Vk4MWKhrv/ZtV6Ew7aVlmj9RhFzgzNphZPirwb9eCPXlmCDSunzhTEVJJuQ1yxO aXLStphVTIDk4xfDVVdM21GfFgGKB85MGV4z3rlgJ9y3jvSjeuELyi6tekVoJop4GBTy +V5sclt9ey8hzMXrH1OF0d6IDuheK90jKawWs= 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=BK28GMzgbn9uGAo3++joJQsUFdtkR52iStwUsJg3nNU=; b=wwczn7uqFXUfhUjoaw3cvJ2k0F/iQThCy1gy+akmSYscUFq6PkdIOFbB4Dg7UI1N7y b7hNq0DxuAhEN8w/XPBnIeOJG1Z/X6/Bz+TGAo18IbnhyzyuX40yvoX0U35c5PlExhxZ FZT9Vi+1mqUZ+MVshlh3A1ZjU3kAWrf00IUg9tTC3jA1PA6EPD2GYgyzdWi+Bed97btM YKi7UJs0OqumdO6xBqX4vi18ng8mHZ1Wge1JmTIhnaxbp0XfLkB/aEkoYC+vNGJEGP2m er0GTs18BP0sjmSzF8x+mQr9zoDuwuuxbQN1uhwF7AGmvBEtJgO0JvVmeBZAqbAM+dB5 pakg== X-Gm-Message-State: AOAM5315Pt1cH5tNJ8hpDKz8kORXFBtYaYwac+wno3n/aGLYOTl2j3A+ 8nhegLvENzOP8mb8zx8uKOPGqg== X-Google-Smtp-Source: ABdhPJy21Y6crHSegGQkRWznkk3IP7PzI7ZoGsSkNYgpNsPRNNRmH6oTLFAa3sPyLMtVq2SuKal13w== X-Received: by 2002:ac8:7d13:: with SMTP id g19mr6980430qtb.178.1635448746580; Thu, 28 Oct 2021 12:19:06 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-015b-1704-43dd-8832.res6.spectrum.com. [2603:6081:7b01:cbda:15b:1704:43dd:8832]) by smtp.gmail.com with ESMTPSA id c8sm2735464qtb.29.2021.10.28.12.19.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Oct 2021 12:19:05 -0700 (PDT) Date: Thu, 28 Oct 2021 15:19:03 -0400 From: Tom Rini To: Simon Glass Cc: U-Boot Mailing List , Michal Simek , Heinrich Schuchardt , Ilias Apalodimas , Daniel Schwierzeck , Steffen Jaeckel , Marek =?iso-8859-1?Q?Beh=FAn?= , Lukas Auer , Dennis Gilmore , Jaehoon Chung , Marek Vasut , Masahiro Yamada , Pavel Herrmann , Peng Fan , Stephen Warren , Stephen Warren Subject: Re: [PATCH v2 00/41] Initial implementation of standard boot Message-ID: <20211028191903.GK8284@bill-the-cat> References: <20211023232635.9195-1-sjg@chromium.org> <20211028162741.GA8284@bill-the-cat> <20211028175229.GF8284@bill-the-cat> <20211028183652.GJ8284@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="yMeU8KwQKf0wI0P3" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.2 at phobos.denx.de X-Virus-Status: Clean --yMeU8KwQKf0wI0P3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 28, 2021 at 12:48:50PM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Thu, 28 Oct 2021 at 12:36, Tom Rini wrote: > > > > On Thu, Oct 28, 2021 at 12:13:56PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 28 Oct 2021 at 11:52, Tom Rini wrote: > > > > > > > > On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 28 Oct 2021 at 10:27, Tom Rini wrote: > > > > > > > > > > > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, Simon Glass wrote: > > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to aut= omatically > > > > > > > boot an Operating System without custom scripting and other c= ustomisation. > > > > > > > This is called 'standard boot' since it provides a standard w= ay for > > > > > > > U-Boot to boot a distro, without scripting. > > > > > > > > > > > > > > It introduces the following concepts: > > > > > > > > > > > > > > - 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 di= stro) > > > > > > > > > > > > > > This series provides an implementation of these, enabled to s= can for > > > > > > > bootflows from MMC, USB and Ethernet. It supports the existin= g distro > > > > > > > boot as well as the EFI loader flow (bootefi/bootmgr). It wor= ks > > > > > > > similiarly to the existing script-based approach, but is nati= ve to > > > > > > > U-Boot. > > > > > > > > > > > > I'm going to break my feedback down in to a few threads, to hop= efully > > > > > > not confuse things too much. My first comment is that rpi_arm6= 4 grows > > > > > > in size by 17 kilobytes, with the whole series (pxe, env, this)= applied. > > > > > > And while there's a few small changes in the pxe cleanup I'm go= ing to > > > > > > re-investigate on their own, it's really just this series, righ= t here, > > > > > > adding tons of code. To replace an admittedly complex bit of > > > > > > environment scripting, with C. It's not even the earlier parts= of the > > > > > > series to clean up / prepare, it starts at "bootstd: Add the bo= otstd > > > > > > uclass and core implementation" and keeps going from there. > > > > > > > > > > Yes it does add a lot of code, although it is a lot less if the > > > > > commands are disabled or simplified, e.g. to only support 'bootfl= ow > > > > > scan -b'. At the moment it enables all dev features. > > > > > > > > OK, for the next go-round yes, please show what a typical enablement > > > > would look like on Pi, for example. > > > > > > OK. Do understand that conceiving of this and implementing it is quite > > > a bit of effort. At some point I just send things out, to get feedback > > > and to think some more. Apart from anything else, there is a risk of > > > going into the weeds or never finishing it. > > > > > > > > > > > > It does save a small amount of data. E.g. rpi_3_32b environment g= oes > > > > > drops by 3.5KB. > > > > > > > > So we're replacing 3.5KB of scripts with 17KB of code. That is not= a > > > > win. > > > > > > Certainly not on size! On testing, debug, visibility and control of > > > the boot process, there are wins. > > > > I'm not sure if there's wins on those grounds either, and certainly not > > enough to justify what this adds. > > > > > > > We should compare this with the EFI support which is about 90KB, = as I recall. > > > > > > > > No, we shouldn't. This isn't about replacing EFI, this is about > > > > replacing the generic distro boot macros, so that's what the size > > > > comparison is to. At the end of the day, and looking towards non-l= egacy > > > > uses, a big common use case is "Find the EFI app to run". > > > > > > I just mean that EFI has been accepted as part of U-Boot and adds 90K= B. > > > > OK? I still don't see the relevance here. > > > > > > > If we continue down the path of making this feature use U-Boot > > > > > functions directly, instead the command line, I suspect we can sa= ve > > > > > quite a bit more, since there is a lot of overhead with these > > > > > commands. At present it is impossible to boot without CONFIG_CMDL= INE > > > > > enabled, for example. > > > > > > > > Yes, this should be using the API and not the command interface. > > > > > > Right, but that's not something I am taking on right now. The PXE > > > refactoring gives an idea of what is needed. I did that work mainly > > > because I don't like adding to code that desperately needs > > > refactoring. We need to do the same for dhcp, EFI and bootm/zboot, but > > > that might take a year. > > > > Well, maybe this particular part of things get set aside for now, and > > the generic distro boot framework just needs to be moved to the env > > update you did. > > > > > > > In any case, I think this feature is filling a gap in U-Boot sinc= e at > > > > > present everything about boot is ad-hoc. This gives us a base to = build > > > > > on. Nothing is for free. > > > > > > > > I disagree. At present, booting is either intentionally per-board,= or > > > > it's using the generic distro boot framework. That framework is wh= at to > > > > further build on or perhaps make more readily simplified (for examp= le, > > > > making it just be "scan around for EFI" or just be "scan around of > > > > extlinux.conf"). > > > > > > Well if the Universal Bootloader is only going to exist to boot EFI, > > > then we should rename it :-) > > > > > > I am not sure that anyone wants something intentionally per-board, > > > > There's some cases, yes, where the system is supposed to do X (or Y, or > > Z). Otherwise there's the generic framework. Or... > > > > > it's just that everything about the boot in U-Boot is really low-level > > > (bootm, fixed addresses, etc.) We need the layer on top that can deal > > > with these silly details. For example, yes there is a Chrome OS boot > > > script in chromebook_coral, but it is the same on all devices. I would > > > rather just enable that bootmethod so that if Chrome OS is present it > > > will boot. > > > > there's things like what Chrome OS wants. > > > > > Re the memory side, i don't like the vars that define the kernel > > > address, FDT address, etc. It seems to me that most/all are > > > unnecessary, if there is something able to deal with memory allocatoin > > > automatically. Perhaps we should use malloc() more, or use LMB more > > > proactively. > > > > Well, in that for Linux, arm64 the Image format has a header that lets > > us avoid a number of problems that weren't possible on arm32, there's a > > tiny bit more flexibility there. But it sounds like you're talking > > about "bootm_size" and "bootm_low" now. > > > > > Even for custom flows, creating a bootmethod will have advantages, I = think. > > > > > > The other thing is that this allows further innovation. For verified > > > boot, it makes it possible to sensibly deal with A/B;recovery, whereas > > > at present that is all just scripting, certainly not handled by distro > > > boot. > > > > No distros implement A/B updates directly. When implemented on top of > > them it's done via the environment, yes. I don't think adding Mender > > and RAUC and swupdate specific bootflow commands is a step in the right > > direction at all. > > > > > > > Anyway, I can look at what the minimum size is with the above poi= nts > > > > > and send that info through. > > > > > > > > I looked at the PXE stuff, and I think the minimal growth there end= s up > > > > being reasonable, fwiw. It comes down to adding sanity checks in p= laces > > > > where the code wasn't always sanity checking, as you reduced > > > > duplication. > > > > > > Yes and perhaps the growth can be reduced, too. > > > > It must be. You need to be a lot closer to parity with the existing > > generic boot mechanism and around that size. I am not liking what I'm > > seeing here so far. >=20 > Just on this point, I'm pretty sure this will kill it. We cannot add > code without increasing the size! It sounds like 17KB on ARM64 is too > much (perhaps 13.5KB including env reduction). Firstly, why, and > secondly, how much is acceptable? If the answer is zero, we are not > going to go anywhere with this, at least without a huge amount of > future refactoring, which is not going to happen since we cannot land > 100s of patches all at once. >=20 > The big prize would be to be able to disable CONFIG_CMDLINE and still > boot. That saves 200KB or more. I think the problem is this just needs to get put on hold for a while. I am not convinced this is moving things in the right direction. Conceptually, it's duplicating a lot of the efi bootmgr functionality, but also adding in non-block devices. And I am not liking configuring this via device tree, rather than environment. Lets move the generic distro framework to the new env framework and continue finishing off other technical debts that we have, before we re-visit a brand new way of handling booting. --=20 Tom --yMeU8KwQKf0wI0P3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmF696MACgkQFHw5/5Y0 tywquwv/fp7RPOyL/m35IkFlK5aR62GO7ibVfXL/3ImngDeezv/+RGYku7IaQW9q IUHe/9imBVy8+7KkGrmYG3o1dw1vxWeEN5lumLLKRzV9RyxJu38wZefG+5vFrPIN xxk/5hjQ9H8GzpinvSSNz6KgpUBh1XN78IzfQPuTXhZ/v5xbp1r3AZfoGn3zp83O q+b1Ayl2VLGNCObd9ffBCDUULL+t+XPi6nuC84YOOb69rJytnPSoP703LPvwav3w gNgsAwAvIb+x96mFFm4MJww6qxcTezOJjqFNOh6f5vyDJDg4L7hTc9EeTADT4iRT 11hvyQjFsglFMNHKhnUpocBKyxd4b6Ns51Wen9weT6YbHbS1R1pZYMMCGeFV3gqs pLm58xmflO66I0cHNKodILOjSFf1PNQ/X+mXMa6rw3Q2oKn4LgpXbKsr5zowiPEN QM2jrYA1OrNOm51/fEH18JnWf8PQiWdTa8rKg2BUFPIxCcLcnAW9UMaIcdIxZIu8 z4t/0td0 =9wRS -----END PGP SIGNATURE----- --yMeU8KwQKf0wI0P3--