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 -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
