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

[Tolunay Orkun]

Wolfgang Denk wrote:
> In message <444EB1D5.1000804 at orkun.us> you wrote:
>   
>> I agree but once you have written the one copy of the environment and 
>> protect it (if you have hardware support), one copy is already securely 
>> written you can go ahead and write the second environment.  We changed 
>>     
>
> You just said that the data is securely written and protected.
>
>   
Due to aging flash flash sectors that is written can change in which 
case, the newly written one might show up corrupt **over time**. At that 
time U-Boot will switch to the second copy but second copy does not have 
the latest stuff we put/modified because we did not sync them.

What I am trying to save redundancy means within "certain limitations" 
we can recover the data that is redundant. This redundancy scheme does 
not provide for that. By certain limitation I am pointing to things like 
number of correctable bits in ram , number of simultaneous disk failures 
in a RAID 5 array etc.
>> the environment because the old one was not right so keeping the old 
>> environment after one copy is written might not save us in certain 
>> situations.
>>     
>
> Which are?
>   
Say, I am booting one of the two kernels/initrd in flash. Or NFS booting 
from a different IP etc. Supplying a different kernel command line.

> Writing the new environment twice just adds flash wear.
>   
I agree but we are already adding wear by writing the flag byte location 
of that sector. Failure of the flag byte will make it unusable as well. 
Besides, if we are not going to update the environment frequently wear 
due to repeated write issue not a concern. Having a truly redundant 
environment is of greater in importance in my opinion.

>> forget to do this sort of stuff after some time. It would be great if 
>> the sync is provided as an option. How about CFG_ENV_REDUND_SYNC (or 
>> something like this) that runs the save command twice internally or 
>> something like that to that effect?
>>     
>
> Feel free to add this as a local extension. I  don;t  think  I  would
> ever enable this on any of my boards.
>   
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 
added and existing operation would be maintained. So, if you do not see 
any benefit from this you will not have to change anything... I can add 
this option to others (say env_nand.c) as well for parallelism.

>> The current scheme also does not sync environment from the good one if 
>> one environment detected bad during boot. Should U-Boot fix the bad one 
>> from the good one automatically? Currently, I think there is not even a 
>>     
>
> U-Boot never does any automatic writing to flash. This is something I
> consider evil.
>   
Yes, I agree. But I think we need to know if one copy of environment is 
bad just like one, there has been a correctable parity error or  one 
disk of a raid5 array has failed so a corrective action could be performed.

>   
>> diagnostic message that one environment is bad.
>>     
>
> No, should there be  one?  Obviously  a  "saveenv"  command  did  not
> complete succesfully; maybe just one millisecond eralier it would not
> have been started at all.
>   
Maybe saveenv completed correctly and over time there was been charge 
decay in flash cell caused some bits to flip....

>> How about U-Boot commands to verify environment so we can use it to do 
>> the sync etc. in a script.
>>     
>
> They are all in place. (crc, test). Just  use  them  as  needed.  But
>   
crc is too general purpose. I need to have to add knowledge of where the 
environment is stored and organized etc. which is not a big deal but not 
clean to use in a script. Luckily U-Boot environment structure is 
simpler than uimage files.

> frankly:  did  you  ever  see any corruption of NOR flash except when
> erasing / writing? And if you did, are you only concerned  about  the
> contents of the environment variables?
>   
I did see this happen in aging flash. It is not common and possibly more 
recent flashes probably have better charge retention etc. but it happens.

Best regards,
Tolunay