| Message ID | 20171019082649.27819-4-maxime.ripard@free-electrons.com |
|---|---|
| State | New |
| Headers | show |
| Series | sunxi: Fix boot of Cubietruk and al. | expand |
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. Peter > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > lib/efi_loader/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index d2b6327119b4..a80a914b2fe8 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -1,7 +1,7 @@ > config EFI_LOADER > bool "Support running EFI Applications in U-Boot" > depends on (ARM || X86) && OF_LIBFDT > - default y > + default y if !ARCH_SUNXI > help > Select this option if you want to run EFI applications (like grub2) > on top of U-Boot. If this option is enabled, U-Boot will expose EFI > -- > 2.14.2 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot
On 10/19/2017 10:26 AM, Maxime Ripard 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. > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Quite the contrary - it is essential. All major distributions are going for distro boot + EFI at least for 64bit platforms now. Disabling it by default means you basically kill your user base on those. > --- > lib/efi_loader/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index d2b6327119b4..a80a914b2fe8 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -1,7 +1,7 @@ > config EFI_LOADER > bool "Support running EFI Applications in U-Boot" > depends on (ARM || X86) && OF_LIBFDT > - default y > + default y if !ARCH_SUNXI Nack on any change to that default line. If you must disable efi_loader (and really, I strongly advise not to do so for sunxi), please do so in the defconfigs, as nothing prohibits the architecture to work with it. Alex
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. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
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.
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. 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. 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"
On Thu, Oct 19, 2017 at 10:06:15AM +0100, Peter Robinson 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. I don't think asking people to modify their default configuration in order to have U-Boot booting is reasonable, is it? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
On Thu, Oct 19, 2017 at 10:51:04AM +0200, Alexander Graf wrote: > On 10/19/2017 10:26 AM, Maxime Ripard 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. > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > Quite the contrary - it is essential. All major distributions are going for > distro boot + EFI at least for 64bit platforms now. Disabling it by default > means you basically kill your user base on those. EFI is mandatory for 32 and 64 bit OpenBSD arm. I would not be surprised if others made similiar choices to be able to boot off filesystems unsupported by U-Boot and have something close to a real firmware interface. > > > --- > > lib/efi_loader/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > index d2b6327119b4..a80a914b2fe8 100644 > > --- a/lib/efi_loader/Kconfig > > +++ b/lib/efi_loader/Kconfig > > @@ -1,7 +1,7 @@ > > config EFI_LOADER > > bool "Support running EFI Applications in U-Boot" > > depends on (ARM || X86) && OF_LIBFDT > > - default y > > + default y if !ARCH_SUNXI > > Nack on any change to that default line. If you must disable efi_loader (and > really, I strongly advise not to do so for sunxi), please do so in the > defconfigs, as nothing prohibits the architecture to work with it. > > > Alex > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot
> From: Maxime Ripard <maxime.ripard@free-electrons.com> > Date: Thu, 19 Oct 2017 10:26:49 +0200 > > 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. This is an essential feature for booting OpenBSD. And I believe it is a requirement for several Linux distros as well. I don't think disabling this by default is a good idea. How much of that 31kB is due to recent improvements of the EFI loader support? I understand the desire to have a more complete EFI implementation, but if the consequence of that is that the EFI loader gets disabled by default on many boards I think we're throwing out the baby with the bathwater... > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > lib/efi_loader/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index d2b6327119b4..a80a914b2fe8 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -1,7 +1,7 @@ > config EFI_LOADER > bool "Support running EFI Applications in U-Boot" > depends on (ARM || X86) && OF_LIBFDT > - default y > + default y if !ARCH_SUNXI > help > Select this option if you want to run EFI applications (like grub2) > on top of U-Boot. If this option is enabled, U-Boot will expose EFI > -- > 2.14.2 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot >
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? > 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
On Thu, Oct 19, 2017 at 01:39:28PM +0200, Mark Kettenis wrote: > > From: Maxime Ripard <maxime.ripard@free-electrons.com> > > Date: Thu, 19 Oct 2017 10:26:49 +0200 > > > > 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. > > This is an essential feature for booting OpenBSD. And I believe it is > a requirement for several Linux distros as well. I don't think > disabling this by default is a good idea. I get it, every one wants its old features. We can't have that. Can we move forward in the discussion? > How much of that 31kB is due to recent improvements of the EFI loader > support? I understand the desire to have a more complete EFI > implementation, but if the consequence of that is that the EFI loader > gets disabled by default on many boards I think we're throwing out the > baby with the bathwater... Bisection led to a meaningless (as in not relevant to the current discussion) commit that was just adding a bit of code, and probably was just tripping over the limit. So it's basically only a symptom, and it shouldn't prevent any development from happening. What I'd like to happen though is a real discussion on why on Earth we should have all the usecases in the worlds supported in our defconfigs, especially for distros that will package and build U-Boot themselves. Everyone has a custom defconfig for the kernel. What's so different? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
On Thu, Oct 19, 2017 at 10:51:04AM +0200, Alexander Graf wrote: > > lib/efi_loader/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > index d2b6327119b4..a80a914b2fe8 100644 > > --- a/lib/efi_loader/Kconfig > > +++ b/lib/efi_loader/Kconfig > > @@ -1,7 +1,7 @@ > > config EFI_LOADER > > bool "Support running EFI Applications in U-Boot" > > depends on (ARM || X86) && OF_LIBFDT > > - default y > > + default y if !ARCH_SUNXI > > Nack on any change to that default line. If you must disable efi_loader (and > really, I strongly advise not to do so for sunxi), please do so in the > defconfigs, as nothing prohibits the architecture to work with it. That's a bit of a separate discussion. We don't want to have too much churn in the defconfig, as it is basically boilerplate that some will get wrong, and then you won't have a consistent tool set between boards, which is also a pain. A pain both to maintain and use if you want to ship something board agnostic. However, the preferred way expressed by Tom to change defaults has been to change those defaults directly in the Kconfig option, instead of them creeping in everywhere in the arch's or platform Kconfig files. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
On Thu, Oct 19, 2017 at 10:26:49AM +0200, Maxime Ripard 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. > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > lib/efi_loader/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index d2b6327119b4..a80a914b2fe8 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig > @@ -1,7 +1,7 @@ > config EFI_LOADER > bool "Support running EFI Applications in U-Boot" > depends on (ARM || X86) && OF_LIBFDT > - default y > + default y if !ARCH_SUNXI > help > Select this option if you want to run EFI applications (like grub2) > on top of U-Boot. If this option is enabled, U-Boot will expose EFI I want to speak against this particular option. "U-Boot boots EFI application, $distro just works" is a huge deal right now. As much as I would have preferred various other things happen at various points in the past, kicking off an EFI application to boot Linux is huge and important outside of the embedded space (and ARM Ltd is pushing this path within the embedded space). There are cases where we don't want the EFI loader, but for ARMv7/AArch64 this should be enabled by default and turned off at the board level for specific use cases. -- Tom
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 >
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? > 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
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! >> 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
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? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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
On Fri, Oct 20, 2017 at 1:36 PM, Maxime Ripard <maxime.ripard@free-electrons.com> 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? We probably could, but we haven't to date, and we don't do it for any of the other u-boot configs we build. It also doesn't fix the issue for other board vendors that ship them, and yes, despite what you've said previously, we do now get a lot of ARMv7 boards that have the distro defaults enabled for their boards and do just work out of the box for the distros. What is enabled by default upstream does make a difference for what vendors ship. Peter
On Fri, Oct 20, 2017 at 08:54:43AM -0400, Tom Rini wrote: > > > >> > 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. We're talking about a vendor that ships today a U-Boot build that either doesn't have DT support, or doesn't start the kernel in the proper execution level which prevents any mainline kernel from running. Maybe it's just me being too pessimistic about this, but do you really expect to see a time where they would ship a bootloader with EFI? Maxmie -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
On Fri, Oct 20, 2017 at 06:39:18PM +0200, Maxime Ripard wrote: > On Fri, Oct 20, 2017 at 08:54:43AM -0400, Tom Rini wrote: > > > > >> > 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. > > We're talking about a vendor that ships today a U-Boot build that > either doesn't have DT support, or doesn't start the kernel in the > proper execution level which prevents any mainline kernel from > running. > > Maybe it's just me being too pessimistic about this, but do you really > expect to see a time where they would ship a bootloader with EFI? There's actually a relative lot of vendor stuff that's based on "only" 2 or so year old U-Boot, and starts to get things right. So yes, once you start to factor in the design->production lag, we will start to see more and more devices that come out with these features enabled and either in-use (because it's relevant to the product) or community-used (because the product can be end-user-used and it's not something that was turned off). And we're starting to see more and wider silicon vendor support coming in and in my experience there's often a lot of "if the vendor defaults work, just add what we need on top" in custom designs. For the kernel and U-Boot both. -- Tom
On Fri, Oct 20, 2017 at 5:39 PM, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > On Fri, Oct 20, 2017 at 08:54:43AM -0400, Tom Rini wrote: >> > > >> > 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. > > We're talking about a vendor that ships today a U-Boot build that > either doesn't have DT support, or doesn't start the kernel in the > proper execution level which prevents any mainline kernel from > running. > > Maybe it's just me being too pessimistic about this, but do you really > expect to see a time where they would ship a bootloader with EFI? Yes, my $dayjob is IoT focused and I'm speaking with vendors about it now, demoing it to them. Also ARM and others are engaged in a EBBR (Embedded Base Boot Requirements) similar to the Server Base Boot Requirements (SBBR) spec so I suspect once that becomes standard which includes a lot of thing you'll find it'll be actively requested by vendors. Plus most of what Tom mentions in his response. When Fedora did the first version of distro boot it took us time to get traction, then nvidia picked it up because they saw the value, now just look at the vendor patches adding that. uEFI is the extension to this, v2 if you like.
On 10/19/2017 10:43 AM, 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. > > Peter > Debian uses package flash-kernel by default. Flash-kernel generates a new boot.scr script every time you install a new kernel. Packages grub-efi-arm and grub-efi-arm64 are provided for those who prefer to boot their ARM board via EFI. All sunxi boards use SPL=y. So why should there be a size limit crossed? Is there an unsuitable limit built in to the second stage boot loader? Then this should be fixed instead of castrating the configuration. Heinrich >> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> >> --- >> lib/efi_loader/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig >> index d2b6327119b4..a80a914b2fe8 100644 >> --- a/lib/efi_loader/Kconfig >> +++ b/lib/efi_loader/Kconfig >> @@ -1,7 +1,7 @@ >> config EFI_LOADER >> bool "Support running EFI Applications in U-Boot" >> depends on (ARM || X86) && OF_LIBFDT >> - default y >> + default y if !ARCH_SUNXI >> help >> Select this option if you want to run EFI applications (like grub2) >> on top of U-Boot. If this option is enabled, U-Boot will expose EFI >> -- >> 2.14.2 >> >> _______________________________________________ >> 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 >
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index d2b6327119b4..a80a914b2fe8 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,7 +1,7 @@ config EFI_LOADER bool "Support running EFI Applications in U-Boot" depends on (ARM || X86) && OF_LIBFDT - default y + default y if !ARCH_SUNXI help Select this option if you want to run EFI applications (like grub2) on top of U-Boot. If this option is enabled, U-Boot will expose EFI
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. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- lib/efi_loader/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)