[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[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

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

-- 
2.14.2

[U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Maxime Ripard]

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

[U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Alexander Graf]

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

[U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Andre Przywara]

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.

[U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Maxime Ripard]

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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/602df51e/attachment.sig>

[U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Peter Robinson]

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

[U-Boot] [PATCH 1/3] ARM: sunxi: Disable USB host options by default

[Mark Kettenis]

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

[U-Boot] [PATCH 2/3] ARM: sunxi: Disable FAT write by default

[Maxime Ripard]

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

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

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

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] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Peter Robinson]

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

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> > trip across the size limit we've had on the U-Boot binary.
> >
> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> > so that we get back some extra room for user customisations.
> 
> Does this disable it on aarch64 boards by default such as the Pine64?
> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> boot aarch64 devices and this would regress this for all those
> distros.

This is something that Fedora, Suse and I'm pretty sure Debian can add
to their defconfig. These are just default configuration, not
one-size-fits-all configuration.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/d5953a5a/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Peter Robinson]

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.

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Peter Robinson]

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"

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote:
> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
> >>> <maxime.ripard@free-electrons.com> wrote:
> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> >>> > trip across the size limit we've had on the U-Boot binary.
> >>> >
> >>> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> >>> > so that we get back some extra room for user customisations.
> >>>
> >>> Does this disable it on aarch64 boards by default such as the Pine64?
> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> >>> boot aarch64 devices and this would regress this for all those
> >>> distros.
> >>
> >> This is something that Fedora, Suse and I'm pretty sure Debian can add
> >> to their defconfig. These are just default configuration, not
> >> one-size-fits-all configuration.
> >
> > So you're making at least three groups of users do more work? It could
> > also be argued that those that need the smaller space could disable it
> > if they don't need it in their configuration.
> 
> Ultimately the problem with the argument about disabling it by default
> and distros can enable it if they want to is a false one.

If it's a false one, then I guess Red Hat doesn't have any kind of
custom defconfigs for Fedora or RHEL for the kernel?

> By enabling it by default we have devices that ship with SPI or NAND
> flash, like a bunch of the OrangePis do now, be able to work with
> all distributions out of the box without any requirements of distros
> to produce a firmware (something I'd really prefer to leave to the
> device makers) to boot a number of Linux OSes OOTB.

That one is the false argument in the discussion. No vendor is
providing such a U-Boot, all of them provide a vendor one that will
not even be able to boot a mainline kernel, let alone supporting
EFI. So having something that works out of the box is just a pipe
dream.

> I think this is a good thing for the entire ecosystem. I don't want
> to regress that, I'd sooner get the size checks in place and then
> review rather than what seems like a "quick win"

I've added a size check. 3 boards are broken:
  - A20-OLinuXino-Lime2-eMMC
  - A20-OLinuXino-Lime2
  - Cubietruck

What now?
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/ae058949/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Rob Clark]

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

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote:
> On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote:
> >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
> >> > <maxime.ripard@free-electrons.com> wrote:
> >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
> >> >>> <maxime.ripard@free-electrons.com> wrote:
> >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> >> >>> > trip across the size limit we've had on the U-Boot binary.
> >> >>> >
> >> >>> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> >> >>> > so that we get back some extra room for user customisations.
> >> >>>
> >> >>> Does this disable it on aarch64 boards by default such as the Pine64?
> >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> >> >>> boot aarch64 devices and this would regress this for all those
> >> >>> distros.
> >> >>
> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can add
> >> >> to their defconfig. These are just default configuration, not
> >> >> one-size-fits-all configuration.
> >> >
> >> > So you're making at least three groups of users do more work? It could
> >> > also be argued that those that need the smaller space could disable it
> >> > if they don't need it in their configuration.
> >>
> >> Ultimately the problem with the argument about disabling it by default
> >> and distros can enable it if they want to is a false one.
> >
> > If it's a false one, then I guess Red Hat doesn't have any kind of
> > custom defconfigs for Fedora or RHEL for the kernel?
> 
> kernel is part of the distro, "firmware" (ie. u-boot or whatever
> implements UEFI) should not be.. so this argument is a bit of a red
> herring.

