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

Wed Jun 12 13:08:19 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:
> > 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.

That's a rather big underestimation though. Most of the boards before
the H3 era have a NAND. UBI cannot deal with the NAND chips technology
yet, but they do have a NAND chip that should be supported in the
future.

> And if I see this correctly, there is neither eMMC nor SD card on the
> C.H.I.P. devices?

Yes.

> So their defconfig will also "boot on all possible boot media".

But not the Olinuxinos, Cubieboard, pcduino's, etc. Basically all the
A10/A13/A20/A33 boards have a NAND chip, and most of them will also
have an SD card slot.

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

It works because the support is not complete at this point, so it's
pretty fragile to market it as such.

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

Yeah, passing the argument is pretty elegant.

> > 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 ;-)

Yeah, but my main objection is that you're saying you want to :)

> But given the number of boards with NAND flash out there and their
> mainline U-Boot support ...

Like I said, it's pretty much 50/50.

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

It's not really my point though. My point is that as U-Boot grows
bigger, we are wandering in the same order of magnitude that Linux,
and Linux can be turned into a "bootloader" as well. Loading Linux,
then loading your actual Linux image and kexec'ing is a thing.

The closer we come to Linux, the more valid that solution is,
especially now that everything that could be provided by U-Boot (like
PSCI) has been pushed down to ATF.

(And yeah, on embedded systems, you can even skip the kexec and just
run the minimal kernel)

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190612/e7294971/attachment.sig>