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

[Wolfgang Denk]

In message <444EC5F1.10205 at orkun.us> you wrote:
> 
> 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 

Chances, that the problem happens while writing, are much higher than
that flash sector which are just being read will lose their contents.
Of course this is possible, but then all flash sectors are  affected,
including  those  storing the U-Boot code. If you are concerned about
such things, you will have to add additioinal security measures.

But seriously, have you ever seen such a thing happen in real life?

> 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.

If theis is your concern, then sync it.  Nothing  prevents  you  from
doing this.

> 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.

So you probably want ECC on your boot flash?

> >> 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.

How  would  this  corrupt  an  already  stored  and  write  protected
environment sector?

> 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. 

No. This does not add a new erase cycle.

> 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.

This is your opinion, OK. As mentioned before, all you need to do  is
run "saveenv" twice.

> 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.

> > 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.

This is a different story. With a RAID5 array, you have a  disk  that
needs to be replaced because it is broken.

With redundand environment, in 99% or more of all  cases  nothing  is
broken,  the  only  problem  was  a reset of the system in an unlucky
moment (while storing the new environment). This  situation  will  go
away automatically whenever you use the next "saveenv" command. Until
then, no problem exists - you have a valid environment.

I do not see any problems here.

> Maybe saveenv completed correctly and over time there was been charge 
> decay in flash cell caused some bits to flip....

If this is your concern you need to protect / check all  other  flash
sectors  as  well.  But  if you don't trust the contents of the flash
memory - why would you then trust the program that  is  running  from
this  memory  and  let  it check itself? If you reach such a level of
paranoia, you need parity or ECC for your flash memory.

> 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.

U-Boot provides  an  astonishing  flexibility  by  using  scripts.  I
request  that  you  use  this  flexibility  instead of blowing up the
common code whith  rarely  used  features  that  can  be  implemented
trivially as a script.

> > 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.

Did it really happen in a situation where the flash was only read?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If it has syntax, it isn't user friendly.