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

Maxime Ripard maxime.ripard at free-electrons.com
Fri Dec 8 09:05:51 UTC 2017


Hi Tom,

On Thu, Dec 07, 2017 at 03:09:31PM -0500, Tom Rini wrote:
> > 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

This is done already.

> and have something posted shortly after v2018.01 releases, and I'll
> apply it for inclusion in v2018.03?

And I was waiting for your feedback :)

I'll do that, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171208/6d26d680/attachment.sig>


More information about the U-Boot mailing list