wd@denx.de wrote on 06/21/2004 04:41:34 PM:
As I understand it, the ENV_REDUND feature in u-boot protect the environment in flash from a power failure during saveenv. It appears
it
will not protect it against accidental scribbling from errant code/processor.
Well, it does, as long as you overwrite only one of the redundand sectors. If this is your concern, then you should locate these two sectors as far apart form each other as possible, ideally in different flash banks.
According to my tests/observations, when you first issue a saveenv to a brand new flash, only one environment block is written. This means any corruption to this block will wipe out the saved environment. Apparently this is often the case for production units, unless there is an environment upgrade. After two saveenv commands, it can indeed survive corruption to one block.
By the way, as you might have already known, I'm still using 0.4.8. The feature might have changed from then. I am using it because my priorities dictates that I get all our product's 1.0.0 features out before I can spend time upgrading u-boot. This suck a lot in my opinion, but business is business.
I like to know from the community, whether it is important to protect
it
against flash scribbling, or are the majority of flash environment corruption due to interruption to the saveenv command?
Actually I have never seen any corruption of the environment in flash by either of these reasons in real life myself, nor with any of our customers. If there was a problem, it was usually an user's error, which you cannot prevent.
But there are certain types of applications where reliability is critical, and then such a feature becomes important. But remember that the protection is inteded for production use, and typical usage cases there. If your software design allows "scribbling" on the boot loader's flash memory, then you have a MAJOR problem anyway.
One of the requirements for our product is to have an industrial strength upgrade path for the kernel.
That means the kernel must be upgradable remotely. It must also have revert back to the old kernel if the new kernel fails in any way.
How this is done here at Nanometrics is we keep 2 kernel partitions, kernel A and kernel B.
One is designated as the default kernel such that u-boot by default boots the default kernel. Assume A is default.
To upgrade the kernel, B partition is programmed with the new kernel remotely, using Linux' fantastic networking support. Then the user instructs the unit to run the B kernel once, essentially testing the new kernel.
This is done by sending a message to u-boot from the kernel to boot B once. I plan to use the u-boot environment, so the environment must be accessible from both u-boot and the kernel.
The unit is then rebooted, and when u-boot comes up, it sees that it needs to boot B once, it obliges and remove that message so that if the new kernel crashes for any reason, u-boot will go back to the old kernel.
If the new kernel runs fine and the user is satisfied with the new kernel, the user has to commit the change by setting B to default. This is done by writing to the u-boot environment again.
In summary, because the environment is updated from many places by _users_, it is important that I have a back up of the environment at all times.
Hope this clarify my intent,
David