[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
Maxime
Maxime Ripard (3): ARM: sunxi: Disable USB host options by default ARM: sunxi: Disable FAT write by default efi_loader: Do not enable it by default for sunxi
arch/arm/Kconfig | 4 ---- lib/efi_loader/Kconfig | 2 +- 2 files changed, 1 insertion(+), 5 deletions(-)
The USB keyboard and USB storage support are non-essential from an architecture-wide sense.
Remove the selection so that we can trim down the size of our binaries a bit.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com --- arch/arm/Kconfig | 3 --- 1 file changed, 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 64e0ee43f112..0eaf54bd8ddb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -688,7 +688,6 @@ config ARCH_SUNXI select DM select DM_ETH select DM_GPIO - select DM_KEYBOARD select DM_SERIAL select DM_USB if DISTRO_DEFAULTS select OF_BOARD_SETUP @@ -699,8 +698,6 @@ config ARCH_SUNXI select SYS_NS16550 select SPL_SYS_THUMB_BUILD if !ARM64 select USB if DISTRO_DEFAULTS - select USB_STORAGE if DISTRO_DEFAULTS - select USB_KEYBOARD if DISTRO_DEFAULTS select USE_TINY_PRINTF imply CMD_GPT imply FAT_WRITE
On 10/19/2017 10:26 AM, Maxime Ripard wrote:
The USB keyboard and USB storage support are non-essential from an architecture-wide sense.
Remove the selection so that we can trim down the size of our binaries a bit.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
Most users out there that I'm aware of use U-Boot without serial port attached. Disabling USB keyboard support means they can no longer interact with their firmware. That's a terrible thing to do.
Alex
Hi,
On 19/10/17 09:48, Alexander Graf wrote:
On 10/19/2017 10:26 AM, Maxime Ripard wrote:
The USB keyboard and USB storage support are non-essential from an architecture-wide sense.
Remove the selection so that we can trim down the size of our binaries a bit.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
Most users out there that I'm aware of use U-Boot without serial port attached. Disabling USB keyboard support means they can no longer interact with their firmware. That's a terrible thing to do.
Also USB storage is the canonical way of installing distributions, by using an USB flash drive with a generic (UEFI) installer on it.
And I second the concerns about removal of UEFI support and USB keyboard. Especially UEFI is a real deal breaker for ARM64 boards.
So while I see that this series fixes a particular problem, I am a bit wary of this solution, as this just papers over the issue and will likely break in the future again.
Can't we somehow fix the environment problem? Possibly via the upgrade process (save the environment, update U-Boot, re-install the environment)? Or some other clever way? That would be more future proof, I believe.
Cheers, Andre.
Hi Andre,
On Thu, Oct 19, 2017 at 10:11:19AM +0100, Andre Przywara wrote:
So while I see that this series fixes a particular problem, I am a bit wary of this solution, as this just papers over the issue and will likely break in the future again.
Can't we somehow fix the environment problem? Possibly via the upgrade process (save the environment, update U-Boot, re-install the environment)? Or some other clever way? That would be more future proof, I believe.
That would be the ideal solution, but it would also assume that you have an upgrade mechanism in the first place. It might work for the distros, but it will not for anyone else that will just upgrade as they did it for the last 5 years and suddenly everything is broken.
And part of that upgrade would also be to change the partition layout if you created partitions that match the various offsets, which is basically impossible without reflashing everything again.
So yeah, I would very much favor that, but that's not really doable.
Maxime
On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
The USB keyboard and USB storage support are non-essential from an architecture-wide sense.
A lot of Fedora users boot from USB HDDs by having a small (say an old 128Mb mSD card from a phone) SD card and then boot the OS from the disk so this will break all of those, plus if they don't have a serial console it means they can't do things like debug or select an older kernel to boot if there was an issue.
Remove the selection so that we can trim down the size of our binaries a bit.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
arch/arm/Kconfig | 3 --- 1 file changed, 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 64e0ee43f112..0eaf54bd8ddb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -688,7 +688,6 @@ config ARCH_SUNXI select DM select DM_ETH select DM_GPIO
select DM_KEYBOARD select DM_SERIAL select DM_USB if DISTRO_DEFAULTS select OF_BOARD_SETUP@@ -699,8 +698,6 @@ config ARCH_SUNXI select SYS_NS16550 select SPL_SYS_THUMB_BUILD if !ARM64 select USB if DISTRO_DEFAULTS
select USB_STORAGE if DISTRO_DEFAULTSselect USB_KEYBOARD if DISTRO_DEFAULTS select USE_TINY_PRINTF imply CMD_GPT imply FAT_WRITE-- 2.14.2
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:47 +0200
The USB keyboard and USB storage support are non-essential from an architecture-wide sense.
Remove the selection so that we can trim down the size of our binaries a bit.
But many people rely on these options and I'd say they should be enabled on the majority of the boards out there.
If you really want to go this way, I'd say you should enable these options in all the board-specific configs and subsequently remove them from those boards where they're not useful.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com
arch/arm/Kconfig | 3 --- 1 file changed, 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 64e0ee43f112..0eaf54bd8ddb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -688,7 +688,6 @@ config ARCH_SUNXI select DM select DM_ETH select DM_GPIO
- select DM_KEYBOARD select DM_SERIAL select DM_USB if DISTRO_DEFAULTS select OF_BOARD_SETUP
@@ -699,8 +698,6 @@ config ARCH_SUNXI select SYS_NS16550 select SPL_SYS_THUMB_BUILD if !ARM64 select USB if DISTRO_DEFAULTS
- select USB_STORAGE if DISTRO_DEFAULTS
- select USB_KEYBOARD if DISTRO_DEFAULTS select USE_TINY_PRINTF imply CMD_GPT imply FAT_WRITE
-- 2.14.2
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Writing to FAT filesystems isn't a very widely used feature in U-Boot where most of the interaction would be reading from such a filesystem.
Remove the imply to gain a bit of size in our binaries.
Signed-off-by: Maxime Ripard maxime.ripard@free-electrons.com --- arch/arm/Kconfig | 1 - 1 file changed, 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 0eaf54bd8ddb..2f67ccb9df30 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -700,7 +700,6 @@ config ARCH_SUNXI select USB if DISTRO_DEFAULTS select USE_TINY_PRINTF imply CMD_GPT - imply FAT_WRITE imply PRE_CONSOLE_BUFFER imply SPL_GPIO_SUPPORT imply SPL_LIBCOMMON_SUPPORT
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
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 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
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: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
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
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
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.
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
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.
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 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 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
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
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 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
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
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 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
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.
On 10/19/2017 10:26 AM, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
How about we add the size check first before crippling the feature set of sunxi boards? Then maybe rather disable lesser used features than efi_loader?
Alex
On Thu, Oct 19, 2017 at 10:44:54AM +0200, Alexander Graf wrote:
On 10/19/2017 10:26 AM, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
How about we add the size check first before crippling the feature set of sunxi boards? Then maybe rather disable lesser used features than efi_loader?
All the features have some users. All the kind of arguments that have been sent so far are that "but I use this feature". Yes. You probably do. But you can have the same kind of argument for any of the features enabled.
Let's look at the features enabled by a Cubietruck defconfig: - GMAC: I'm pretty sure there's some people using network out there, and you don't want to break those. - AHCI: I'm pretty sure there's some people using their SATA disk out there, and you don't want to break those. - PSCI: I'm pretty sure there's some people using multiple CPUs out there, and you don't want to break those. - Fastboot: I'm pretty sure there's some people reflashing their systems out there, and you don't want to break those. - DFU: I'm pretty sure there's some people reflashing their systems out there and that don't like fastboot, and you don't want to break those. - MMC: I'm pretty sure there's some people using their MMC card out there, and you don't want to break those. - USB: I'm pretty sure there's some people using their USB devices out there, and you don't want to break those.
tl; dr: using that kind of argument, nothing is removed, and we keep building non-functional (as in, non-booting) binaries. Is that *really* what you're suggesting?
Maxime
On 10/19/2017 11:11 AM, Maxime Ripard wrote:
On Thu, Oct 19, 2017 at 10:44:54AM +0200, Alexander Graf wrote:
On 10/19/2017 10:26 AM, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
How about we add the size check first before crippling the feature set of sunxi boards? Then maybe rather disable lesser used features than efi_loader?
All the features have some users. All the kind of arguments that have been sent so far are that "but I use this feature". Yes. You probably do. But you can have the same kind of argument for any of the features enabled.
I agree, but my first statement still holds: Please make sure we don't overrun our size restrictions first so that these issue get caught early during the development cycle, not when U-Boot is already released.
That said, how about we just imply SYS_THUMB_BUILD in ARCH_SUNXI? That way we save even more (going from 537K to 417K with gcc7.1) without losing any feature set on 32bit systems.
Alex
On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
Maxime
Maxime Ripard (3): ARM: sunxi: Disable USB host options by default ARM: sunxi: Disable FAT write by default efi_loader: Do not enable it by default for sunxi
arch/arm/Kconfig | 4 ---- lib/efi_loader/Kconfig | 2 +- 2 files changed, 1 insertion(+), 5 deletions(-)
We can first enable Thumb2 build by default for 32-bit sunxi boards and this should fix Cubietruck problems.
$ cat .config | grep THUMB CONFIG_HAS_THUMB2=y # CONFIG_SYS_THUMB_BUILD is not set CONFIG_SPL_SYS_THUMB_BUILD=y
As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig reduces the size of the resulting U-Boot binary.
== Before: ==
$ arm-linux-gnueabihf-size u-boot text data bss dec hex filename 489398 26492 249240 765130 bacca u-boot.orig
== After: ==
$ arm-linux-gnueabihf-size u-boot text data bss dec hex filename 366314 26492 249232 642038 9cbf6 u-boot
On Thu, Oct 19, 2017 at 12:10:44PM +0300, Siarhei Siamashka wrote:
On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
Maxime
Maxime Ripard (3): ARM: sunxi: Disable USB host options by default ARM: sunxi: Disable FAT write by default efi_loader: Do not enable it by default for sunxi
arch/arm/Kconfig | 4 ---- lib/efi_loader/Kconfig | 2 +- 2 files changed, 1 insertion(+), 5 deletions(-)
We can first enable Thumb2 build by default for 32-bit sunxi boards and this should fix Cubietruck problems.
$ cat .config | grep THUMB CONFIG_HAS_THUMB2=y # CONFIG_SYS_THUMB_BUILD is not set CONFIG_SPL_SYS_THUMB_BUILD=y
As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig reduces the size of the resulting U-Boot binary.
== Before: ==
$ arm-linux-gnueabihf-size u-boot text data bss dec hex filename 489398 26492 249240 765130 bacca u-boot.orig
== After: ==
$ arm-linux-gnueabihf-size u-boot text data bss dec hex filename 366314 26492 249232 642038 9cbf6 u-boot
Yes, I would strongly encourage enabling Thumb2 support instead of removing various features.
I would also encourage looking at moving environment either "up", or switching to env in filesystem in the future as a "Yes, we broke your existing setup, but we gave you a real useful feature".
Hi Siarhei,
On Thu, Oct 19, 2017 at 12:10:44PM +0300, Siarhei Siamashka wrote:
On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
Maxime
Maxime Ripard (3): ARM: sunxi: Disable USB host options by default ARM: sunxi: Disable FAT write by default efi_loader: Do not enable it by default for sunxi
arch/arm/Kconfig | 4 ---- lib/efi_loader/Kconfig | 2 +- 2 files changed, 1 insertion(+), 5 deletions(-)
We can first enable Thumb2 build by default for 32-bit sunxi boards and this should fix Cubietruck problems.
$ cat .config | grep THUMB CONFIG_HAS_THUMB2=y # CONFIG_SYS_THUMB_BUILD is not set CONFIG_SPL_SYS_THUMB_BUILD=y
As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig reduces the size of the resulting U-Boot binary.
== Before: ==
$ arm-linux-gnueabihf-size u-boot text data bss dec hex filename 489398 26492 249240 765130 bacca u-boot.orig
== After: ==
$ arm-linux-gnueabihf-size u-boot text data bss dec hex filename 366314 26492 249232 642038 9cbf6 u-boot
I just gave it a try, and indeed it solves the issue for all the boards. Thanks for the suggestion!
I'll send the patches.
Maxime
Hi,
On 19/10/17 09:26, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question)
I see that the environment is hardcoded to 0x88000 in env/Kconfig. Where does this value come from? Why is it this rather arbitrary value?
I believe the real limit should be 1MB - ENV_SIZE. Most sane partitioning tools put the first partition at 1MB, so this leaves the space below that to the bootloader/firmware.
This would put the actual limit at 856 KB for now - that should be enough for everybody ;-) We could even push this further by reducing ENV_SIZE to say 64KB.
At least that would buy us some time to address this issue in a more sustainable way.
Cheers, Andre.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
Maxime
Maxime Ripard (3): ARM: sunxi: Disable USB host options by default ARM: sunxi: Disable FAT write by default efi_loader: Do not enable it by default for sunxi
arch/arm/Kconfig | 4 ---- lib/efi_loader/Kconfig | 2 +- 2 files changed, 1 insertion(+), 5 deletions(-)
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 09:26, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question)
All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ?
I know I don't.
And I guess the question should be turned the other way around. Should you expect your environment to be erased / ignored by any upgrade?
There's never been any documentation on this as far as I know, so there's probably people that will expect it to be fixed, and things keep on booting.
I see that the environment is hardcoded to 0x88000 in env/Kconfig. Where does this value come from? Why is it this rather arbitrary value?
It predates my involvement in U-Boot, so I don't really know, but I guess some arbitrary value needed to be picked and someone did (maybe Hans or Enrick) because it seemed reasonable at the time.
I believe the real limit should be 1MB - ENV_SIZE. Most sane partitioning tools put the first partition at 1MB, so this leaves the space below that to the bootloader/firmware.
Is that 1MB after the partition table or 1MB since the beginning of the device?
This would put the actual limit at 856 KB for now - that should be enough for everybody ;-) We could even push this further by reducing ENV_SIZE to say 64KB.
At least that would buy us some time to address this issue in a more sustainable way.
Yeah, but even if we could address the issues mentionned above, we'd still need to take care of the partitions for let's say the environment that would need to be moved as well. This is just not practical.
I guess we could introduce a new image with more room for the u-boot binary, and advertise it as such. But we would still have to build the old one for quite some time.
Maxime
On Thu, Oct 19, 2017 at 03:24:57PM +0200, Maxime Ripard wrote:
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 09:26, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question)
All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ?
I know I don't.
And I guess the question should be turned the other way around. Should you expect your environment to be erased / ignored by any upgrade?
There's never been any documentation on this as far as I know, so there's probably people that will expect it to be fixed, and things keep on booting.
There is a strong expectation that environment is preserved. In deployment cases, it's a must, and when it's not able to happen, people have to work their upgrade such that it knows and the flag-day type action happens.
It's certainly not unprecedented to change the env location / size / type (we've done it on am335x_evm/related a few times) but it usually requires a good reason and communication outward too.
I see that the environment is hardcoded to 0x88000 in env/Kconfig. Where does this value come from? Why is it this rather arbitrary value?
It predates my involvement in U-Boot, so I don't really know, but I guess some arbitrary value needed to be picked and someone did (maybe Hans or Enrick) because it seemed reasonable at the time.
Yes, it's likely a reasonable at the time choice. This is also, FWIW, I try and encourage new SoCs to pick env in filesystem options instead as it's generally more friendly for reference / general purpose type builds, and custom designs can still easily figure out where they want to store env and do so.
Hi,
On 19/10/17 14:24, Maxime Ripard wrote:
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 09:26, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question)
All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ?
I know I don't.
Well, I never use the saved environment and always expected some user or board specific environment to come from some file (boot.scr or something loaded via TFTP). But that's just my personal use, hence I was asking. And I was wondering if it hasn't been broken in the past for arm64 sunxi boards already, because aarch64 code is usually bigger (I remember seeing like +20% for u-boot.bin in the past).
And I guess the question should be turned the other way around. Should you expect your environment to be erased / ignored by any upgrade?
I think this is usually the case for a BIOS upgrade on a PC.
There's never been any documentation on this as far as I know, so there's probably people that will expect it to be fixed, and things keep on booting.
That's probably right and we should be nice ;-)
I see that the environment is hardcoded to 0x88000 in env/Kconfig. Where does this value come from? Why is it this rather arbitrary value?
It predates my involvement in U-Boot, so I don't really know, but I guess some arbitrary value needed to be picked and someone did (maybe Hans or Enrick) because it seemed reasonable at the time.
I chased it down to: commit e24ea55c04a8ee9c273dd879edda23bbde3d807a Author: Ian Campbell ijc@hellion.org.uk Date: Mon May 5 14:42:31 2014 +0100
sunxi: mmc support
So yeah, dawn of time (for upstream sunxi support).
I believe the real limit should be 1MB - ENV_SIZE. Most sane partitioning tools put the first partition at 1MB, so this leaves the space below that to the bootloader/firmware.
Is that 1MB after the partition table or 1MB since the beginning of the device?
The beginning of the device. I would expect a (legacy) layout to be: @0: MBR (1 sector) @8K: SPL (up to 32KB) @40K: U-Boot image (@544K: environment) @1MB: first primary partition Not sure if there is anything else in there.
I wonder if we could insert some code in U-Boot to move the environment in preparation for a hard change? Like: - Before looking at 544K, check for a valid environment at 896K. - If an env is found @544K: move it to 896K, invalidate the 544K copy.
If we have this algorithm live for some time, we might be able to catch and migrate many users, without making life miserable for *everyone*. Not perfect, I know, but better than a hard cut. Meanwhile we switch to Thumb2 to buy us some time and add a build time check to be alerted when future builds exceed the current limit.
This would put the actual limit at 856 KB for now - that should be enough for everybody ;-) We could even push this further by reducing ENV_SIZE to say 64KB.
At least that would buy us some time to address this issue in a more sustainable way.
Yeah, but even if we could address the issues mentionned above, we'd still need to take care of the partitions for let's say the environment that would need to be moved as well. This is just not practical.
I don't understand. What partitions? Android? Do they start between 544K and 1MB?
I guess we could introduce a new image with more room for the u-boot binary, and advertise it as such. But we would still have to build the old one for quite some time.
Who would be "we", exactly? Distributions? I guess this is the only case where we want to preserve the ENV location? Could they mitigate this by using the transitional schema as described above? For new (whole) images this would certainly not be a problem, would it?
Cheers, Andre.
On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 14:24, Maxime Ripard wrote:
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 09:26, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question)
All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ?
I know I don't.
Well, I never use the saved environment and always expected some user or board specific environment to come from some file (boot.scr or something loaded via TFTP). But that's just my personal use, hence I was asking.
Well, even if you want to boot to tftp, you'll need to have some setup to do, even just to use a different server IP, and that will be in the environment.
And I was wondering if it hasn't been broken in the past for arm64 sunxi boards already, because aarch64 code is usually bigger (I remember seeing like +20% for u-boot.bin in the past).
And I guess the question should be turned the other way around. Should you expect your environment to be erased / ignored by any upgrade?
I think this is usually the case for a BIOS upgrade on a PC.
Yeah, so definitely not the U-Boot habits :)
I believe the real limit should be 1MB - ENV_SIZE. Most sane partitioning tools put the first partition at 1MB, so this leaves the space below that to the bootloader/firmware.
Is that 1MB after the partition table or 1MB since the beginning of the device?
The beginning of the device. I would expect a (legacy) layout to be: @0: MBR (1 sector) @8K: SPL (up to 32KB) @40K: U-Boot image (@544K: environment) @1MB: first primary partition Not sure if there is anything else in there.
I wonder if we could insert some code in U-Boot to move the environment in preparation for a hard change? Like:
- Before looking at 544K, check for a valid environment at 896K.
- If an env is found @544K: move it to 896K, invalidate the 544K copy.
If we have this algorithm live for some time, we might be able to catch and migrate many users, without making life miserable for *everyone*. Not perfect, I know, but better than a hard cut.
I guess if we were to do this, we'd better store it in a filesystem file directly like Tom suggested, and just skip the increase of the size.
This would put the actual limit at 856 KB for now - that should be enough for everybody ;-) We could even push this further by reducing ENV_SIZE to say 64KB.
At least that would buy us some time to address this issue in a more sustainable way.
Yeah, but even if we could address the issues mentionned above, we'd still need to take care of the partitions for let's say the environment that would need to be moved as well. This is just not practical.
I don't understand. What partitions? Android? Do they start between 544K and 1MB?
I've seen (and built) setups where you would have a partition dedicated to the U-Boot environment and binaries so that you can upgrade / switch them easily.
fastboot (and I suspect dfu) makes that really convenient.
I guess we could introduce a new image with more room for the u-boot binary, and advertise it as such. But we would still have to build the old one for quite some time.
Who would be "we", exactly? Distributions?
U-Boot upstream
I guess this is the only case where we want to preserve the ENV location? Could they mitigate this by using the transitional schema as described above? For new (whole) images this would certainly not be a problem, would it?
Even in the transition scheme, let's say you have a user that would use a 'legacy' offset for its environment, you will not want to overwrite it, so you'll need the size check for as long as the transition period last.
Maxime
El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió:
On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 14:24, Maxime Ripard wrote:
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 09:26, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question)
All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ?
I know I don't.
Well, I never use the saved environment and always expected some user or board specific environment to come from some file (boot.scr or something loaded via TFTP). But that's just my personal use, hence I was asking.
Well, even if you want to boot to tftp, you'll need to have some setup to do, even just to use a different server IP, and that will be in the environment.
I personally just use pxe boot dhcp pxe get pxe boot and pick the right option. nothing needed on the client side.
Dennis
On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote:
El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió:
On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 14:24, Maxime Ripard wrote:
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 09:26, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question)
All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ?
I know I don't.
Well, I never use the saved environment and always expected some user or board specific environment to come from some file (boot.scr or something loaded via TFTP). But that's just my personal use, hence I was asking.
Well, even if you want to boot to tftp, you'll need to have some setup to do, even just to use a different server IP, and that will be in the environment.
I personally just use pxe boot
It's not really about what personally you use, but what any user can use.
dhcp pxe get pxe boot and pick the right option. nothing needed on the client side.
It has the assumption that the DHCP server is setup properly, which might or might not be the case, especially when it comes to the server option being there and valid.
Maxime
El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió:
On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote:
El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió:
On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 14:24, Maxime Ripard wrote:
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 09:26, Maxime Ripard wrote: > Hi, > > Most featureful boards, such as the Cubietruck, have been > broken since > the release 2017.09. > > This is due to a size increase of the binary that will > trip > us across > the size we've been using in the u-boot-sunxi-with- > spl.bin > file. > > We would have two ways to work around it. The first one > would > be to > just increase the offset of the environment. However, > since > it would > break all the environments of our users and possibly the > custom > partition scheme that they would have created, it doesn't > really seem > like a smart move.
Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question)
All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ?
I know I don't.
Well, I never use the saved environment and always expected some user or board specific environment to come from some file (boot.scr or something loaded via TFTP). But that's just my personal use, hence I was asking.
Well, even if you want to boot to tftp, you'll need to have some setup to do, even just to use a different server IP, and that will be in the environment.
I personally just use pxe boot
It's not really about what personally you use, but what any user can use.
Not saying that it is. but how I use it is really simple for the user to use without needing to have a ton of specific knowledge about how u- boot works
dhcp pxe get pxe boot and pick the right option. nothing needed on the client side.
It has the assumption that the DHCP server is setup properly, which might or might not be the case, especially when it comes to the server option being there and valid.
Maxime
Anyone doing something like this on X86 has to have the same setup. its not that hard of a ask to assume that a pxe environment is available. you can skip the dhcp part and set the serrver ip and system ip manually, its just simpler to use dhcp
Dennis
Hi,
On 24/10/17 18:05, Dennis Gilmore wrote:
El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió:
On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote:
El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió:
On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 14:24, Maxime Ripard wrote:
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: > Hi, > > On 19/10/17 09:26, Maxime Ripard wrote: >> Hi, >> >> Most featureful boards, such as the Cubietruck, have been >> broken since >> the release 2017.09. >> >> This is due to a size increase of the binary that will >> trip >> us across >> the size we've been using in the u-boot-sunxi-with- >> spl.bin >> file. >> >> We would have two ways to work around it. The first one >> would >> be to >> just increase the offset of the environment. However, >> since >> it would >> break all the environments of our users and possibly the >> custom >> partition scheme that they would have created, it doesn't >> really seem >> like a smart move. > > Is that really such a problem? How many people rely on > having > their > custom environment preserved over an update? (That's an > honest > question)
All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ?
I know I don't.
Well, I never use the saved environment and always expected some user or board specific environment to come from some file (boot.scr or something loaded via TFTP). But that's just my personal use, hence I was asking.
Well, even if you want to boot to tftp, you'll need to have some setup to do, even just to use a different server IP, and that will be in the environment.
I personally just use pxe boot
It's not really about what personally you use, but what any user can use.
Not saying that it is. but how I use it is really simple for the user to use without needing to have a ton of specific knowledge about how u- boot works
dhcp pxe get pxe boot and pick the right option. nothing needed on the client side.
It has the assumption that the DHCP server is setup properly, which might or might not be the case, especially when it comes to the server option being there and valid.
Maxime
Anyone doing something like this on X86 has to have the same setup. its not that hard of a ask to assume that a pxe environment is available. you can skip the dhcp part and set the serrver ip and system ip manually, its just simpler to use dhcp
I agree to both of you ;-) As Maxime already pointed out, it's a bit of a pointless discussion, as x U-Boot users have possibly x different usage scenarios. Some very actively do work on the U-Boot prompt and rely on a customized and preserved environment, while others merely rely on some standardized boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI.
That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly. And I believe that the arm64 boards mostly use a standardized way of booting, also are much less wide spread, so the number of affected users is probably less there.
I am just thinking of whether it's worthwhile to have some transition code, which tries multiple environment locations (first FAT, then MMC, for instance), or even contains code to migrate from one to another.
Cheers, Andre.
On Tue, Oct 24, 2017 at 06:21:43PM +0100, Andre Przywara wrote:
That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly. And I believe that the arm64 boards mostly use a standardized way of booting, also are much less wide spread, so the number of affected users is probably less there.
I am just thinking of whether it's worthwhile to have some transition code, which tries multiple environment locations (first FAT, then MMC, for instance), or even contains code to migrate from one to another.
I started to look into the latter as well, because that's really what I'd like to see (for some time at least).
I guess having a custom environment handling method would be the best, and it doesn't seem that hard.
The behaviour I had in mind would be, when reading: - Look for an environment in a FAT partition - If not: - Load the raw environment - Print a warning
When writing: - Try to write the environment to a FAT partition - If it fails: - Write to the raw environment - Print a warning
That way, we can slowly migrate users in a transparent manner as soon as they would use saveenv, and we also provide a warning that things might (and actually will) break in the future if the setup isn't changed.
We could even just rely on the existing methods from both standards environment code, we just need to make the functions !static.
Maxime
I'm personally feel trimming un(non)used bits(which might use in future or not) is not a good idea.why can't we have TPL because even adding Falcon might also increase the size.
On 25-Oct-2017 11:43 AM, "Maxime Ripard" maxime.ripard@free-electrons.com wrote:
On Tue, Oct 24, 2017 at 06:21:43PM +0100, Andre Przywara wrote:
That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly. And I believe that the arm64 boards mostly use a standardized way of booting, also are much less wide spread, so the number of affected users is probably less there.
I am just thinking of whether it's worthwhile to have some transition code, which tries multiple environment locations (first FAT, then MMC, for instance), or even contains code to migrate from one to another.
I started to look into the latter as well, because that's really what I'd like to see (for some time at least).
I guess having a custom environment handling method would be the best, and it doesn't seem that hard.
The behaviour I had in mind would be, when reading: - Look for an environment in a FAT partition - If not: - Load the raw environment - Print a warning
When writing: - Try to write the environment to a FAT partition - If it fails: - Write to the raw environment - Print a warning
That way, we can slowly migrate users in a transparent manner as soon as they would use saveenv, and we also provide a warning that things might (and actually will) break in the future if the setup isn't changed.
We could even just rely on the existing methods from both standards environment code, we just need to make the functions !static.
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
Hi Jagan,
On Wed, Oct 25, 2017 at 03:25:59PM +0530, Jagan Teki wrote:
I'm personally feel trimming un(non)used bits(which might use in future or not) is not a good idea.why can't we have TPL because even adding Falcon might also increase the size.
As far as I understand it, the TPL is just an extra step between the SPL and the main U-Boot binary.
I'm not exactly sure how that would allow us to increase the size of the main U-Boot binary. Can you elaborate?
Thanks! Maxime
Hi,
On 25/10/17 10:42, Maxime Ripard wrote:
On Tue, Oct 24, 2017 at 06:21:43PM +0100, Andre Przywara wrote:
That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly. And I believe that the arm64 boards mostly use a standardized way of booting, also are much less wide spread, so the number of affected users is probably less there.
I am just thinking of whether it's worthwhile to have some transition code, which tries multiple environment locations (first FAT, then MMC, for instance), or even contains code to migrate from one to another.
I started to look into the latter as well, because that's really what I'd like to see (for some time at least).
I guess having a custom environment handling method would be the best, and it doesn't seem that hard.
The behaviour I had in mind would be, when reading:
- Look for an environment in a FAT partition
- If not:
- Load the raw environment
- Print a warning
When writing:
- Try to write the environment to a FAT partition
- If it fails:
- Write to the raw environment
- Print a warning
That way, we can slowly migrate users in a transparent manner as soon as they would use saveenv, and we also provide a warning that things might (and actually will) break in the future if the setup isn't changed.
That was exactly what I had in mind as well!
Do you have some spare cycles to implement this? If not, I can give it a try.
We could even just rely on the existing methods from both standards environment code, we just need to make the functions !static.
There is even a Delphic comment in env/Kconfig: "At *present* the environment can be stored in only one place." ;-)
Cheers, Andre.
P.S. I will arrive tonight in Prague, for the DT workshop tomorrow.
On Tue, 24 Oct 2017 18:21:43 +0100 Andre Przywara andre.przywara@arm.com wrote:
Hi,
On 24/10/17 18:05, Dennis Gilmore wrote:
El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió:
On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote:
El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió:
On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 14:24, Maxime Ripard wrote: > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara > wrote: >> Hi, >> >> On 19/10/17 09:26, Maxime Ripard wrote: >>> Hi, >>> >>> Most featureful boards, such as the Cubietruck, have been >>> broken since >>> the release 2017.09. >>> >>> This is due to a size increase of the binary that will >>> trip >>> us across >>> the size we've been using in the u-boot-sunxi-with- >>> spl.bin >>> file. >>> >>> We would have two ways to work around it. The first one >>> would >>> be to >>> just increase the offset of the environment. However, >>> since >>> it would >>> break all the environments of our users and possibly the >>> custom >>> partition scheme that they would have created, it doesn't >>> really seem >>> like a smart move. >> >> Is that really such a problem? How many people rely on >> having >> their >> custom environment preserved over an update? (That's an >> honest >> question) > > All of them, I guess. In your U-boot upgrade script, do you > do a > 'env > default -a; saveenv' all the time ? > > I know I don't.
Well, I never use the saved environment and always expected some user or board specific environment to come from some file (boot.scr or something loaded via TFTP). But that's just my personal use, hence I was asking.
Well, even if you want to boot to tftp, you'll need to have some setup to do, even just to use a different server IP, and that will be in the environment.
I personally just use pxe boot
It's not really about what personally you use, but what any user can use.
Not saying that it is. but how I use it is really simple for the user to use without needing to have a ton of specific knowledge about how u- boot works
dhcp pxe get pxe boot and pick the right option. nothing needed on the client side.
It has the assumption that the DHCP server is setup properly, which might or might not be the case, especially when it comes to the server option being there and valid.
Maxime
Anyone doing something like this on X86 has to have the same setup. its not that hard of a ask to assume that a pxe environment is available. you can skip the dhcp part and set the serrver ip and system ip manually, its just simpler to use dhcp
I agree to both of you ;-) As Maxime already pointed out, it's a bit of a pointless discussion, as x U-Boot users have possibly x different usage scenarios. Some very actively do work on the U-Boot prompt and rely on a customized and preserved environment, while others merely rely on some standardized boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI.
That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly.
Even without Thumb2 we still can reduce footprint by taking advantage of compression for the main U-Boot binary. For this purpose we can use at least LZO because the decompressor code is really small (was it 200-300 bytes?) and still can fit in SPL. A more sophisticated approach can involve attaching the decompressor code to the main U-Boot binary itself.
To be honest, I actually expected the size overflow problem to eventually happen for the SPL, resulting in a proposal of a similar radical feature chopping "solution". And when shit actually hits the fan, I will submit an LZO/UCL runtime decompression patch for the SPL, which can save the day :-) I have already mentioned this a few times in the past and it is our strategic reserve. The size overflow for the main U-Boot binary was a bit of surprise to me, but we still have it under control.
Also as already discussed in this thread, we can just move the location of the environment to reserve more space for the main U-Boot binary (yes, handling the smooth environment location move during U-Boot upgrade will be a bit tricky, but still doable if anyone is really up to it).
And I believe that the arm64 boards mostly use a standardized way of booting, also are much less wide spread, so the number of affected users is probably less there.
I don't think that we have any significant number of U-Boot env users on 32-bit sunxi hardware either. For example, we can do a search in the linux-sunxi wiki to compare the usage of environment vs. boot.scr and uEnv.txt:
https://linux-sunxi.org/index.php?search=saveenv https://linux-sunxi.org/index.php?search=boot.scr https://linux-sunxi.org/index.php?search=uenv.txt
Using saveenv is justified only in very rare exceptional cases. They do exist, otherwise Maxime would not have encountered the problem in the first place. But I think that we should encourage Maxime to migrate away from it. I would really like to know a bit more about his use case.
The Linux distributions don't seem to rely on the U-Boot environment (if I understood their feedback correctly). Our tutorials at the linux-sunxi wiki encourage the use of boot.scr since a very long time ago. Anyone is free to deviate from good practices, but they should really know what they are doing and understand that they are expected to take care of their problems themselves.
I am just thinking of whether it's worthwhile to have some transition code, which tries multiple environment locations (first FAT, then MMC, for instance), or even contains code to migrate from one to another.
Ugh. I think that this is a very bad idea. It makes the U-Boot environment handling even more convoluted and dangerous than it is now. I would prefer to keep the U-Boot environment (when its use is justified) tightly coupled with the bootloader itself and always stored on the same boot media. We do have the boot media id passed to us from the boot ROM, so this is pretty much straightforward. Allowing to move the environment to a different media is a recipe for disaster.
Currently boot.scr or uEnv.txt is loaded from FAT or other partitions as part of distro boot. Is this really not enough?
Hi,
On 25/10/17 12:58, Siarhei Siamashka wrote:
On Tue, 24 Oct 2017 18:21:43 +0100 Andre Przywara andre.przywara@arm.com wrote:
.....
That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly.
Even without Thumb2 we still can reduce footprint by taking advantage of compression for the main U-Boot binary. For this purpose we can use at least LZO because the decompressor code is really small (was it 200-300 bytes?) and still can fit in SPL. A more sophisticated approach can involve attaching the decompressor code to the main U-Boot binary itself.
While it's good to know that we have this option for the future, I don't think it's needed right now to solve this particular issue. Because actually it's not a hard architectural limit, just some arbitrary hardcoded limit, which turns out to be too small. And it's actually only a problem when we consider the saved environment to be a crucial feature.
To be honest, I actually expected the size overflow problem to eventually happen for the SPL, resulting in a proposal of a similar radical feature chopping "solution". And when shit actually hits the fan, I will submit an LZO/UCL runtime decompression patch for the SPL, which can save the day :-)
Looking forward to that ;-)
I have already mentioned this a few times in the past and it is our strategic reserve. The size overflow for the main U-Boot binary was a bit of surprise to me, but we still have it under control.
Also as already discussed in this thread, we can just move the location of the environment to reserve more space for the main U-Boot binary (yes, handling the smooth environment location move during U-Boot upgrade will be a bit tricky, but still doable if anyone is really up to it).
So do you propose to migrate the environment during an upgrade process? I like that idea, but don't think we have anything like a standardized "upgrade process" at the moment. And don't have the time to introduce this.
And I believe that the arm64 boards mostly use a standardized way of booting, also are much less wide spread, so the number of affected users is probably less there.
I don't think that we have any significant number of U-Boot env users on 32-bit sunxi hardware either. For example, we can do a search in the linux-sunxi wiki to compare the usage of environment vs. boot.scr and uEnv.txt:
https://linux-sunxi.org/index.php?search=saveenv https://linux-sunxi.org/index.php?search=boot.scr https://linux-sunxi.org/index.php?search=uenv.txt
Using saveenv is justified only in very rare exceptional cases. They do exist, otherwise Maxime would not have encountered the problem in the first place. But I think that we should encourage Maxime to migrate away from it. I would really like to know a bit more about his use case.
As mentioned above, I don't care so much about a saved environment, but I am merely a "user" of U-Boot, so it's not really my call. As long as there is a non-negligible amount of users, we should consider preserving the saved environment.
The Linux distributions don't seem to rely on the U-Boot environment (if I understood their feedback correctly).
That would be an interesting data point to know for sure.
Our tutorials at the linux-sunxi wiki encourage the use of boot.scr since a very long time ago. Anyone is free to deviate from good practices, but they should really know what they are doing and understand that they are expected to take care of their problems themselves.
I am just thinking of whether it's worthwhile to have some transition code, which tries multiple environment locations (first FAT, then MMC, for instance), or even contains code to migrate from one to another.
Ugh. I think that this is a very bad idea. It makes the U-Boot environment handling even more convoluted and dangerous than it is now. I would prefer to keep the U-Boot environment (when its use is justified) tightly coupled with the bootloader itself and always stored on the same boot media. We do have the boot media id passed to us from the boot ROM, so this is pretty much straightforward.
But this is not how it works at the moment for sunxi (or U-Boot in general), is it? I think we have ENV_IS_IN_MMC defined for sunxi, so we don't access the environment in SPI flash, should we boot from there, for instance (not talking about the missing SPI driver here for now). And how I understand the code this environment location is hardcoded at compile time, so does not take the actual boot source into account? Or does this somehow work with NAND, for instance? Or eMMC vs. SD card?
Allowing to move the environment to a different media is a recipe for disaster.
Why so? I see that it's not very pretty, but I consider this a user friendly solution to some technical problem we need to solve. Maybe we can actually clean up the U-Boot environment code on the way?
Currently boot.scr or uEnv.txt is loaded from FAT or other partitions as part of distro boot. Is this really not enough?
From my point of view: yes. But Maxime strongly hinted that other people
might disagree.
Cheers, Andre.
On Wed, Oct 25, 2017 at 02:58:44PM +0300, Siarhei Siamashka wrote:
On Tue, 24 Oct 2017 18:21:43 +0100 Andre Przywara andre.przywara@arm.com wrote:
Hi,
On 24/10/17 18:05, Dennis Gilmore wrote:
El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió:
On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote:
El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió:
On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > Hi, > > On 19/10/17 14:24, Maxime Ripard wrote: >> On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara >> wrote: >>> Hi, >>> >>> On 19/10/17 09:26, Maxime Ripard wrote: >>>> Hi, >>>> >>>> Most featureful boards, such as the Cubietruck, have been >>>> broken since >>>> the release 2017.09. >>>> >>>> This is due to a size increase of the binary that will >>>> trip >>>> us across >>>> the size we've been using in the u-boot-sunxi-with- >>>> spl.bin >>>> file. >>>> >>>> We would have two ways to work around it. The first one >>>> would >>>> be to >>>> just increase the offset of the environment. However, >>>> since >>>> it would >>>> break all the environments of our users and possibly the >>>> custom >>>> partition scheme that they would have created, it doesn't >>>> really seem >>>> like a smart move. >>> >>> Is that really such a problem? How many people rely on >>> having >>> their >>> custom environment preserved over an update? (That's an >>> honest >>> question) >> >> All of them, I guess. In your U-boot upgrade script, do you >> do a >> 'env >> default -a; saveenv' all the time ? >> >> I know I don't. > > Well, I never use the saved environment and always expected > some > user or > board specific environment to come from some file (boot.scr or > something > loaded via TFTP). But that's just my personal use, hence I was > asking.
Well, even if you want to boot to tftp, you'll need to have some setup to do, even just to use a different server IP, and that will be in the environment.
I personally just use pxe boot
It's not really about what personally you use, but what any user can use.
Not saying that it is. but how I use it is really simple for the user to use without needing to have a ton of specific knowledge about how u- boot works
dhcp pxe get pxe boot and pick the right option. nothing needed on the client side.
It has the assumption that the DHCP server is setup properly, which might or might not be the case, especially when it comes to the server option being there and valid.
Maxime
Anyone doing something like this on X86 has to have the same setup. its not that hard of a ask to assume that a pxe environment is available. you can skip the dhcp part and set the serrver ip and system ip manually, its just simpler to use dhcp
I agree to both of you ;-) As Maxime already pointed out, it's a bit of a pointless discussion, as x U-Boot users have possibly x different usage scenarios. Some very actively do work on the U-Boot prompt and rely on a customized and preserved environment, while others merely rely on some standardized boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI.
That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly.
Even without Thumb2 we still can reduce footprint by taking advantage of compression for the main U-Boot binary. For this purpose we can use at least LZO because the decompressor code is really small (was it 200-300 bytes?) and still can fit in SPL. A more sophisticated approach can involve attaching the decompressor code to the main U-Boot binary itself.
To be honest, I actually expected the size overflow problem to eventually happen for the SPL, resulting in a proposal of a similar radical feature chopping "solution". And when shit actually hits the fan, I will submit an LZO/UCL runtime decompression patch for the SPL, which can save the day :-) I have already mentioned this a few times in the past and it is our strategic reserve. The size overflow for the main U-Boot binary was a bit of surprise to me, but we still have it under control.
Would you mind posting the runtime decompression part? We have other platforms that are already stuck due to small size limits and something like this might finally un-block them. Thanks!
Hi Siarhei,
On Wed, Oct 25, 2017 at 02:58:44PM +0300, Siarhei Siamashka wrote:
Anyone doing something like this on X86 has to have the same setup. its not that hard of a ask to assume that a pxe environment is available. you can skip the dhcp part and set the serrver ip and system ip manually, its just simpler to use dhcp
I agree to both of you ;-) As Maxime already pointed out, it's a bit of a pointless discussion, as x U-Boot users have possibly x different usage scenarios. Some very actively do work on the U-Boot prompt and rely on a customized and preserved environment, while others merely rely on some standardized boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI.
That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly.
Even without Thumb2 we still can reduce footprint by taking advantage of compression for the main U-Boot binary. For this purpose we can use at least LZO because the decompressor code is really small (was it 200-300 bytes?) and still can fit in SPL. A more sophisticated approach can involve attaching the decompressor code to the main U-Boot binary itself.
To be honest, I actually expected the size overflow problem to eventually happen for the SPL, resulting in a proposal of a similar radical feature chopping "solution". And when shit actually hits the fan, I will submit an LZO/UCL runtime decompression patch for the SPL, which can save the day :-) I have already mentioned this a few times in the past and it is our strategic reserve. The size overflow for the main U-Boot binary was a bit of surprise to me, but we still have it under control.
I guess one of the reason is that we pretty much have a fixed set of features in the SPL, and there's nothing really missing either, so the size isn't changing that much. The U-Boot binary however gains new features on a regular basis, each of them increasing slightly the binary size. But yeah, that's definitely one of the things we can do :)
Also as already discussed in this thread, we can just move the location of the environment to reserve more space for the main U-Boot binary (yes, handling the smooth environment location move during U-Boot upgrade will be a bit tricky, but still doable if anyone is really up to it).
I've sent a (rather dumb) attempt earlier today as an RFC.
And I believe that the arm64 boards mostly use a standardized way of booting, also are much less wide spread, so the number of affected users is probably less there.
I don't think that we have any significant number of U-Boot env users on 32-bit sunxi hardware either. For example, we can do a search in the linux-sunxi wiki to compare the usage of environment vs. boot.scr and uEnv.txt:
https://linux-sunxi.org/index.php?search=saveenv https://linux-sunxi.org/index.php?search=boot.scr https://linux-sunxi.org/index.php?search=uenv.txt
Using saveenv is justified only in very rare exceptional cases. They do exist, otherwise Maxime would not have encountered the problem in the first place. But I think that we should encourage Maxime to migrate away from it. I would really like to know a bit more about his use case.
There's several of them actually.
For example, if fast boot (as in booting fast, not the Android stuff) is something you need, the distro bootcmd is not an option. Only the preboot command that initialize USB will take more time than needed to boot your whole system.
The other one is for upgrade mechanism such as Mender.io that will need some changes (and access) to the U-Boot environment to do A-B style upgrades.
The Linux distributions don't seem to rely on the U-Boot environment (if I understood their feedback correctly). Our tutorials at the linux-sunxi wiki encourage the use of boot.scr since a very long time ago. Anyone is free to deviate from good practices, but they should really know what they are doing and understand that they are expected to take care of their problems themselves.
I am just thinking of whether it's worthwhile to have some transition code, which tries multiple environment locations (first FAT, then MMC, for instance), or even contains code to migrate from one to another.
Ugh. I think that this is a very bad idea. It makes the U-Boot environment handling even more convoluted and dangerous than it is now. I would prefer to keep the U-Boot environment (when its use is justified) tightly coupled with the bootloader itself and always stored on the same boot media. We do have the boot media id passed to us from the boot ROM, so this is pretty much straightforward. Allowing to move the environment to a different media is a recipe for disaster.
I think Andre's point was only about storing the environment at different locations, but on the same media.
Maxime
El jue, 19-10-2017 a las 15:24 +0200, Maxime Ripard escribió:
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote:
Hi,
On 19/10/17 09:26, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question)
All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ?
I know I don't.
I personally do not do anything to the environment ever if I can help it. I rely on u-boot having the smarts to just do the right thing and boot my system for me. if the environment moves, as I use the defaults it will just continue to work.
Dennis
On Thu, Oct 19, 2017 at 10:26:46AM +0200, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
So, where is the over-run exactly? We have CONFIG_SPL_MAX_SIZE to ensure that we have SPL fitting within constraints. For U-Boot itself we don't have a generic check but it's usually done with a custom linker script (which could in turn just #include the regular one I think).
On Thu, Oct 19, 2017 at 09:28:03AM -0400, Tom Rini wrote:
On Thu, Oct 19, 2017 at 10:26:46AM +0200, Maxime Ripard wrote:
Hi,
Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.
This is due to a size increase of the binary that will trip us across the size we've been using in the u-boot-sunxi-with-spl.bin file.
We would have two ways to work around it. The first one would be to just increase the offset of the environment. However, since it would break all the environments of our users and possibly the custom partition scheme that they would have created, it doesn't really seem like a smart move.
Another one would be to start trimming down a bit our enabled options in order to reduce the size and to gain some extra space for users customisations. I've taken care some of the low hanging fruits, and we should probably take another go at it in the future (and add a size check in the image build somehow?)
So, where is the over-run exactly? We have CONFIG_SPL_MAX_SIZE to ensure that we have SPL fitting within constraints. For U-Boot itself we don't have a generic check but it's usually done with a custom linker script (which could in turn just #include the regular one I think).
The overlap is between the end of the U-Boot binary (so SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR in this case + U-Boot size) and ENV_OFFSET.
I've been able to add a check in the u-boot-sunxi-with-spl.bin for the size, but I guess we could have something generic as well. This seems to not be very trivial to do though, since some offsets (ENV_OFFSET) are in bytes, and some other in storage units (SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR in blocks, SYS_SPI_U_BOOT_OFFS and SYS_NAND_U_BOOT_OFFS in bytes), and then some other are just booting from a partition and we can't really do anything there.
I'll send the patches, let's start the discussion from there.
Maxime
participants (12)
-
Alexander Graf -
Andre Przywara -
Dennis Gilmore -
Heinrich Schuchardt -
Jagan Teki -
Jonathan Gray -
Mark Kettenis -
Maxime Ripard -
Peter Robinson -
Rob Clark -
Siarhei Siamashka -
Tom Rini