[U-Boot-Users] Redundant environment expected behavior vs current

[Jerry Van Baren]

Stefan Roese wrote:
> On Wednesday, 26. April 2006 09:53, Wolfgang Denk wrote:
>>> I will have to add the code associated with this option into
>>> common/env_flash.c. If CFG_ENV_REDUND_SYNC is not defined no new code is
>> You can keep this as local extensions / patches. I  don't  think  I'm
>> going to add this, unless at least some other people speak up here on
>> the list and say that they need this, too.
> 
> I have to admit, that I was also a little astonished how the redundant 
> environment works when I first used it. I would have expected (as Tolunay 
> did) the 2nd totally synced version.
> 
> I do see the benefit that the current implementation only erases the flash 
> sectors half as much as normal (not redundant) flash environment or totally 
> synced redundant environment does. But is this really a problem? Then all not 
> redundant flash environment U-Boot implementations would have a problem too.
> 
> I also tend to forget such things like using "saveenv" twice, so I would vote 
> to let Tolunay implement this new behavior (using CFG_ENV_REDUND_SYNC) that 
> the user (or developer) can choose between both versions.
> 
> And if Wolfgang agrees to accept this patch then please include a short 
> description on both implementations in the README. That would be very 
> helpful.
> 
> Best regards,
> Stefan

My 2 cents:
-----------
1c: What u-boot currently has I would label a "back up" env, not a 
"redundant" env.  The analogy would be a back up tape's copy of your 
hard drive vs. a RAID-1's redundant copy.  Both copy mechanisms are 
useful, but in different ways.

2c: I've been working with "full featured" and flash EEPROMs for 20 
years and have not seen any lose their contents after being successfully 
programmed (and properly programmed - losing power during a program 
cycle is a Bad Thing[tm] DAMHIK :-/).  OTOH, I am in development and may 
have missed Manufacturing's warranty repair bulletins :-/.

gvb