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

[Tom Rini <trini@konsulko.com>]

On Fri, Oct 20, 2017 at 02:36:27PM +0200, Maxime Ripard 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@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@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@gmail.com> wrote:
> > >> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
> > >> >> > <maxime.ripard@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@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?

Because the goal is that boards ship from the manufacturer with a
firmware that's "good enough".  And firmware updates are handled by
Someone Else, rather than the distro.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171020/be9dda90/attachment.sig>