From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 11 Jun 2019 10:28:19 -0400 Subject: [U-Boot] [PATCH 0/5] sunxi: env: Load environment from boot media In-Reply-To: <20190611093728.5vtgmhge5azs3vaz@flea> References: <20190608012658.5369-1-andre.przywara@arm.com> <20190610083037.e2lshft7w3jnfux2@flea> <20190610101139.4a6cc3a2@donnerap.cambridge.arm.com> <20190611093728.5vtgmhge5azs3vaz@flea> Message-ID: <20190611142819.GE7115@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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. 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. > 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?". -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: