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

Tue Jun 11 16:10:34 UTC 2019

On Tue, Jun 11, 2019 at 04:34:25PM +0100, Andre Przywara wrote:
> On Tue, 11 Jun 2019 16:53:58 +0200
> Maxime Ripard <maxime.ripard at bootlin.com> 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.
> 
> Looks like there are exactly 2 out of 146 Allwinner boards with mainline
> (_defconfig) NAND support out there, and fortunately I haven't seen NAND
> flash on modern (sunxi) boards in a while.
> And if I see this correctly, there is neither eMMC nor SD card on the
> C.H.I.P. devices? So their defconfig will also "boot on all possible boot
> media".
> What I was aiming at with "have one image for all possible boot media" is
> to not throw away what works already: the _defconfig build for most (all?)
> boards works naturally on eMMC and SD card, also on SPI flash, for the SPL
> and for U-Boot proper. It's just the environment that requires fixing.
> Which is what this series is about.
> 
> > > 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.  
> 
> Yeah, I was wondering about this as well. Maxime's case of: "I want to
> save the environment to this device" seems like a valid use case.
> 
> Wouldn't a parameter to "saveenv" solve this rather elegantly? Happy to
> look into a patch for this.

I was thinking for the whole of "env".  Pass in a string maybe, and then
re-init the env portion based on that.  I think that might cover the
most cases of "we guessed wrong".

> > 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.
> 
> Well, we can't save everyone ;-)
> But given the number of boards with NAND flash out there and their
> mainline U-Boot support ...

Is it even anything other than CHIP?

> > > > 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.
> > 
> > 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.
> 
> I think that illustrates that we are coming from *very* different areas:
> My kernels are 16-20 MB (distro kernels or my own monolithic test
> kernels), plus tons of modules. I don't care about U-Boot being less than
> 600KB, since it goes into the first MB of an SD card or eMMC device, or
> into the SPI flash, which is at least 2MB, but mostly 16MB. And honestly I
> don't use the U-Boot environment too much, I am just relying on the distro
> defaults environment to find the EFI boot app.
> Your use cases seem to be quite different, mostly embedded in the original
> sense ("doesn't look like a computer"), I guess. Also I guess you will
> have your tailored config, probably plus tailored environment anyway.
> 
> So do you want a CONFIG_ option to turn this new behaviour off (or on)?
> As mentioned I couldn't think of too many use cases, so considered this as
> not needed.

This I think is helpful in illustrating the problem we have, which is
a very wide set of use cases.  We could save 70kB by dropping EFI
loader, and probably another "big" chunk of kB if we drop the oddball
and largely only used by "distro boot" commands.  But that would very
much break the distro boot use case, which is important :)

And not to single out EFI, since Heinrich is working on splitting out
"needed for UEFI self test" vs "needed for common use case/EBBR"
functionality, but the defaults for that start to conflict with "why is
my bootloader more than 256kB?".  And I think we need to take a harder
look at the DM framework and see if/how we can trim space.  Maybe figure
out a way to link-time/compile-time optimize the one-board/one-dts case.

> > 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.
> 
> That's indeed one thing I realised as well. In the past U-Boot wasn't very
> good as using menuconfig to tailor some defconfig, though I think this
> mostly works now. But I am not sure that's a real problem: if people care
> about bootloader tuning, they are hopefully professionals and can be
> bothered with providing their own .config.

We're getting farther with the Kconfig migration but it's still a good
bit from complete.  And even then, people expect the defconfig to be
"it".

-- 
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/890dce96/attachment.sig>