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.