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

[Peter Robinson]

On Fri, Oct 20, 2017 at 1:36 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> 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?

We probably could, but we haven't to date, and we don't do it for any
of the other u-boot configs we build. It also doesn't fix the issue
for other board vendors that ship them, and yes, despite what you've
said previously, we do now get a lot of ARMv7 boards that have the
distro defaults enabled for their boards and do just work out of the
box for the distros. What is enabled by default upstream does make a
difference for what vendors ship.

Peter