[U-Boot-Users] redundant environment block

[David Ho]

wd at 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