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

[Rob Clark]

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.

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

BR,
-R

>> By enabling it by default we have devices that ship with SPI or NAND
>> flash, like a bunch of the OrangePis do now, be able to work with
>> all distributions out of the box without any requirements of distros
>> to produce a firmware (something I'd really prefer to leave to the
>> device makers) to boot a number of Linux OSes OOTB.
>
> That one is the false argument in the discussion. No vendor is
> providing such a U-Boot, all of them provide a vendor one that will
> not even be able to boot a mainline kernel, let alone supporting
> EFI. So having something that works out of the box is just a pipe
> dream.
>
>> I think this is a good thing for the entire ecosystem. I don't want
>> to regress that, I'd sooner get the size checks in place and then
>> review rather than what seems like a "quick win"
>
> I've added a size check. 3 boards are broken:
>   - A20-OLinuXino-Lime2-eMMC
>   - A20-OLinuXino-Lime2
>   - Cubietruck
>
> What now?
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>