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