I generally agree with Mark here.
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.
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 think the basics of EFI (mostly those that EBBR requires) are sane and nice to boot multiple architectures as well.
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.
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.
FIT simply isn't fit for purpose (pun intended). It only really works 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.
EBBR should be truly optional, enabled only by boards that use it. Most don't use it but it is enabled anyway. The default boot path should be one that makes use of the existing U-Boot support.
I don't particularly care about EBBR myself, but EFI_LOADER should be the default for as many armv7/arm64/riscv U-Boot targets as possible to give users an easy way to choose the OS they want to run on their machines. That is the best way to guarantee that vendors ship their firmware with it enabled.
To try to retify this situation, this series adds a new Kconfig option for EBBR so that the naming is more explicit. Then EFI_LOADER is updated to depend on it.
Isn't using the the term EBBR for non-ARM platforms misleading?
Not really, we are discussing with RISC-V atm and having platfomrs being EBBR compliant. In essence we don't desire EBBR to be an Arm only thing.
EFI_LOADER is used much more widely. Anyway, I disagree with this direction.
Same here
If size really matters here, we should look at reducing the EFI_LOADER feature set to reduce the amount of code i adds, and maybe introduce an EBBR option that can be enabled by those boards that desire full EBBR compliance?
+1
[...]