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 96528C2B9F4 for ; Mon, 28 Jun 2021 13:37:23 +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 D98206145F for ; Mon, 28 Jun 2021 13:37:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D98206145F 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 C5CBE82DE2; Mon, 28 Jun 2021 15:37:20 +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="FBm+hghg"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0DCEE82DE2; Mon, 28 Jun 2021 15:37:19 +0200 (CEST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 CBC6B82DD6 for ; Mon, 28 Jun 2021 15:37:15 +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-x835.google.com with SMTP id g3so9262561qth.11 for ; Mon, 28 Jun 2021 06:37:15 -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=oo9U+WC9/WUNUJsC84Pndm8MaoVyEXmlFqv1EAm/ikY=; b=FBm+hghgFiUVrxFyIYzWKksFTl9/sfHUXG1WR4nUQzAXv2S4wlFTHIxOQdCgjd94Vb aRbeOIn/lovfDnc+6Np6TDFMY5+5DrNlK6wfdUhgrqKFnxwdj+MvKfbHo7HwTK4QQf0J BFOM2Nm86iumIrLNWOKYTiTk4drvcwlaxR+ok= 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=oo9U+WC9/WUNUJsC84Pndm8MaoVyEXmlFqv1EAm/ikY=; b=obQ8wk0hUplUe2lPrntlwiFlGn9ZrdW6waibNfwPsKvf3XAR8JwQdjizGkcBe6KNlC jXNPbKo6vbH1C7FcKFxQj+MqHkdGZnwSZ+dQ5R+VW9LsG+VccvxTVAit5KcE9HVjwXBE tQdDN93r0DmiDT58hxP0scXbCiBuPAzk9Zrv0yftyPgJKD9HEzWCN7pogIkKeqgacy6w 6cYcml7WEc+pOxBkFQFKU1Zh//vUeTVUDhf6D4+CCjPhovxmi9Yd9WSio2puYfalsTiZ 6ffcM1tdOvbK5JGokEt+0YAEtR/uh9bUMqp0FALlQesXukEUvP0YEvaFbUwEs5Je2EqJ QrPQ== X-Gm-Message-State: AOAM532veN2bWzqZ1ubw4as4IR1HT8BdryU2PTeU3U/zGnk6dDYLVJWF Q74/85O49hs55UgURf9Xtc54Sg== X-Google-Smtp-Source: ABdhPJwYqp87Ln9Lmywg+ztp0XmFn4IDJmHIejvCkBjbcLhLex5mdJvD2P12i3wud5KoDAJe0MxDgg== X-Received: by 2002:ac8:7d11:: with SMTP id g17mr22099594qtb.251.1624887434654; Mon, 28 Jun 2021 06:37:14 -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 k20sm10633452qko.113.2021.06.28.06.37.12 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 28 Jun 2021 06:37:13 -0700 (PDT) Date: Mon, 28 Jun 2021 09:37:11 -0400 From: Tom Rini To: Mark Kettenis Cc: Simon Glass , u-boot@lists.denx.de, pali@kernel.org, xypron.glpk@gmx.de, ilias.apalodimas@linaro.org, agraf@csgraf.de, yamada.masahiro@socionext.com Subject: Re: [PATCH 0/7] efi: Various tidy-ups and drop the default Message-ID: <20210628133711.GY9516@bill-the-cat> References: <20210628014841.501036-1-sjg@chromium.org> <5613706c36261e2a@bloch.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PJ3LlpcmNPuizT72" Content-Disposition: inline In-Reply-To: <5613706c36261e2a@bloch.sibelius.xs4all.nl> 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 --PJ3LlpcmNPuizT72 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 > >=20 > > 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. >=20 > 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 bootloader. >=20 > 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... >=20 > 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. >=20 > 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. --=20 Tom --PJ3LlpcmNPuizT72 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmDZ0IQACgkQFHw5/5Y0 tyx+aAv/WaQ/50jTfOLm7tynFZQRxv82QdR26HK3ckcUuZ+YVX+L5hruH/ghQzcg XHJECjAumbtF/vNDHGQJ21FR4dkw3wURSHi3XrpzjGvPJxmAPOgQkfTBpY4J4nEr QOG51Taf+Hd73O9mfQUk2b4JtcvtBa/imqxdoDRbxpNvOCo7xE8kZp76zuH95v2k CzmRuqq9WYDoJkC+silft1uCjOkNmQZ2ovYJs7s1/NIlbVFCBj8E0ghonq6Cfc2S eB3OJPRcQfJAZEczwL+wKY6tCwKhH0XFD4li77cTKl7lSXHpO99EDdxUw4UbpGT5 OqIx4ctpKCp1JkM+aIcJliFIRGx9WoaV5qKYarZhn3cUlVZvX1YlgbRf/diwFPOZ ZMpJbgAkdT5B4aKDcM5y4BDRjxjTKsFRp4wA3zRgvGjvieQVUJKATibzSKYWxQmy W0NG5R6GT5ZWfSeCB4wkr6VBhB/vTOsMAR4ZDfqNaB99S1rHiwZRMJY9k7pDqmdr RUpCb6Sf =oz7D -----END PGP SIGNATURE----- --PJ3LlpcmNPuizT72--