Then that discussion is entirely moot. If the distros don't care about
building the U-Boot binary, why should they care about maintaining the
U-Boot's defconfig like Peter was suggesting?

> Maybe the solution is a "distro.config" option to separate options
> that make sense for distro/EBBR from what people who are doing more
> non-standard boot-chains are wanting.

It's kind of amazing to see that the usual boot-chain that people have
been relying on for more than a decade and is still in use in the
immense majority of devices can be seen as "non-standard". But I guess
that's a different topic.

> For example, for UEFI boot, we can disable all the filesystems other
> than FAT if you need to trim some space.  And maybe doing a more
> simplified (ie. add it to efi_bootmgr.c) alternative to distro
> bootcmd could save a bunch of .text space.  In fact we don't really
> need the scripting env at all.  Probably there are other options for
> things to disable that I haven't thought of if you *really* needed
> to trim down.

That's good to know. Hopefully we won't need to trim that space since
we got a bit more room to spare by switching to thumb, and if we can
move to a filesystem based environment, we won't ever need it.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171020/b76d4870/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Peter Robinson]

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

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Fri, Oct 20, 2017 at 01:27:36PM +0100, Peter Robinson wrote:
> On Fri, Oct 20, 2017 at 8:20 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote:
> >> On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >> > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote:
> >> >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
> >> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
> >> >> > <maxime.ripard@free-electrons.com> wrote:
> >> >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> >> >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
> >> >> >>> <maxime.ripard@free-electrons.com> wrote:
> >> >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> >> >> >>> > trip across the size limit we've had on the U-Boot binary.
> >> >> >>> >
> >> >> >>> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> >> >> >>> > so that we get back some extra room for user customisations.
> >> >> >>>
> >> >> >>> Does this disable it on aarch64 boards by default such as the Pine64?
> >> >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> >> >> >>> boot aarch64 devices and this would regress this for all those
> >> >> >>> distros.
> >> >> >>
> >> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can add
> >> >> >> to their defconfig. These are just default configuration, not
> >> >> >> one-size-fits-all configuration.
> >> >> >
> >> >> > So you're making at least three groups of users do more work? It could
> >> >> > also be argued that those that need the smaller space could disable it
> >> >> > if they don't need it in their configuration.
> >> >>
> >> >> Ultimately the problem with the argument about disabling it by default
> >> >> and distros can enable it if they want to is a false one.
> >> >
> >> > If it's a false one, then I guess Red Hat doesn't have any kind of
> >> > custom defconfigs for Fedora or RHEL for the kernel?
> >>
> >> kernel is part of the distro, "firmware" (ie. u-boot or whatever
> >> implements UEFI) should not be.. so this argument is a bit of a red
> >> herring.
> >
> > Then that discussion is entirely moot. If the distros don't care about
> > building the U-Boot binary, why should they care about maintaining the
> > U-Boot's defconfig like Peter was suggesting?
> 
> You're taking that and turning it around wrong, we currently have to
> care about building it. Ultimately what we'd like is to not have to
> care. One is the current status quo, the other is future desire!

Then we're back to the previous question you didn't answer. If you
have to build it, why can't you have a custom defconfig, or a
configuration fragment like Rob suggested, like you do for the kernel?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171020/fb430c2b/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Tom Rini]

