From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 19 Oct 2017 09:31:55 -0400 Subject: [U-Boot] [PATCH 0/3] sunxi: Fix boot of Cubietruk and al. In-Reply-To: <20171019132457.dcsamtfncimf53af@flea> References: <20171019082649.27819-1-maxime.ripard@free-electrons.com> <829444bb-fa9e-40a4-3b58-f5506557f89b@arm.com> <20171019132457.dcsamtfncimf53af@flea> Message-ID: <20171019133155.GX12015@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: