[U-Boot] incremental environment updating

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Jerry Van Baren,
> 
> In message <49E335BB.4050609 at ge.com> you wrote:
>>> - 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).
> 
> So what do we save, then? Instead of a single write we now need
> actually two...

Well, I have a (NOR) flash with a 128Kbyte sector size.  If my env is 
~2K, I can do ~64 updates before I would need to erase the sector and 
start over.

 From a practical point of view, that probably isn't a big deal.  From a 
"bugs me" POV, it bugs me that I'm "wasting" 126K of that sector.  :-P

IIRC, redundant env lumps take two sectors so the redundant env isn't 
erased (need to check the code).  Depending on your acceptable risk 
tolerance, the "redundant" env lump would simply be lump(n-1).

[snip]

Best regards,
gvb