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.rip...@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 <pbrobin...@gmail.com> > >> wrote: > >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard > >> > <maxime.rip...@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.rip...@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? > 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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