On Fri, Oct 20, 2017 at 02:36:27PM +0200, Maxime Ripard wrote:
> On Fri, Oct 20, 2017 at 01:27:36PM +0100, Peter Robinson wrote:
> > On Fri, Oct 20, 2017 at 8:20 AM, Maxime Ripard
> > <maxime.ripard@free-electrons.com> wrote:
> > > On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote:
> > >> On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard
> > >> <maxime.ripard@free-electrons.com> wrote:
> > >> > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote:
> > >> >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson <pbrobinson@gmail.com> wrote:
> > >> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
> > >> >> > <maxime.ripard@free-electrons.com> wrote:
> > >> >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> > >> >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
> > >> >> >>> <maxime.ripard@free-electrons.com> wrote:
> > >> >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> > >> >> >>> > trip across the size limit we've had on the U-Boot binary.
> > >> >> >>> >
> > >> >> >>> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> > >> >> >>> > so that we get back some extra room for user customisations.
> > >> >> >>>
> > >> >> >>> Does this disable it on aarch64 boards by default such as the Pine64?
> > >> >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> > >> >> >>> boot aarch64 devices and this would regress this for all those
> > >> >> >>> distros.
> > >> >> >>
> > >> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can add
> > >> >> >> to their defconfig. These are just default configuration, not
> > >> >> >> one-size-fits-all configuration.
> > >> >> >
> > >> >> > So you're making at least three groups of users do more work? It could
> > >> >> > also be argued that those that need the smaller space could disable it
> > >> >> > if they don't need it in their configuration.
> > >> >>
> > >> >> Ultimately the problem with the argument about disabling it by default
> > >> >> and distros can enable it if they want to is a false one.
> > >> >
> > >> > If it's a false one, then I guess Red Hat doesn't have any kind of
> > >> > custom defconfigs for Fedora or RHEL for the kernel?
> > >>
> > >> kernel is part of the distro, "firmware" (ie. u-boot or whatever
> > >> implements UEFI) should not be.. so this argument is a bit of a red
> > >> herring.
> > >
> > > Then that discussion is entirely moot. If the distros don't care about
> > > building the U-Boot binary, why should they care about maintaining the
> > > U-Boot's defconfig like Peter was suggesting?
> > 
> > You're taking that and turning it around wrong, we currently have to
> > care about building it. Ultimately what we'd like is to not have to
> > care. One is the current status quo, the other is future desire!
> 
> Then we're back to the previous question you didn't answer. If you
> have to build it, why can't you have a custom defconfig, or a
> configuration fragment like Rob suggested, like you do for the kernel?

Because the goal is that boards ship from the manufacturer with a
firmware that's "good enough".  And firmware updates are handled by
Someone Else, rather than the distro.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171020/be9dda90/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Fri, Oct 20, 2017 at 08:54:43AM -0400, Tom Rini wrote:
> > > >> > If it's a false one, then I guess Red Hat doesn't have any kind of
> > > >> > custom defconfigs for Fedora or RHEL for the kernel?
> > > >>
> > > >> kernel is part of the distro, "firmware" (ie. u-boot or whatever
> > > >> implements UEFI) should not be.. so this argument is a bit of a red
> > > >> herring.
> > > >
> > > > Then that discussion is entirely moot. If the distros don't care about
> > > > building the U-Boot binary, why should they care about maintaining the
> > > > U-Boot's defconfig like Peter was suggesting?
> > > 
> > > You're taking that and turning it around wrong, we currently have to
> > > care about building it. Ultimately what we'd like is to not have to
> > > care. One is the current status quo, the other is future desire!
> > 
> > Then we're back to the previous question you didn't answer. If you
> > have to build it, why can't you have a custom defconfig, or a
> > configuration fragment like Rob suggested, like you do for the kernel?
> 
> Because the goal is that boards ship from the manufacturer with a
> firmware that's "good enough".  And firmware updates are handled by
> Someone Else, rather than the distro.

We're talking about a vendor that ships today a U-Boot build that
either doesn't have DT support, or doesn't start the kernel in the
proper execution level which prevents any mainline kernel from
running.

Maybe it's just me being too pessimistic about this, but do you really
expect to see a time where they would ship a bootloader with EFI?

Maxmie

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171020/d33a4436/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Tom Rini]

On Fri, Oct 20, 2017 at 06:39:18PM +0200, Maxime Ripard wrote:
> On Fri, Oct 20, 2017 at 08:54:43AM -0400, Tom Rini wrote:
> > > > >> > If it's a false one, then I guess Red Hat doesn't have any kind of
> > > > >> > custom defconfigs for Fedora or RHEL for the kernel?
> > > > >>
> > > > >> kernel is part of the distro, "firmware" (ie. u-boot or whatever
> > > > >> implements UEFI) should not be.. so this argument is a bit of a red
> > > > >> herring.
> > > > >
> > > > > Then that discussion is entirely moot. If the distros don't care about
> > > > > building the U-Boot binary, why should they care about maintaining the
> > > > > U-Boot's defconfig like Peter was suggesting?
> > > > 
> > > > You're taking that and turning it around wrong, we currently have to
> > > > care about building it. Ultimately what we'd like is to not have to
> > > > care. One is the current status quo, the other is future desire!
> > > 
> > > Then we're back to the previous question you didn't answer. If you
> > > have to build it, why can't you have a custom defconfig, or a
> > > configuration fragment like Rob suggested, like you do for the kernel?
> > 
> > Because the goal is that boards ship from the manufacturer with a
> > firmware that's "good enough".  And firmware updates are handled by
> > Someone Else, rather than the distro.
> 
> We're talking about a vendor that ships today a U-Boot build that
> either doesn't have DT support, or doesn't start the kernel in the
> proper execution level which prevents any mainline kernel from
> running.
> 
> Maybe it's just me being too pessimistic about this, but do you really
> expect to see a time where they would ship a bootloader with EFI?

