[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote:
> On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote:
> >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
> >> > <maxime.ripard at free-electrons.com> wrote:
> >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
> >> >>> <maxime.ripard at free-electrons.com> wrote:
> >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> >> >>> > trip across the size limit we've had on the U-Boot binary.
> >> >>> >
> >> >>> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> >> >>> > so that we get back some extra room for user customisations.
> >> >>>
> >> >>> Does this disable it on aarch64 boards by default such as the Pine64?
> >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> >> >>> boot aarch64 devices and this would regress this for all those
> >> >>> distros.
> >> >>
> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can add
> >> >> to their defconfig. These are just default configuration, not
> >> >> one-size-fits-all configuration.
> >> >
> >> > So you're making at least three groups of users do more work? It could
> >> > also be argued that those that need the smaller space could disable it
> >> > if they don't need it in their configuration.
> >>
> >> Ultimately the problem with the argument about disabling it by default
> >> and distros can enable it if they want to is a false one.
> >
> > If it's a false one, then I guess Red Hat doesn't have any kind of
> > custom defconfigs for Fedora or RHEL for the kernel?
> 
> kernel is part of the distro, "firmware" (ie. u-boot or whatever
> implements UEFI) should not be.. so this argument is a bit of a red
> herring.

Then that discussion is entirely moot. If the distros don't care about
building the U-Boot binary, why should they care about maintaining the
U-Boot's defconfig like Peter was suggesting?

> Maybe the solution is a "distro.config" option to separate options
> that make sense for distro/EBBR from what people who are doing more
> non-standard boot-chains are wanting.

It's kind of amazing to see that the usual boot-chain that people have
been relying on for more than a decade and is still in use in the
immense majority of devices can be seen as "non-standard". But I guess
that's a different topic.

> For example, for UEFI boot, we can disable all the filesystems other
> than FAT if you need to trim some space.  And maybe doing a more
> simplified (ie. add it to efi_bootmgr.c) alternative to distro
> bootcmd could save a bunch of .text space.  In fact we don't really
> need the scripting env at all.  Probably there are other options for
> things to disable that I haven't thought of if you *really* needed
> to trim down.

That's good to know. Hopefully we won't need to trim that space since
we got a bit more room to spare by switching to thumb, and if we can
move to a filesystem based environment, we won't ever need it.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171020/b76d4870/attachment.sig>