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