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

[Andre Przywara <andre.przywara@arm.com>]

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.