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 AFD06C433EF for ; Thu, 28 Oct 2021 17:52:43 +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 BE8E7610EA for ; Thu, 28 Oct 2021 17:52:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BE8E7610EA 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 96DC0832C6; Thu, 28 Oct 2021 19:52:40 +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="TMlVu7nR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B298180185; Thu, 28 Oct 2021 19:52:38 +0200 (CEST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 36ADE83480 for ; Thu, 28 Oct 2021 19:52:34 +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-qk1-x72c.google.com with SMTP id bm16so6618967qkb.11 for ; Thu, 28 Oct 2021 10:52:34 -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=azxYM3f3foavRsdZxUmtWdwxO3CwBnoYFwtYitGOisE=; b=TMlVu7nRsf/Fj6zx8N6QEenkRVrchZcUf5lxG4Lt8h+bxCTbj1sKffUtLT9394IF8b Oxf24M8ezhrVyRRIv9a2gcMr37rsvBZIWfMy+MiYS3ATEfUEkFRv5sQatzQhVMjwIk7I Xk1bbfIvPptlXZKyr/qiCppIoGyYay39kfTeE= 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=azxYM3f3foavRsdZxUmtWdwxO3CwBnoYFwtYitGOisE=; b=Xp3A/vjIc72G1wSfkiANCXPDOC1Pz90vVnRhcPsJ1v5+5oyh1Xz6bXAzIT66bZazv+ H9LXNvSpujD6WiGKl8zftPfY1iPxbfJrsAJqEDybRWIeyt32Ldqt2SzQooEGUilAMr+G 34I45qYXXGLGVIXVjh2BoIit1oM4Sr9wGtd4TPu1pgqkKBbseTRF5jPYguCa6zeiwb0X ESeUfKtHWrWS0ayobE+5athBYA6jMiUKlA4TShc6TgQoKILJggSdMIQ7hOtEotvzoc+T 9N/3I7MHzXkyfXCRr3uA1MAsPWmOU+2XFm6Cs8upUXlpC1tIDXyRaz4lv9SkrKhorgww ciCg== X-Gm-Message-State: AOAM533utJMDDs+lM6+joBRxo1SHcurQ1KyWN49BGYDvDP4EYHhCB6qi glf2JkRSSdI31Shy7BrPC0KjOg== X-Google-Smtp-Source: ABdhPJwpoiPfe7A6J7Ba0NTLIA/DXs/tZgxSh+ngA6HETSK9MNvL4+orrzSqVSJ9IBy8zRx/payh/w== X-Received: by 2002:a05:620a:1313:: with SMTP id o19mr4907568qkj.8.1635443552919; Thu, 28 Oct 2021 10:52:32 -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 p187sm2351690qkd.101.2021.10.28.10.52.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Oct 2021 10:52:32 -0700 (PDT) Date: Thu, 28 Oct 2021 13:52:29 -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: <20211028175229.GF8284@bill-the-cat> References: <20211023232635.9195-1-sjg@chromium.org> <20211028162741.GA8284@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kqAFKZ++CrkAX0DV" 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 --kqAFKZ++CrkAX0DV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > Hi Tom, >=20 > 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 automatical= ly > > > boot an Operating System without custom scripting and other customisa= tion. > > > This is called 'standard boot' since it provides a standard way 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 distro) > > > > > > This series provides an implementation of these, enabled to scan for > > > bootflows from MMC, USB and Ethernet. It supports the existing distro > > > boot as well as the EFI loader flow (bootefi/bootmgr). It works > > > similiarly to the existing script-based approach, but is native to > > > U-Boot. > > > > I'm going to break my feedback down in to a few threads, to hopefully > > not confuse things too much. My first comment is that rpi_arm64 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 going to > > re-investigate on their own, it's really just this series, right 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 bootstd > > uclass and core implementation" and keeps going from there. >=20 > 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 'bootflow > 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. > It does save a small amount of data. E.g. rpi_3_32b environment goes > drops by 3.5KB. So we're replacing 3.5KB of scripts with 17KB of code. That is not a win. > We should compare this with the EFI support which is about 90KB, as I rec= all. 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-legacy uses, a big common use case is "Find the EFI app to run". > If we continue down the path of making this feature use U-Boot > functions directly, instead the command line, I suspect we can save > quite a bit more, since there is a lot of overhead with these > commands. At present it is impossible to boot without CONFIG_CMDLINE > enabled, for example. Yes, this should be using the API and not the command interface. > In any case, I think this feature is filling a gap in U-Boot since 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 what to further build on or perhaps make more readily simplified (for example, making it just be "scan around for EFI" or just be "scan around of extlinux.conf"). > Anyway, I can look at what the minimum size is with the above points > and send that info through. I looked at the PXE stuff, and I think the minimal growth there ends up being reasonable, fwiw. It comes down to adding sanity checks in places where the code wasn't always sanity checking, as you reduced duplication. --=20 Tom --kqAFKZ++CrkAX0DV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmF6410ACgkQFHw5/5Y0 tyygrQwAmhiq+gL7UOR3AVWK7iVxShYnDA8gKvzbIiio/hNqO6L5K9FhutS2bj9+ JYW3jptpxiszTr6uUFKpfqOLNHUeK+a2eDyUtmnxOS0gxw7Tm2zXArHNJI42CYH7 vIQdgnDYXzFmlcxzGUTWOC8j+3cgvM1fBp6YfGP4fuUjieUymYWTtZEaO++awUtv xkS/h1btHK9ziIAYGWDGb8uv1keZKfCva4AO065Q9fgDYcwp2gh1gY/Kc0mL/E/i Fm403a3QbXGFq1gM+Do1PTWdA4GsXIjoSn3Vy5kX96YiSMbg2cVGgQxamiNxDHRe wko/6b25WGZhpRLtGVfFGQMeneV8za7NSZgLEWqcPI5cz4vk+cN7VOEgqjJ6+m/F jMddPl/AzeJ8PkXPdquhLXjBDltMoNdFDr0C14F9T/y6dWDt5AmGnR86Ym0C19K9 IV7D3LX1yOHErGniWYhh+3rq0BJO+KzHajMLGbymeW5+2La7jlcXoWy7xYcHQV4f i6gVB/g7 =C+P2 -----END PGP SIGNATURE----- --kqAFKZ++CrkAX0DV--