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

[Maxime Ripard]

On Fri, Oct 20, 2017 at 01:27:36PM +0100, Peter Robinson wrote:
> On Fri, Oct 20, 2017 at 8:20 AM, Maxime Ripard
> <maxime.ripard at free-electrons.com> wrote:
> > 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?
> 
> You're taking that and turning it around wrong, we currently have to
> care about building it. Ultimately what we'd like is to not have to
> care. One is the current status quo, the other is future desire!

Then we're back to the previous question you didn't answer. If you
have to build it, why can't you have a custom defconfig, or a
configuration fragment like Rob suggested, like you do for the kernel?

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/fb430c2b/attachment.sig>