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. 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@lists.denx.de > https://lists.denx.de/listinfo/u-boot > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot