In message 444EC5F1.10205@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