sunxi: Fix boot of Cubietruk and al.

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 <[email protected]>

Quoted 3 lines · Maxime Ripard

The USB keyboard and USB storage support are non-essential from an architecture-wide sense.

Quoted 4 lines

Remove the selection so that we can trim down the size of our binaries a bit.

Signed-off-by Maxime Ripard <[email protected]>

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.

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.

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 <[email protected]>

---
 arch/arm/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

arch/arm/Kconfig +0 -4

index 64e0ee43f112..0eaf54bd8ddb 100644
@@ -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 at lists.denx.de
https://lists.denx.de/listinfo/u-boot

From: Maxime Ripard <[email protected]>
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.

Signed-off-by Maxime Ripard <[email protected]>

---
 arch/arm/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

arch/arm/Kconfig +0 -3

index 64e0ee43f112..0eaf54bd8ddb 100644
@@ -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

Signature · 6 lines

2.14.2

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

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 <[email protected]>

---
 lib/efi_loader/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

lib/efi_loader/Kconfig +1 -2

index d2b6327119b4..a80a914b2fe8 100644
@@ -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 at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Quoted 3 lines · Maxime Ripard

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.

Quoted 2 lines

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.

Quoted 8 lines · Peter Robinson

Quoted 5 lines · Maxime Ripard

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.

Quoted 4 lines

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.

Quoted 14 lines · Maxime Ripard

Quoted 12 lines · Peter Robinson

Quoted 5 lines · Maxime Ripard

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.

Quoted 3 lines

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.

Quoted 20 lines · Peter Robinson

Quoted 17 lines · Maxime Ripard

Quoted 5 lines · Peter Robinson

Quoted 3 lines · Maxime Ripard

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 3 lines

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"

Quoted 25 lines · Peter Robinson

Quoted 23 lines · Peter Robinson

Quoted 9 lines · Maxime Ripard

Quoted 8 lines · Peter Robinson

Quoted 5 lines · Maxime Ripard

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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 2 lines

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?

Quoted 5 lines

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.

Quoted 3 lines

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 at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Quoted 29 lines · Maxime Ripard

Quoted 27 lines · Peter Robinson

Quoted 16 lines · Peter Robinson

Quoted 14 lines · Maxime Ripard

Quoted 12 lines · Peter Robinson

Quoted 5 lines · Maxime Ripard

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 34 lines · Rob Clark

Quoted 31 lines · Maxime Ripard

Quoted 21 lines · Peter Robinson

Quoted 20 lines · Peter Robinson

Quoted 17 lines · Maxime Ripard

Quoted 5 lines · Peter Robinson

Quoted 3 lines · Maxime Ripard

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 6 lines

Quoted 3 lines

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?

Quoted 3 lines

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?

Quoted 3 lines

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.

Quoted 7 lines

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

Quoted 39 lines · Maxime Ripard

Quoted 37 lines · Rob Clark

Quoted 26 lines · Maxime Ripard

Quoted 25 lines · Peter Robinson

Quoted 23 lines · Peter Robinson

Quoted 9 lines · Maxime Ripard

Quoted 8 lines · Peter Robinson

Quoted 5 lines · Maxime Ripard

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.

Quoted 8 lines

Quoted 4 lines

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 3 lines

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!

Quoted 45 lines · Peter Robinson

Quoted 42 lines · Maxime Ripard

Quoted 31 lines · Rob Clark

Quoted 29 lines · Maxime Ripard

Quoted 27 lines · Peter Robinson

Quoted 16 lines · Peter Robinson

Quoted 14 lines · Maxime Ripard

Quoted 12 lines · Peter Robinson

Quoted 5 lines · Maxime Ripard

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 3 lines

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?

Quoted 15 lines

Quoted 14 lines

Quoted 10 lines

Quoted 6 lines

Quoted 2 lines

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!

Quoted 3 lines

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.

Quoted 15 lines · Tom Rini

Quoted 15 lines

Quoted 14 lines

Quoted 10 lines

Quoted 6 lines

Quoted 2 lines

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!

Quoted 7 lines

Quoted 3 lines

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?

Quoted 15 lines · Tom Rini

Quoted 15 lines

Quoted 14 lines

Quoted 10 lines

Quoted 6 lines

Quoted 2 lines

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!

Quoted 7 lines

Quoted 3 lines

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?

Quoted 45 lines · Peter Robinson

Quoted 42 lines · Maxime Ripard

Quoted 31 lines · Rob Clark

Quoted 29 lines · Maxime Ripard

Quoted 27 lines · Peter Robinson

Quoted 16 lines · Peter Robinson

Quoted 14 lines · Maxime Ripard

Quoted 12 lines · Peter Robinson

Quoted 5 lines · Maxime Ripard

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 6 lines

Quoted 2 lines

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?

Quoted 3 lines

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?

Quoted 14 lines · Maxime Ripard

Quoted 12 lines · Peter Robinson

