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

[Peter Robinson]

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!

>> 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