[U-Boot-Users] Redundant environment expected behavior vs current
wd at denx.de
Wed Apr 26 09:53:31 CEST 2006
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
> 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
> 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?
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.
More information about the U-Boot