Quoted 5 lines · Maxime Ripard

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.

Quoted 3 lines

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.

Quoted 5 lines · Maxime Ripard

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

Quoted 21 lines

Signed-off-by Maxime Ripard <[email protected]>

---
 lib/efi_loader/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

lib/efi_loader/Kconfig +1 -2

index d2b6327119b4..a80a914b2fe8 100644
@@ -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

Quoted 4 lines

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

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 <[email protected]>

---
  lib/efi_loader/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

lib/efi_loader/Kconfig +0 -0

index d2b6327119b4..a80a914b2fe8 100644

Quoted 3 lines · Maxime Ripard

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.

Quoted 4 lines

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 <[email protected]>

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.

Quoted 10 lines

---
  lib/efi_loader/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

lib/efi_loader/Kconfig +0 -0

index d2b6327119b4..a80a914b2fe8 100644

lib/efi_loader/Kconfig line 4

Quoted 5 lines

lib/efi_loader/Kconfig +1 -1

@@ -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 at lists.denx.de
https://lists.denx.de/listinfo/u-boot

lib/efi_loader/Kconfig line 4

Quoted 13 lines

  lib/efi_loader/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

lib/efi_loader/Kconfig +1 -1

index d2b6327119b4..a80a914b2fe8 100644
@@ -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.

From: Maxime Ripard <[email protected]>
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.

Signed-off-by Maxime Ripard <[email protected]>

---
 lib/efi_loader/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

lib/efi_loader/Kconfig +1 -1

index d2b6327119b4..a80a914b2fe8 100644
@@ -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

Signature · 6 lines

2.14.2

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
https://lists.denx.de/listinfo/u-boot

Quoted 6 lines

From: Maxime Ripard <[email protected]>
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.

Quoted 2 lines

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

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 <[email protected]>

---
 lib/efi_loader/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

lib/efi_loader/Kconfig +0 -0

index d2b6327119b4..a80a914b2fe8 100644

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?)

Quoted 14 lines · Maxime Ripard

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.

Quoted 5 lines

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?

Quoted 20 lines · Alexander Graf

Quoted 19 lines · Maxime Ripard

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?)

Quoted 3 lines

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.

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(-)

Quoted 22 lines · Maxime Ripard

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

Quoted 8 lines

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

Quoted 22 lines · Maxime Ripard

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

Quoted 8 lines

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

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(-)

Hi,

Quoted 8 lines · Maxime Ripard

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.

Quoted 5 lines

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.

Quoted 11 lines · Andre Przywara

Hi,

Quoted 8 lines · Maxime Ripard

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.

Quoted 8 lines

Quoted 5 lines

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.

Quoted 2 lines

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.

Quoted 17 lines · Andre Przywara

Hi,

Quoted 13 lines · Maxime Ripard

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.

Quoted 2 lines

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.

Quoted 2 lines

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.

Quoted 3 lines

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?

Quoted 6 lines

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.

Hi,

Quoted 21 lines · Maxime Ripard

Quoted 19 lines · Andre Przywara

Hi,

Quoted 5 lines · Maxime Ripard

Hi,

Most featureful boards, such as the Cubietruck, have been broken since the release 2017.09.

Quoted 8 lines

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)

Quoted 4 lines

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

Quoted 2 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

Quoted 7 lines

Quoted 6 lines

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.

Quoted 4 lines

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?

Quoted 3 lines

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?

Quoted 37 lines

Hi,

Quoted 34 lines · Maxime Ripard

Quoted 24 lines · Andre Przywara

Hi,

Quoted 11 lines · Maxime Ripard

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.

Quoted 9 lines

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.

Quoted 4 lines

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 ?

Quoted 8 lines

Quoted 1 line

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.

El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió:

Quoted 47 lines · Andre Przywara

Quoted 45 lines

Hi,

Quoted 30 lines · Maxime Ripard

Quoted 24 lines · Andre Przywara

Hi,

Quoted 11 lines · Maxime Ripard

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.

Quoted 9 lines

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.

Quoted 4 lines

