[PATCH v2 0/9] efi: Various tidy-ups and drop the default

[Simon Glass]

Hi Tom,

On Fri, 2 Jul 2021 at 14:19, Tom Rini <trini at 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 at xs4all.nl> wrote:
> > >
> > > > From: Simon Glass <sjg at 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