There's actually a relative lot of vendor stuff that's based on "only"
2 or so year old U-Boot, and starts to get things right.  So yes, once
you start to factor in the design->production lag, we will start to see
more and more devices that come out with these features enabled and
either in-use (because it's relevant to the product) or community-used
(because the product can be end-user-used and it's not something that
was turned off).  And we're starting to see more and wider silicon
vendor support coming in and in my experience there's often a lot of "if
the vendor defaults work, just add what we need on top" in custom
designs.  For the kernel and U-Boot both.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171020/2a72de79/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Peter Robinson]

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.

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Peter Robinson]

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

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 10:06:15AM +0100, Peter Robinson wrote:
> On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote:
> >> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard
> >> <maxime.ripard@free-electrons.com> wrote:
> >> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> >> > trip across the size limit we've had on the U-Boot binary.
> >> >
> >> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> >> > so that we get back some extra room for user customisations.
> >>
> >> Does this disable it on aarch64 boards by default such as the Pine64?
> >> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to
> >> boot aarch64 devices and this would regress this for all those
> >> distros.
> >
> > This is something that Fedora, Suse and I'm pretty sure Debian can add
> > to their defconfig. These are just default configuration, not
> > one-size-fits-all configuration.
> 
> So you're making at least three groups of users do more work? It could
> also be argued that those that need the smaller space could disable it
> if they don't need it in their configuration.

I don't think asking people to modify their default configuration in
order to have U-Boot booting is reasonable, is it?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/95512142/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Heinrich Schuchardt]

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

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Alexander Graf]

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

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Jonathan Gray]

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

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 10:51:04AM +0200, Alexander Graf wrote:
> >   lib/efi_loader/Kconfig | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index d2b6327119b4..a80a914b2fe8 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -1,7 +1,7 @@
> >   config EFI_LOADER
> >   	bool "Support running EFI Applications in U-Boot"
> >   	depends on (ARM || X86) && OF_LIBFDT
> > -	default y
> > +	default y if !ARCH_SUNXI
> 
> Nack on any change to that default line. If you must disable efi_loader (and
> really, I strongly advise not to do so for sunxi), please do so in the
> defconfigs, as nothing prohibits the architecture to work with it.

That's a bit of a separate discussion. We don't want to have too much
churn in the defconfig, as it is basically boilerplate that some will
get wrong, and then you won't have a consistent tool set between
boards, which is also a pain. A pain both to maintain and use if you
want to ship something board agnostic.

However, the preferred way expressed by Tom to change defaults has
been to change those defaults directly in the Kconfig option, instead
of them creeping in everywhere in the arch's or platform Kconfig
files.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/c30e0911/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Mark Kettenis]

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

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Maxime Ripard]

On Thu, Oct 19, 2017 at 01:39:28PM +0200, Mark Kettenis wrote:
> > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> > Date: Thu, 19 Oct 2017 10:26:49 +0200
> > 
> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> > trip across the size limit we've had on the U-Boot binary.
> > 
> > Since it's not an essential feature, disable it by default for ARCH_SUNXI
> > so that we get back some extra room for user customisations.
> 
> This is an essential feature for booting OpenBSD.  And I believe it is
> a requirement for several Linux distros as well.  I don't think
> disabling this by default is a good idea.

I get it, every one wants its old features. We can't have that. Can we
move forward in the discussion?

