Hi Tom,
On Fri, 2 Jul 2021 at 14:19, Tom Rini trini@konsulko.com wrote:
On Fri, Jul 02, 2021 at 02:04:40PM -0600, Simon Glass wrote:
Hi Mark,
On Fri, 2 Jul 2021 at 13:50, Mark Kettenis mark.kettenis@xs4all.nl wrote:
From: Simon Glass sjg@chromium.org Date: Fri, 2 Jul 2021 12:36:11 -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.
The current situation is affecting U-Boot's image as a svelt bootloader.
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.
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.
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.
The final patch makes EBBR optional. For now, only sandbox enables EBBR. Other boards can be added as needed, presumably by distributions that require it. Another approach would be to add 'CONFIG_EBBR=y' to the .config before building, in the build system. That might be more friendly to U-Boot users.
This series also fixes a minor issue noticed during testing.
I don't understand why you're pushing this series in a form that still disables EFI_LOADER by default after last weeks discussions.
I moved the change to non-default to the last patch. Even if that is not a good idea, the rest of the series stands.
But more specifically to your question, I have not seen any discussion about the size issues identified. Nor has there been any comment on my suggestion in the cover letter for distros to define CONFIG_EBBR themselves when building U-Boot. I still think turning it off by default makes sense given the current situation.
It's not "distros", it's board vendors. And then SoM vendors. And their customers. Based on what I see, the default values get re-used 95% of the time, or more. The things we want to Just Work need to be enabled by default. What distros want is for vendors to include firmware in non-volatile storage, not to rebuild every board firmware and have to ship that, and even less to have to tell users to reconfigure things and then build.
It's also at this point counter-productive. If you want to run an off the shelf distro on aarch64, it's almost certainly going to use EFI_LOADER. What I wasn't sure about was armv7, but that was confirmed to be used by default in Fedora and OpenBSD and encouraged (I'll assume I just didn't find the right install media) for Debian. I'd rather talk with someone in Armbian about why they don't use EFI_LOADER than try and convince Fedora to go and use extlinux.conf more (and that leaves out entirely *BSD which is not what I want to do either!).
I don't know why Armbian is different and I am not going to advocate for extlinux.conf either.
There's got to be a better way.
Regards, Simon