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

[Andre Przywara <andre.przywara@arm.com>]

On Mon, 10 Jun 2019 10:30:37 +0200
Maxime Ripard <maxime.ripard@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.
- You want to boot from SD card without touching the eMMC at all. Saving
the environment will spoil that.
- You want to have one image for all possible boot media. 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.

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.

Happy to hear of cases where this behaviour would cause trouble.

For the context:
These patches are part of a branch of mine, which allows to create a nice
flasher image for the Pine64-LTS (and other boards with SPI flash): It
boots from SD card and presents a U-Boot bootmenu, which among normal boot
options offers to install this image to SPI flash, or eMMC, if connected.
The installer bootmenu items live in "raw MMC" envirnment on the SD card
and are not copied to SPI flash. So with these changes everything falls
into place naturally.

Cheers,
Andre.