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!).

-- 
Tom