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

[Tom Rini]

On Thu, Oct 19, 2017 at 03:24:57PM +0200, 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.
> 
> 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.

There is a strong expectation that environment is preserved.  In
deployment cases, it's a must, and when it's not able to happen, people
have to work their upgrade such that it knows and the flag-day type
action happens.

It's certainly not unprecedented to change the env location / size /
type (we've done it on am335x_evm/related a few times) but it usually
requires a good reason and communication outward too.

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

Yes, it's likely a reasonable at the time choice.  This is also, FWIW, I
try and encourage new SoCs to pick env in filesystem options instead as
it's generally more friendly for reference / general purpose type
builds, and custom designs can still easily figure out where they want
to store env and do so.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171019/3452579f/attachment.sig>