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

[Maxime Ripard]

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.

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.

Loading the environment from the boot device instead of hardcoding
is pretty orthogonal to that though.

> Putting the environment on eMMC seems like a commonly accessible
> place, but isn't really reliable for those eMMC socket boards. I
> guess not many actually have a chip connected in the Pine64-LTS,
> SoPine or Pine-H64, for instance.  Forcing the environment to SD
> card is equally troublesome.

Yeah, that's true. I guess we could also rely on whether the eMMC / SD
is reseponding to commands, but I don't see any particular benefit to
do that.

> I think the situation gets even worse with SPI flash booting (which was
> the trigger for these patches). And no, we definitely don't want multiple
> defconfig files per board just to cover those cases. Also asking the user
> to manually change the config sounds more like a workaround.

Yeah, well, let's agree to disagree on this one.

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