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