[U-Boot] incremental environment updating

[Jerry Van Baren]

Mike Frysinger wrote:
> On Monday 13 April 2009 06:15:24 Wolfgang Denk wrote:
>> In message Mike wrote:
>>> currently the env code will erase the entire env storage before writing
>>> back out the current env, even if the env storage has enough empty space
>>> to store the current env.  for example, if CONFIG_ENV_SIZE is declared as
>>> 0x2000 but the current env only takes up ~0x300 bytes, the whole 0x2000
>>> is erased and then the ~0x300 gets written out.  seems like we can get a
>>> pretty good return for fairly low effort if we appended env updates
>>> rather than erasing/writing every time ?  it'd certainly be faster. 
>>> while systems with a dedicated sector this isnt so bad, but for people
>>> who have to embed the env in the middle of a large sector, this would be
>>> much faster most of the time.
>>>
>>> has there been previous discussion along these lines that i havent seen ?
>> This hasn't been discussed before. Interesting idea. However, I fail
>> to see how this could be implemented without changing the environment
>> format?
> 
> that depends on how you want the compatibility to go.  being able to read old 
> environments by newer u-boots is reasonable, but i dont think having old u-
> boots read newer environments makes realistic sense ?
> 
> in terms of actual changes, i had a couple of ideas ... the current env format 
> is: <crc><env><NUL>[undefined].  so if we logically extend the format where 
> [undefined] is <crc><env><NUL>[...], then all existing env storage would be 
> automatically imported.  considering most env storage out there uses a bit 
> value of "0" to mean programmed and "1' to mean unprogrammed, it should be 
> pretty easy to quickly detect where the appended envs stop.
> -mike

Hi Mike,

Another concept is to append a complete new env on every write.  This is 
less efficient than just a delta, but has a substantial advantage in 
that it gives the user a way to erase env variables as well as change 
them.  I suspect it would also be simpler to implement.

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.
   <next><crc><env><NUL> <next><crc><env><NUL>[undefined]
    ^^^^ offset of -----> ^^^^ 0xFFFFFFFF

To find the valid env, you simply start at the start of the env area and 
keep adding <next> to the env start address until <next> == 0xFFFFFFFF. 
  Add four and your env address is correct.  No other change needed to 
the env reading code.

Either way, we would need a new command, say "compactenv" (kind of a 
long command :-(, maybe there is a shorter German word ;-).  This would 
erase the current env sector and rewrite it with one env, resetting the 
clock.  This could also be done automatically if there is no room left 
in the env storage area (both options would probably be good to implement).

Another note: this would make it safer to append the env to u-boot 
rather than keeping it in a separate sector, except when the env storage 
area needs to be cleared.  I don't know if that is worth bragging about, 
however ("Our New Improved[tm] Env storage handling is 99 times safer: 
it now only risks bricking your board one time in a hundred!").

Best regards,
gvb