[U-Boot] incremental environment updating

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Jerry Van Baren,
> 
> In message <49E32C3C.8090404 at ge.com> you wrote:
>> Since flash can change 1s to 0s, but cannot change them back, you could 
>> redefine the env storage to be
>>    <next><crc><env><NUL>[undefined]
>> (note the added <next> at the start).  By definition, the valid env's 
>> <next> == 0xFFFFFFFF.  To write a new env, simply write the offset of 
>> [undefined] into the <next> location and then write a new env lump.
> 
> I see problems with this:
> 
> - it's incompatible with the current format, i. e. detection of
>   existing old formats needs a special case which is something I
>   always consider ugly.

True, although that is an issue only for upgrades to boards that have an 
existing env and that you want to use the new env method on.  I would 
expect the special casing would not be excessively ugly and may not be 
necessary, depending on how important backward compatibility (board 
upgrading) is.

> - it works only on NOR flash, not on any media that can be accessed
>   only in blocks

Not true: the offset merely needs to be aligned to the next block in 
that case:
   <next><crc><env><NUL>FFFFFFFFFFFF <next><crc><env><NUL>[undefined]
   ^^^^ offset of ------------------> ^^^^ 0xFFFFFFFF

All flash that I can recall seeing allows at least a limited number of 
rewrites to a block (the limited number getting smaller on successive 
generations), so two writes to the env start block (once to write the 
new env, a second time to rewrite the 0xFFFFFFFF to point to the 
superceeding env).  If the flash didn't support two writes, that would 
be a show-stopper.  Due to how people use flash, I don't think the 
number will ever go to one write (IIRC, 4 is typical of current 
generation NAND).

> - handling of redundant environment becomes a lot more complicated

I don't think so: it would be handled the same way as the primary env in 
a separate sector as is done currently.  If you step through all of the 
primary env lumps and the last one has an invalid CRC, you fall back to 
the backup env and repeat the search.

> BTW: what was the exact problem we were trying to solve? Saving the
> time it takes to erase one flash sector?
> 
> If we have to pay  for  this  with  introducing  a  new, incompatible
> environment format, and probably having to handle NOR flash and other
> storage media differently, I doubt if this is worth the effort.

That could very well be true.

> Best regards,
> 
> Wolfgang Denk

Ditto,
gvb