Is that really such a problem? How many people rely on having their
custom environment preserved over an update? (That's an honest question)

Quoted 5 lines

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.

Quoted 5 lines

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.

Quoted 64 lines · Dennis Gilmore

Quoted 62 lines · Maxime Ripard

Quoted 47 lines · Andre Przywara

Hi,

Quoted 37 lines · Maxime Ripard

Quoted 28 lines · Andre Przywara

Hi,

Quoted 13 lines · Maxime Ripard

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.

Quoted 11 lines

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.

Quoted 6 lines

Is that really such a problem? How many people rely on having
their
custom environment preserved over an update? (That's an honest
question)

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 1 line

I personally just use pxe boot

It's not really about what personally you use, but what any user can use.

Quoted 4 lines

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

Quoted 65 lines · Maxime Ripard

Quoted 64 lines · Dennis Gilmore

Quoted 62 lines · Maxime Ripard

Quoted 47 lines · Andre Przywara

Hi,

Quoted 37 lines · Maxime Ripard

Quoted 28 lines · Andre Przywara

Hi,

Quoted 13 lines · Maxime Ripard

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.

Quoted 11 lines

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.

Quoted 6 lines

Is that really such a problem? How many people rely on having
their
custom environment preserved over an update? (That's an honest
question)

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 4 lines

Quoted 1 line

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

Quoted 10 lines

Quoted 4 lines

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.

Quoted 1 line

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

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.

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

Quoted 9 lines · Andre Przywara

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.

Hi,

Quoted 84 lines · Dennis Gilmore

Quoted 65 lines · Maxime Ripard

Quoted 64 lines · Dennis Gilmore

Quoted 62 lines · Maxime Ripard

Quoted 47 lines · Andre Przywara

Hi,

Quoted 37 lines · Maxime Ripard

Quoted 28 lines · Andre Przywara

Hi,

Quoted 13 lines · Maxime Ripard

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.

Quoted 11 lines

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.

Quoted 6 lines

Is that really such a problem? How many people rely on having
their
custom environment preserved over an update? (That's an honest
question)

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 4 lines

Quoted 1 line

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

Quoted 10 lines

Quoted 4 lines

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.

Quoted 5 lines

Quoted 1 line

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.

On Tue, 24 Oct 2017 18:21:43 +0100
Andre Przywara <[email protected]> wrote:

Quoted 4 lines

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

Quoted 3 lines

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.

Quoted 3 lines

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?

[CCing Vagrant Cascadian, the Debian U-Boot maintainer]

Quoted 8 lines · Andre Przywara

Quoted 7 lines · Siarhei Siamashka

Quoted 5 lines · On Tue, 24 Oct 2017 18:21:43 +0100 Andre Przywara <[email protected]>…

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.

[...]

Quoted 12 lines

Quoted 12 lines

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

Quoted 8 lines

Quoted 8 lines

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.

Hello,

I cannot speak for Maxime, but from a distro point of view there are at
least two common usecases:

a) Changing the default boot order

At least among Debian users it is not uncommon to run the installer from an SD-card (Debian provides SD-card images with u-boot and the Debian installer) and install the distro to a harddisk (especially on the A20 where native SATA is available). The default boot order is MMC before SATA and USB, i.e. after installing to SATA or USB, the user must change the boot order by setting the boot_targets variable accordingly and saving it into the persistent environment, because otherwise the system would reboot into the installer on the SD card all the time instead of booting the installed system. Removing the SD card isn't an option because then there wouldn't be any (mainline) u-boot anymore.

This isn't a problem when installing to the SD-card from which the installer was loaded as the SD-card gets repartitioned and the installer is overwritten in that case.

b) Changing the default console device

The Debian boot.scr passes the contents of the u-boot console variable to the kernel as the system console device. All sunxi-based systems default to serial console, but there are quite a number of users that don't have a serial console cable but instead run their console on HDMI. They change their system console by setting the u-boot "console" variable accordingly and running saveenv. This works as u-boot runs its own console both on serial and simplefb in parallel, while the Linux kernel can only have one system console device at a time.

Quoted 7 lines

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.

Quoted 5 lines

Quoted 3 lines

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.

Please see above :-).

Quoted 2 lines

Quoted 2 lines

Currently boot.scr or uEnv.txt is loaded from FAT or other partitions as part of distro boot. Is this really not enough?

In Debian's case it is "other partitions". Debian doesn't create any FAT partitions on non-UEFI systems. The /boot partition is ext2 and for the other partitions ext4 is the default filesystem. Therefore forcing the environment onto a FAT partition would surely cause problems when upgrading an existing system to a newer u-boot version.

uEnv.txt is AFAICS not used by mainline u-boot at all, at least on sunxi-based systems.

Quoted 100 lines · On Tue, 24 Oct 2017 18:21:43 +0100 Andre Przywara <[email protected]>…

Hi,

Quoted 84 lines · Dennis Gilmore

Quoted 65 lines · Maxime Ripard

Quoted 64 lines · Dennis Gilmore

Quoted 62 lines · Maxime Ripard

Quoted 47 lines · Andre Przywara

Hi,

Quoted 37 lines · Maxime Ripard

Quoted 28 lines · Andre Przywara

Hi,

Quoted 13 lines · Maxime Ripard

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.

Quoted 11 lines

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.

Quoted 6 lines

Is that really such a problem? How many people rely on having
their
custom environment preserved over an update? (That's an honest
question)

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 4 lines

Quoted 1 line

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

Quoted 10 lines

Quoted 4 lines

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.

Quoted 5 lines

Quoted 1 line

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.

Quoted 3 lines

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.

Quoted 12 lines

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 22 lines

Hi,

Quoted 18 lines · Maxime Ripard

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.

Quoted 3 lines

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.

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?)

Quoted 14 lines · Maxime Ripard

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.

Quoted 5 lines

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