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