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