[U-Boot-Users] Re: Redundant environment

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Wolfgang Denk wrote:
> Dear Tolunay,
> 
> in message <445B8086.9000404@orkun.us> you wrote:
>> This patch would solve the issue that exists today that when the 
>> "active" environment is lost/corrupted for some reason the "redundant" 
>> environment would contain an exact copy of the primary to have the board 
>> come up without requiring the need to redo the changes that was lost on 
> 
> Actually I think that you will not acchieve  this  with  your  patch.
> This  is  why  I'm concerned. You see, if you feel better having this
> patch I would not complain, but I am afraid  that  a  lot  of  people
> might  just  activate it because they think it would do them any good
> when it doesn't (and actually it just hurts).
> 
> There is only one occasion when we have any significant likelyhood of
> losing the environment data: this is when a call to  "saveenv"  fails
> becaue  either  a)  we  have  a  power  loss, b) we have an otherwise
> induced reset of the CPU, or  c)  the  flash  sector  that  shall  be
> erased/written is failing.
> 
> So where exactly does your modification improve  anything?  Let's  go
> through this step by step.
> 
> Case 1: power loss/reset happens during the first  "saveenv",  i.  e.
>         when writing the first copy of the new environment data.
> 
>         In this case this first copy  contains  no  valid  data;  the
>         second copy of the environment contains valid, but old data.
> 
>         This is exactly the same as we have with the  current  imple-
>         mentation. I don't see any improvement.
> 
> Case 2: power loss/reset happens during the second "saveenv",  i.  e.
>         when writing the second copy of the new environment data.
> 
>         In this case this first copy contains valid new  data,  while
>         the  second  copy  of  the environment does not contain valid
>         data.
> 
>         In the current implementation, the first (and  only)  saveenv
>         would  have  completed,  too,  and  the reset would hit after
>         leaving this part of code, so we had valid new  data  in  the
>         first copy, and valid (but old) data in the second one.
> 
>         Again, this is not  an  improvement.  Actually  I  think  the
>         current implementations is even more useful.
> 
> Case 3: A flash sector in the first copy of the  environment  becomes
>         defective  while  we  erase or write it. In this case we will
>         see appropriate error conditions, and the  "saveenv"  command
>         will abort.
> 
>         This is the same as case 1: no valid data in copy  1,  valid,
>         but  old  data  in copy 2; no difference between the existing
>         and your new implementation.
> 
> Case 4: A flash sector in the second copy of the environment  becomes
>         defective  while  we  erase or write it. In this case we will
>         see appropriate error conditions, and the  "saveenv"  command
>         will abort.
> 
>         This is the same as case 2: valid new  data  in  copy  1,  no
>         valid  data  in copy 2 with your implementation, but probably
>         valid old data with the existing code.
> 
> I guess I must have missed some cases  because  there  was  none  yet
> where  the  new  implementaion  would improve the reliability. Please
> fill in these missing cases.

Case 5: Data retention.
If you check the data sheets of your flash device, you should find a 
section on data retention.  It probably is more than 10 years
Grabbing a Spansion AM29F800B 
<http://www.spansion.com/products/Am29F800B.html> data sheet at random, 
I find it is rated at 10 years at 150^C, 20 years at 125^C.

Even if the retention rating of the part given by the manufacturer is 
insufficient, a mirror (duplication) of the "redundant" environment that 
was created at the same time as the "active" environment could not be 
expected to last any longer than the "active" environment since they 
were written at the same time.

If (a) you are really paranoid and (b) you expect your gadget to outlive 
the retention of the memories, you need to rewrite the environment (and, 
likely, your whole program!) every few years in order to reset the 
decay.  Making a duplicate environment once won't help.

[snip]

> So, can you please fill in the szenario where your modification would
> really help to make the system more reliable?
> 
> Best regards,
> Wolfgang Denk

2cents, and worth every penny you paid,
gvb