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=-2.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,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 62ED4C49361 for ; Mon, 28 Jun 2021 14:26:07 +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 E0F11613CB for ; Mon, 28 Jun 2021 14:26:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E0F11613CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de 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 793DB82DD2; Mon, 28 Jun 2021 16:26:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de 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; secure) header.d=gmx.net header.i=@gmx.net header.b="FH+YKbE2"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 65CF682DD7; Mon, 28 Jun 2021 16:26:02 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id D383E8048A for ; Mon, 28 Jun 2021 16:25:58 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1624890354; bh=dW11eWG0d38JMDGQD/fbWNxjcq6r3kosZX7guo04yiQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=FH+YKbE2foJ465VyALJ9jxvZZYzNOvh4aB3INspAFWBpCdzN2BTPuIbA5qPWC4+/p 7Q2D4MbJz+23zOH/DqpQAsUqjtN9yPByipNMQYDXHe4rw5pkh9K9nakim59ArmUvr2 0xiTJRN2pOfTX+nH9iF9LenYzRuAcJMRcH3tlsjA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.55] ([88.152.144.157]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MRmfo-1lnNWt3qB8-00TCZn; Mon, 28 Jun 2021 16:25:53 +0200 Subject: Re: [PATCH 0/7] efi: Various tidy-ups and drop the default To: Tom Rini Cc: Simon Glass , u-boot@lists.denx.de, pali@kernel.org, ilias.apalodimas@linaro.org, agraf@csgraf.de, yamada.masahiro@socionext.com, Mark Kettenis References: <20210628014841.501036-1-sjg@chromium.org> <5613706c36261e2a@bloch.sibelius.xs4all.nl> <20210628133711.GY9516@bill-the-cat> From: Heinrich Schuchardt Message-ID: <220d26ac-b5a9-1840-c42a-523efc4bad0d@gmx.de> Date: Mon, 28 Jun 2021 16:25:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210628133711.GY9516@bill-the-cat> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:6lTpxXRFlqEMTpodf/apNGNC/izPrUcj1yjbuzmJqeub5cTU957 hcR4xJOt1G1VnyXHhYmWwsr5AOtAma0W9VYMgej98XDY/RsI5tLMGscjSJykB/EhRs+MiI7 OAZFBIwWWGsUhXtUd4fqpKn8BtvlQidUXJLNteuQA9/tbpqppAo9KkNtjtylf4ObBK3mq6h U2llFEVCaPETSQWtq3Iug== X-UI-Out-Filterresults: notjunk:1;V03:K0:IS9oqQHg0Rk=:sksFYDcxtdtDJrD8Cje87s U+4Jzzq8/kntLA/smyvyXoBJKkQLkjDtHGG8feT8uBx65PFB3/sR1qmd0jC/Om4iVwPrsWRMn miyKsmLyAnkKkzfoHTL/7N2s9WY+3ij1vaKciJQl+vJ+E9+P0GZohgty07+FVvbhLqcmCbi4f m5ebkLU6rmU6FFMEEhfRKYF8cWPvJo2s2f53aO3FSw4ExOuAgv/N0G6UZir1JUEsDuQOfzUfx gVxLGEvNkMlV82PgO1NLsNwaTGOCAndvPyPdPpl9lFaviY+5GOfjwMa6UBwiK9uPdJ0VG9lfJ P13HrOBj2uuuWDH1C/iAxp2lr0JWfcz5QoANLNw/Ny5O80Iut/mFFy9sVgPVpNpz8s67eGPPX THP7nso0SIT5dp/LnkKumGn+Va468cy3bPyq15Rf3++GmRLJ+VZxi8WkslFNga3xH4jpzS7fr ZIela7QDgv1MouxaaBIroiKhUck3d3rSE4KQ175Z2anuAiVlUPU80WVsuKIayPeh5XjN/hIDc mJnb/MysKoHg/oDznNjT9dLut80yayj5BZGkpi/sM2qVR0vnpmxY3nRPYIeVpJaELFzwgYJsb w0kbRtVcKhLdj+ZcsoIh/92B5uzJRgu8fwVwEC1toqjOIoxVfuM64M7xzLQPPTzTGz5nPvm8x JZ5ZkP0XjTuO9nKMv17BnbkoBIboTGCLLr08WGusmJGPEUpZRtlIHkOZFBr3Ut6x1O7hr9wDM ROsXmAvOessITl1JlzRA+hCwBsbAIO7QUiWNR64XmNXQ7edEIq3vnuwoobFqegJxhLXTityxc pK++MzwxIZ3L/uTkceOg9V0kx1lVbvfaZTnvxhqo4+6A41ab17fbSy1iAfrFg40mKV6Q6jHPM Tp6ipFd8uGnbI1VjCCIMFbMflykP9W2oYARbIe+k6BL1t3dIxp06eMsX4mqTU514xKTv0/N5L r7XnLXEjBZ65jCxDcfDSTEQMRjwPvbyzIMpIu+usgNuuMxwjLob3uxgQMrNHWrJomEf4/atiW oPEYIpjHt1rUlAVDEYMrS04EO4kRMiJpMcYV8q3uczHS/HuH5cFGr1Nm9Qx+S1HSCWQor37rG lt9OvhOsDrP0DbkGxpFtG8lYyhi8IDDQbiA 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 On 6/28/21 3:37 PM, 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 about >>> 90KB. About 170 boards explicitly disable the option, but is is clear >>> 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. Debian and Ubuntu both offer booting via UEFI and GRUB on armv7 (see https://packages.ubuntu.com/hirsute/grub-efi-arm). You could use package flash-kernel instead if you wanted to avoid UEFI. It is just a question of how you decide to install your system. If you want the installer to automatically install GRUB, you must invoke it via UEFI. Armbian uses the Debian repos. That lets you boot Armbian using UEFI and GRUB if you want to. SUSE is another distro relying on UEFI and GRUB. > >>> The current situation is affecting U-Boot's image as a svelt bootloade= r. >> >> 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 platforms >> (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally >> 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 for >> 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 just > disabling EFI_LOADER, it's perhaps just one of those "fun" things about > Kconfig and anything other than "make oldconfig" for spotting new config > options that default to enabled. > >>> EFI_LOADER is required by EBBR, a new boot standard which aims to >>> bring in UEFI protocols to U-Boot. But EBRR is not required for >>> booting. U-Boot already provides support for FIT, the 'bootm' command >>> and a suitable hand-off to Linux. EBRR has made the decision to create >>> a parallel infrastructure, e.g. does not use FIT, nor U-Boot's signing >>> infrastructure. >> >> EFI_LOADER is required to boot FreeBSD and OpenBSD on several >> platforms as well as generic Linux distros. For example >> OpenBSD/armv7, OpenBSD/arm64 and OpenBSD/riscv64 all rely on >> EFI_LOADER to boot and have done so for the last 4 years. The fact >> that ARM has embraced UEFI as an embedded boot standard and branded it >> EBBR really isn't all that relevant. > > To be clear here, I like EFI_LOADER. I too do wish some other > technologies had become dominant for technical rather than inertia > reasons, but here we are. Having played around with it on aarch64, > there are some pretty nice comes-along-with parts to it. > > What I hadn't seen, and am only a little skeptical of still, is how far > backwards in generations it's going to be used on. The general wish is > that users nor off the shelf OS groups need to rebuild U-Boot for a > given board, and instead it just works. The number of new designs for > 32bit parts is no where near the number of new designs for 64bit parts. > So what we're seeing in U-Boot now is people updating support on their > older designs, and not necessarily caring about using EFI_LOADER. > The question is not how old your board is. My i.MX6 Wandboard (bought 2013) and my Allwinner A20 Banana Pi (bought 2014) both run fine with UEFI and GRUB on Debian. The major divide is between systems running a distribution and IoT devices where you build your image via Yocto, OpenWRT, or the like. Best regards Heinrich