From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 11 Jun 2019 11:20:15 -0400 Subject: [U-Boot] [PATCH 0/5] sunxi: env: Load environment from boot media In-Reply-To: <20190611145358.x5xpbrffmslzl2at@flea> References: <20190608012658.5369-1-andre.przywara@arm.com> <20190610083037.e2lshft7w3jnfux2@flea> <20190610101139.4a6cc3a2@donnerap.cambridge.arm.com> <20190611093728.5vtgmhge5azs3vaz@flea> <20190611142819.GE7115@bill-the-cat> <20190611145358.x5xpbrffmslzl2at@flea> Message-ID: <20190611152015.GF7115@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 04:53:58PM +0200, Maxime Ripard wrote: > Hi! > > On Tue, Jun 11, 2019 at 10:28:19AM -0400, Tom Rini wrote: > > 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. > > I was mostly talking about the distribution of the image itself. While > eMMC, SD and SPI flash can be made to take the same image, NAND will > require a particular ECC and randomizer setup that requires that it's > bundled separately. Right. But as you noted, there's use cases for boot from one to fix another. > > > 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?". > > I'm exagerating a little, but barely. A current build for the SoC > Andre was mentionning takes 600kB. And since the trend has been for > the binaries to grow for quite some time now, I'm pretty sure everyone > will reserve 1MB just to be sure they have some room to spare. Yes, it's larger than I would like, and features keep being added. But also, yes, DM stuff needs a harder look. > Now, getting a kernel image to fit in a MB takes a bit of time, but > it's not really impossible to achieve. And if you can reclaim that MB > dedicated to U-Boot, it's actually fairly easy to do. > > I've tried to have the size reduced at some time because we were > corrupting our U-Boot binary as soon as we where using saveenv (which > is probably one of the worst issue we could have), and it ended up > with everyone agreeing that we needed to reduce the size, just not the > one they were using. > > It's kind of weird that people haven't yet embraced defconfig as they > are in Linux, where every distro has its own configuration, and it's > perfectly fine. To the last point, distributions seemingly very much want to avoid building U-Boot and there's a growing contingent that wishes the hardware shipped with the DTB for the hardware as well. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: