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.rip...@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
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
