[U-Boot] [PATCH 0/5] sunxi: env: Load environment from boot media

[Tom Rini]

On Tue, Jun 11, 2019 at 04:53:58PM +0200, Maxime Ripard wrote:
> Hi!
> 
> On Tue, Jun 11, 2019 at 10:28:19AM -0400, Tom Rini wrote:
> > On Tue, Jun 11, 2019 at 11:37:28AM +0200, Maxime Ripard wrote:
> > > On Mon, Jun 10, 2019 at 10:11:39AM +0100, Andre Przywara wrote:
> > > > On Mon, 10 Jun 2019 10:30:37 +0200
> > > > Maxime Ripard <maxime.ripard at bootlin.com> wrote:
> > > >
> > > > Hi Maxime,
> > > >
> > > > thanks for having a look!
> > > >
> > > > > On Sat, Jun 08, 2019 at 02:26:53AM +0100, Andre Przywara wrote:
> > > > > > At the moment we need to configure the place where U-Boot tries to load
> > > > > > its environment from at compile time. This is not only inflexible, but
> > > > > > also unnecessary, as we have easy access to the boot source.
> > > > > >
> > > > > > This series prepares U-Boot on Allwinner boards to load the environment
> > > > > > from the same media where the SPL and U-Boot proper were loaded from.
> > > > > > This allows to keep one firmware binary, and copy it to an SD card,
> > > > > > eMMC or even SPI flash, without needing to configure it differently.
> > > > >
> > > > > This does change a couple of things though. The environment used to be
> > > > > loaded always from the same source, no matter the boot device. This
> > > > > means that if you would set an SD card, you would get the environment
> > > > > from the eMMC. Same thing for FEL. This is no longer the case.
> > > > >
> > > > > I don't know whether it's a good or a bad thing, but it should be
> > > > > mentionned.
> > > >
> > > > This is true, I failed to mention that.
> > > >
> > > > To start a discussion on this:
> > > > I consider the current (fixed location) behaviour somewhat surprising and
> > > > limiting, and couldn't find a real use case where this would be required.
> > > > Happy to hear of one!
> > > > Instead I thought about those cases:
> > > > - There is some botched U-Boot plus environment on the eMMC. You want to
> > > > boot from SD card to have a clean start, possibly to fix it. But it will
> > > > load the possibly outdated, broken or even unrelated environment from eMMC.
> > >
> > > This one might be a feature though. Being able to restore / fix an
> > > environment in the eMMC running from an SD card has save me a couple
> > > of times. Or booting from the SD card because the U-Boot on the eMMC
> > > is broken, while the environment is working.
> > >
> > > > - You want to boot from SD card without touching the eMMC at all. Saving
> > > > the environment will spoil that.
> > >
> > > But it goes against that one, which might be more important / sensible.
> > >
> > > > - You want to have one image for all possible boot media.
> > >
> > > That won't happen, only because NAND is a thing.
> >
> > Some of this is perhaps an argument for adding a sub-command to specify
> > where the environment is to be read from.  Heuristics are still only a
> > best guess and won't get it right every time.
> 
> I was mostly talking about the distribution of the image itself. While
> eMMC, SD and SPI flash can be made to take the same image, NAND will
> require a particular ECC and randomizer setup that requires that it's
> bundled separately.

Right.  But as you noted, there's use cases for boot from one to fix
another.

> > > And even then, I'm not really sure that it's a good thing. A U-Boot
> > > build these days is roughly in the same sizes than a stripped down
> > > Linux image. For an inferior solution in pretty much every aspect.
> >
> > Hey now.  We aren't _quite_ that large.  And we are (really!) trying to
> > find a happy medium between "distros want X/Y/Z for everyone" and "can
> > we commonly get back to UNDER 512kB maybe?  Please?".
> 
> I'm exagerating a little, but barely. A current build for the SoC
> Andre was mentionning takes 600kB. And since the trend has been for
> the binaries to grow for quite some time now, I'm pretty sure everyone
> will reserve 1MB just to be sure they have some room to spare.

Yes, it's larger than I would like, and features keep being added.  But
also, yes, DM stuff needs a harder look.

> Now, getting a kernel image to fit in a MB takes a bit of time, but
> it's not really impossible to achieve. And if you can reclaim that MB
> dedicated to U-Boot, it's actually fairly easy to do.
> 
> I've tried to have the size reduced at some time because we were
> corrupting our U-Boot binary as soon as we where using saveenv (which
> is probably one of the worst issue we could have), and it ended up
> with everyone agreeing that we needed to reduce the size, just not the
> one they were using.
> 
> It's kind of weird that people haven't yet embraced defconfig as they
> are in Linux, where every distro has its own configuration, and it's
> perfectly fine.

To the last point, distributions seemingly very much want to avoid
building U-Boot and there's a growing contingent that wishes the
hardware shipped with the DTB for the hardware as well.

-- 
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/20190611/2ed5591c/attachment.sig>