> How much of that 31kB is due to recent improvements of the EFI loader
> support?  I understand the desire to have a more complete EFI
> implementation, but if the consequence of that is that the EFI loader
> gets disabled by default on many boards I think we're throwing out the
> baby with the bathwater...

Bisection led to a meaningless (as in not relevant to the current
discussion) commit that was just adding a bit of code, and probably
was just tripping over the limit.

So it's basically only a symptom, and it shouldn't prevent any
development from happening.

What I'd like to happen though is a real discussion on why on Earth we
should have all the usecases in the worlds supported in our
defconfigs, especially for distros that will package and build U-Boot
themselves.

Everyone has a custom defconfig for the kernel. What's so different?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/c17c768a/attachment.sig>

[U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi

[Tom Rini]

On Thu, Oct 19, 2017 at 10:26:49AM +0200, Maxime Ripard wrote:

> The EFI loader support takes around 31kB on an ARMv7 board, which makes us
> trip across the size limit we've had on the U-Boot binary.
> 
> Since it's not an essential feature, disable it by default for ARCH_SUNXI
> so that we get back some extra room for user customisations.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  lib/efi_loader/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index d2b6327119b4..a80a914b2fe8 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -1,7 +1,7 @@
>  config EFI_LOADER
>  	bool "Support running EFI Applications in U-Boot"
>  	depends on (ARM || X86) && OF_LIBFDT
> -	default y
> +	default y if !ARCH_SUNXI
>  	help
>  	  Select this option if you want to run EFI applications (like grub2)
>  	  on top of U-Boot. If this option is enabled, U-Boot will expose EFI

I want to speak against this particular option.  "U-Boot boots EFI
application, $distro just works" is a huge deal right now.  As much as I
would have preferred various other things happen at various points in
the past, kicking off an EFI application to boot Linux is huge and
important outside of the embedded space (and ARM Ltd is pushing this
path within the embedded space).  There are cases where we don't want
the EFI loader, but for ARMv7/AArch64 this should be enabled by default
and turned off at the board level for specific use cases.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/e09517c3/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Alexander Graf]

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

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/27397d42/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Alexander Graf]

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

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Siarhei Siamashka]

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

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Tom Rini]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/5dec1bb8/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/92dd9a42/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Andre Przywara]

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

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/75b7f702/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/3452579f/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Andre Przywara]

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.

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/c39d268a/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Dennis Gilmore]

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

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171023/62cd6bbd/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Dennis Gilmore]

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

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Andre Przywara]

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.

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171025/b7c14f58/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Jagan Teki]

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

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171025/78003c43/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Andre Przywara]

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.

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Siarhei Siamashka]

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?

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Andre Przywara]

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.

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Dennis Gilmore]

El mié, 25-10-2017 a las 20:41 +0200, Karsten Merker escribió:
> [CCing Vagrant Cascadian, the Debian U-Boot maintainer]
> 
> On Wed, Oct 25, 2017 at 02:42:50PM +0100, Andre Przywara wrote:
> > 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.
> 
> [...]
> > > 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.
> 
> 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.
This is a bit unfortunate, if only we had spi or some other flash for
stroing u-boot on all the hardware so that vendors could ship something
that just works. wiping out the installer would b an option, but that
is pretty ugly. 

> 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.
u-boot and the linux kernel actually default to displaying to both the
serial console and the HDMI console. the user can intereact with both
at the same time. At least it is true on the sunxi machines I have
tested it on, with zero need to setup any console lines or do anything
special. I suspect that you no longer need to have a boot.scr at all.

> > 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.
> 
> Please see above :-).
> 
> > > 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.

Fedora does not use or support uEnv.txt or boot.scr our disk images
ship with a fat partition at the start so that we can ship the firmware
needed to boot on a raspberry pi, however any 32 bit system installed
using anaconda will not have a fat partition at all. /boot is ext4 and
depeding on if you use server or a different installer you will by
default get xfs or ext4 on lvm, there is the ability to choose
different options. Older disk images before we supported raspberry pi
did not have fat partition at all. so there is likely a lot of machines
without access to afat partition that would break if if it became
required.

Dennis

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171025/f4e82364/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171025/1f4ac28d/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Dennis Gilmore]

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

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Tom Rini]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/0d04668d/attachment.sig>

[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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


-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/9fc632f9/attachment.sig>