sunxi: Fix boot of Cubietruk and al.
Get series with b4
b4 am 20171025145844.3fe7077a@i7Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.
Quoted 100 lines · On Tue, 24 Oct 2017 18:21:43 +0100 Andre Przywara <[email protected]>…
Hi,
Quoted 84 lines · Dennis Gilmore
Quoted 65 lines · Maxime Ripard
Quoted 64 lines · Dennis Gilmore
Quoted 62 lines · Maxime Ripard
Quoted 47 lines · Andre Przywara
Hi,
Quoted 37 lines · Maxime Ripard
Quoted 28 lines · Andre Przywara
Hi,
Quoted 13 lines · Maxime Ripard
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.Quoted 11 lines
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.Quoted 6 lines
Is that really such a problem? How many people rely on having
their
custom environment preserved over an update? (That's an honest
question)Quoted 6 lines
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.
Quoted 7 lines
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.Quoted 4 lines
Quoted 1 line
I personally just use pxe boot
It's not really about what personally you use, but what any user can use.
Not saying that it is. but how I use it is really simple for the user to use without needing to have a ton of specific knowledge about how u- boot works
Quoted 10 lines
Quoted 4 lines
dhcp
pxe get
pxe boot
and pick the right option. nothing needed on the client side.It has the assumption that the DHCP server is setup properly, which might or might not be the case, especially when it comes to the server
option being there and valid.Quoted 5 lines
Quoted 1 line
Maxime
Anyone doing something like this on X86 has to have the same setup. its not that hard of a ask to assume that a pxe environment is available. you can skip the dhcp part and set the serrver ip and system ip manually, its just simpler to use dhcp
I agree to both of you ;-)
As Maxime already pointed out, it's a bit of a pointless discussion, as x U-Boot users have possibly x different usage scenarios. Some very actively do work on the U-Boot prompt and rely on a customized and preserved environment, while others merely rely on some standardized boot paths, usingconfig_distro_bootcmd.hand PXE, DHCP and/or EFI.
Quoted 3 lines
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.
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 :-) 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).
Quoted 3 lines
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.
The Linux distributions don't seem to rely on the U-Boot environment (if I understood their feedback correctly). 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.
Quoted 3 lines
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. Allowing to move the environment to a different media is a recipe for disaster.
Currently boot.scr or uEnv.txt is loaded from FAT or other partitions as part of distro boot. Is this really not enough?
Signature · 2 lines
Best regards, Siarhei Siamashka