[U-Boot-Users] redundant environment block
Hi all,
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.
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?
Thanks a lot, David
In message OF1DF5789D.DD8FEF70-ON85256EBA.00649B07-85256EBA.00651617@nanometrics.ca you wrote:
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.
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.
[Jut a note: I have seen quite a number of cases of corrupted environment when stored in EEPROM. I recommend NOT to use EEPROM for the environment to all our customers. (Also it's slow as hell when booting.)]
Best regards,
Wolfgang Denk
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
In message OF5F8667A7.07E4DE39-ON85256EBC.0044D597-85256EBC.0047ED01@nanometrics.ca you wrote:
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
Saveenv will _always_ write only one block. This is intentional.
corruption to this block will wipe out the saved environment. Apparently
Remember that the most likely way to corrupt this block is by a failing saveenv comand. If you have to deal with arbitrarily corrupted sectors in flash you have lost anyway - with the same probability you can lose any other seciotr as well, for example one which contains U-boot code.
Also, in many cases (when embedded environment is used), _both_ redundanrd sectors will be pre-initialized with the default environment.
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.
The behaviour of U-Boot is simple and clear. It makes it easy to adapt your production to your requirements.
By the way, as you might have already known, I'm still using 0.4.8. The
Don't blame us for that.
I'm not sure what you're trying to point out. I don't see any deficientcies on U-Boots part here.
Best regards,
Wolfgang Denk
participants (2)
-
David Ho -
Wolfgang Denk