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 X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82C5BC49EAB for ; Mon, 28 Jun 2021 17:27:56 +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 D48EC61C76 for ; Mon, 28 Jun 2021 17:27:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D48EC61C76 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 41F0582DE4; Mon, 28 Jun 2021 19:27:53 +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="BC5u1NAg"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7A7EF829BA; Mon, 28 Jun 2021 19:27:51 +0200 (CEST) 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 13CFB829BA for ; Mon, 28 Jun 2021 19:27:48 +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-x72b.google.com with SMTP id j184so28252887qkd.6 for ; Mon, 28 Jun 2021 10:27:48 -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:user-agent; bh=hRGd4M7fnxcDTsroPm3F1plbUp3i1kx1z+WfGgqCtZU=; b=BC5u1NAgTWQFHExmmzGv8Q94nvpa9SijmEE0hYn4h7En1x4MZhcIM4mRh/uZAlT2fx 3Ovqt6uK+BndQ9ED5EK7YvKVh5XbgYccr2kSb3N9Ouu0VG53hgjvFe393YFPOkh+7KZY zpMxql8z4AIs5STw/Ep1CgLaadc37G9uQ64mw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hRGd4M7fnxcDTsroPm3F1plbUp3i1kx1z+WfGgqCtZU=; b=sl+SYeMBu91JS9k4Qwgg3xQqmAg1sshUZOzUsC9lKAgufzRZ0WeICoMnd1iqzHXcfd oTcIh6D4tL9wErbgHenoZ0Cd8ySkHJPm/xDimgrkkPFw99A7JC/E/JnWMHEjjpJ5O5l5 avaBeC/L1ExM0oIqM91UB10hc4ZlAH8QMRJG0iVGpdtxETy9zasGmvU96j4fICOu4IQU kW8JrVuNaPv9cdpPgdBuSVfY8fexEtdvgl08uuomHEhFxWUjsMsYwCQ6mvWV1eW+yAYA LxWCFMKl91ZKPbWSMGbOulq/8/JVs/5QM9uMWv/SNHQs6MiBMUFqJ+ZNyU2VgzoaFsE5 Y9TQ== X-Gm-Message-State: AOAM5321hfg6ggm5DqHRFW2Po3hqBZX3GZjHx8SiYfUmNB1L7Frw48Dh 4aMddvw0kaTiBZ80K1WKXTxx6Q== X-Google-Smtp-Source: ABdhPJyUi6ZjBS4wwSBC1klDJn5azBtBqeUHAgZkiA0Gc0r3nRWEsdgBQNyZGDUydUrrPnZ7mBdr0Q== X-Received: by 2002:a37:84c3:: with SMTP id g186mr25613704qkd.276.1624901266768; Mon, 28 Jun 2021 10:27:46 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-2808-537e-3f88-1d98.res6.spectrum.com. [2603:6081:7b01:cbda:2808:537e:3f88:1d98]) by smtp.gmail.com with ESMTPSA id i69sm10937330qke.47.2021.06.28.10.27.45 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 28 Jun 2021 10:27:45 -0700 (PDT) Date: Mon, 28 Jun 2021 13:27:44 -0400 From: Tom Rini To: Simon Glass Cc: Heinrich Schuchardt , Mark Kettenis , U-Boot Mailing List , Pali =?iso-8859-1?Q?Roh=E1r?= , Ilias Apalodimas , Alex Graf , Masahiro Yamada Subject: Re: [PATCH 0/7] efi: Various tidy-ups and drop the default Message-ID: <20210628172744.GQ9516@bill-the-cat> References: <20210628014841.501036-1-sjg@chromium.org> <5613706c36261e2a@bloch.sibelius.xs4all.nl> <20210628133711.GY9516@bill-the-cat> <5a197768-3d0a-3b3b-5897-ed28d4e0f566@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IihCYcYBKEGq/NBR" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) 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 --IihCYcYBKEGq/NBR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote: > Hi Heinrich, >=20 > On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt wr= ote: > > > > On 6/28/21 4:18 PM, Simon Glass wrote: > > > Hi Tom, Mark, > > > > > > On Mon, 28 Jun 2021 at 07:37, Tom Rini wrote: > > >> > > >> On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote: > > >>>> From: Simon Glass > > >>>> Date: Sun, 27 Jun 2021 19:48:34 -0600 > > >>>> > > >>>> It has come to light that EFI_LOADER adds an extraordinary amount = of > > >>>> code to U-Boot. For example, with nokia_rx51 the size delta is abo= ut > > >>>> 90KB. About 170 boards explicitly disable the option, but is is cl= ear > > >>>> that many more could, thus saving image size and boot time. > > >>> > > >>> EFI_LOADER used to be a lot smaller. It is great to see that over = the > > >>> years UEFI support has become more complete, but a lot of that new > > >>> code implements features that are not at all essential for just > > >>> booting an OS from storage. If that growth leads to the suggestion= to > > >>> disable EFI_LOADER completely by default, we're putting the cart > > >>> before the horse. > > >> > > >> Well, I see I forgot to prefix my patch with RFC, but I hadn't found > > >> EFI_LOADER being used in the wild on armv7, but wasn't sure about the > > >> BSD families. I did see that Debian doesn't use it, and that Armbian > > >> doesn't even use it on aarch64. > > >> > > >>>> The current situation is affecting U-Boot's image as a svelt bootl= oader. > > >>> > > >>> Really? I know UEFI has a bad reputation in the Open Source world, > > >>> and some of its Microsoft-isms are really annoying (yay UCS-2). But > > >>> it works, it provides a standardized approach across several platfo= rms > > >>> (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personal= ly > > >>> I'd wish the industry had standardized on Open Firmware instead, but > > >>> that ship sailed a long time ago... > > >>> > > >>> I find it hard to imagine that 90k is a serious amount of storage f= or > > >>> something that is going to include a multi-MB Linux kernel. This > > >>> isn't code that lives in SPL or TPL where severe size restrictions > > >>> apply. > > >> > > >> In one of those cases where I need to pop back in to the other (Nokia > > >> N900 specific) thread and see if the big size reduction really was j= ust > > >> disabling EFI_LOADER, it's perhaps just one of those "fun" things ab= out > > >> Kconfig and anything other than "make oldconfig" for spotting new co= nfig > > >> options that default to enabled. > > > > > > Yes it will be interesting to see what you find there. My results on > > > nokia_rx51 were something like this: > > > > > > default > > > arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 > > > rodata +10989.0 text +109846.0 > > > > > > without ebbr > > > arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 > > > rodata +5333.0 text +29712.0 > > > > > > with various other things: > > > CONFIG_OF_LIBFDT_ASSUME_MASK=3D7 > > > # CONFIG_OF_TRANSLATE is not set > > > # CONFIG_SIMPLE_BUS is not set > > > # CONFIG_TI_SYSC is not set > > > # CONFIG_CMD_FDT is not set > > > > > > arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata > > > +3274.0 text +15552.0 > > > > > > (Mark, in the same email:) > > >>> FIT simply isn't fit for purpose (pun intended). It only really wo= rks > > >>> for booting Linux, and forces people to combine u-boot, kernel, > > >>> initial ramdisk and other firmware components into a single image. > > >>> That is really undesirable as: > > >>> - This makes it sigificantly harder to update individual components= of > > >>> such an image. Making it hard to update a kernel is obviously a > > >>> serious security risk. > > >>> - This makes it impossible to build an OS install image that works = om > > >>> multiple boards/SoCs. > > > > > > > > > I would really like to understand this better. The whole thing is a > > > complete mystery to me. > > > > > > Firstly I have sometimes fiddled with booting other OSes using FIT. It > > > seemed OK. I can't see why it only works with Linux. > > > > > > Secondly, I don't expect that U-Boot itself would be in the FIT. > > > > > > Thirdly, do you really want the kernel and initrd to be separate? At > > > least in the systems I have used, they are built together, even having > > > the same name, e.g.: > > > > > > initrd.img-5.10.40-1rodete1-amd64 > > > System.map-5.10.40-1rodete1-amd64 > > > vmlinuz-5.10.28-1rodete2-amd64 > > > > I have not hit any distro that builds FIT images. All install vmlinux > > and initrd as separate files. > > > > Why would you want to change that? >=20 > Well there is no point in having two files if one will do. Also it > allows for a hash / signature check. The question of "how great would it be and how many problems would it have solved if FIT images had become popular" is one for another time. It will always have its use cases and users but never the broad adoption many of us felt it should have. Bringing it up in this context won't change that. I'm saying this because I think there are some important technical questions within U-Boot to resolve because the EFI loader part of U-Boot is critical to our long term future. And DM is an important part of our internal design and we're (probably later than I should have) pulling out the parts that haven't been updated so that we can deliver on some of the overall promise of DM better, too. --=20 Tom --IihCYcYBKEGq/NBR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmDaBowACgkQFHw5/5Y0 tyztJAv/RCwWnFJkTnU+TgHaR0TsxeLMXS/0Ek2CONDs8qQ/kw+llSU93xIkNjzr e3r89HAsEhoHx5UOZtGS7t1xLlSqjUUIXUElZoEEaGy5EqSxf3IKP9AvFHI/WEdp KXzvoz1UCcQ/VQB2SenTGeuGPIYel8Im5X0rFdG5Iz/HQ9bgQQuzf+bYWjzrrPAl WxKARGKX9M+TdsJMGcJj0+6DG5Xw0vlUMl7Acu+R4an4MixHel5f94TgV3yABDBG FzT9vc+0VLYaAAgn0uCS3eBBqGbszKGmN3dFUVgP3j0Ke/p+rYaQ95Vzqj3ATTEB ckZ0wup+oGO8bv6qJdAaZX2Gl+6J8gMzlweObSE/ALqfFyDOPltu0uGnwiAU6aAC iG7i1YxKwufaz3cBaxr28yRy2ZLKd3rYjGxrN/7pHFPOLv+TH+XQzw5dwvv6UNSW tcflFRkVGSRXggMNcyB3DtV1SEYGYMKi14L+0zlExovU46uTqurHinxqnU2yjJxf sGJ61xh3 =zYU4 -----END PGP SIGNATURE----- --IihCYcYBKEGq/NBR--