[U-Boot] [PATCH 00/14] env: Multiple env support and env transition for sunxi

Tom Rini trini at konsulko.com
Thu Dec 7 20:09:31 UTC 2017


On Tue, Nov 28, 2017 at 11:24:35AM +0100, Maxime Ripard wrote:

> Hi,
> 
> Here is an attempt at transitioning away from the MMC raw environment to a
> FAT-based one. Since the RFC was quite well received, I actually tested it
> and fixed a few rough edges.
> 
> You'll find the first RFC here for reference:
> https://lists.denx.de/pipermail/u-boot/2017-October/310111.html
> 
> And the second that originated in this series:
> https://lists.denx.de/pipermail/u-boot/2017-November/311608.html
> 
> The fundamental issue I'm trying to adress is that we've had for a
> very long time the assumption that the main U-Boot binary wouldn't
> exceed around 500 bytes.
> 
> However, we're starting to get real close to that limit, and are
> running out of silver bullets to deal with the consequences of having
> a bigger U-Boot binary, the main consequence being that we would
> have some overlap between the environment and U-Boot.
> 
> One way to address this that has been suggested by Tom is to move away
> from the raw MMC environment to a FAT-based one. This would allow us
> to slowly migrate away, and eventually remove the MMC-raw option
> entirely to reclaim that space for the binary.
> 
> That cannot be done in a single release however, since we might have
> environments in the wild already that people rely on. And since we
> always encouraged people to use the raw MMC environment, noone would
> expect that.
> 
> This is even worse since some platforms are using the U-Boot
> environment to deal with implement their upgrade mechanism, such as
> mender.io, and force moving the environment would break any further
> upgrade.
> 
> The suggested implementation is to allow U-Boot to compile multiple
> environments backend at once, based on the work done by Simon. The
> default behaviour shouldn't change obviously. We can then piggy-back
> on this to tweak on a per-board basis the environment lookup algorithm
> to always favour the FAT-based environment and then fallback to the
> MMC. It will allow us to migrate a raw-MMC user to a FAT based
> solution as soon as they update their environment (assuming that there
> is a bootable FAT partition in the system).
> 
> This has just been compile tested on sunxi so far, and I'd like
> general comments on the approach taken. Obviously, this will need to
> work properly before being merged.
> 
> Let me know what you think,

I think this is the right direction to head in.  Can you please address
the few outstanding points / questions and have something posted shortly
after v2018.01 releases, and I'll apply it for inclusion in v2018.03?
Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171207/5d4e52c6/attachment.sig>


More information about the U-Boot mailing list