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.