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

[Maxime Ripard]

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?

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