From: Tom Rini <trini@konsulko.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: Simon Glass <sjg@chromium.org>,
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
Date: Mon, 28 Jun 2021 09:37:11 -0400 [thread overview]
Message-ID: <20210628133711.GY9516@bill-the-cat> (raw)
In-Reply-To: <5613706c36261e2a@bloch.sibelius.xs4all.nl>
[-- Attachment #1: Type: text/plain, Size: 3648 bytes --]
On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote:
> > From: Simon Glass <sjg@chromium.org>
> > 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.
> > The current situation is affecting U-Boot's image as a svelt bootloader.
>
> 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.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2021-06-28 13:37 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
2021-06-28 1:48 ` [PATCH 1/7] configs: Resync with savedefconfig Simon Glass
2021-06-28 1:48 ` [PATCH 2/7] Makefile: Drop include/asm directory as well as symlink Simon Glass
2021-06-28 1:48 ` [PATCH 3/7] disk: Tidy up #ifdefs in part_efi Simon Glass
2021-06-28 11:20 ` Heinrich Schuchardt
2021-06-28 13:50 ` Tom Rini
2021-06-28 16:18 ` Heinrich Schuchardt
2021-06-28 1:48 ` [PATCH 4/7] Use LIB_UUID with ACPIGEN and FS_BTRFS Simon Glass
2021-06-28 1:48 ` [PATCH 5/7] Allow efi_loader header to be included always Simon Glass
2021-06-28 11:02 ` Heinrich Schuchardt
2021-06-28 1:48 ` [PATCH 6/7] lib: Create a new Kconfig option for charset conversion Simon Glass
2021-06-28 10:37 ` Heinrich Schuchardt
2021-06-28 1:48 ` [PATCH 7/7] efi: Make EBBR optional Simon Glass
2021-06-28 9:48 ` Heinrich Schuchardt
2021-06-28 13:48 ` Tom Rini
2021-06-28 8:38 ` [PATCH 0/7] efi: Various tidy-ups and drop the default Mark Kettenis
2021-06-28 8:59 ` Ilias Apalodimas
2021-06-28 13:37 ` Tom Rini [this message]
2021-06-28 14:18 ` Simon Glass
2021-06-28 15:20 ` Heinrich Schuchardt
2021-06-28 16:26 ` Simon Glass
2021-06-28 17:09 ` Heinrich Schuchardt
2021-06-28 18:02 ` Simon Glass
2021-06-28 17:27 ` Tom Rini
2021-06-28 18:08 ` Simon Glass
2021-06-29 12:56 ` AKASHI Takahiro
2021-06-29 14:01 ` Heinrich Schuchardt
2021-06-29 14:14 ` AKASHI Takahiro
2021-06-28 17:49 ` Mark Kettenis
2021-07-02 19:05 ` Simon Glass
2021-07-02 19:48 ` Mark Kettenis
2021-07-02 20:09 ` Tom Rini
2021-07-02 20:47 ` Simon Glass
2021-06-28 14:25 ` Heinrich Schuchardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210628133711.GY9516@bill-the-cat \
--to=trini@konsulko.com \
--cc=agraf@csgraf.de \
--cc=ilias.apalodimas@linaro.org \
--cc=mark.kettenis@xs4all.nl \
--cc=pali@kernel.org \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.