Wolfgang Denk wrote:
In message 444EB1D5.1000804@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