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

[Maxime Ripard]

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.

> 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.

> 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?

> 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 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.

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/75b7f702/attachment.sig>