[U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al.

[Maxime Ripard]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/c39d268a/attachment.sig>