[U-Boot] [PATCH 2/4] env_nand.c: support falling back to redundant env when writing

[Scott Wood <scottwood@freescale.com>]

On 11/28/2012 03:06:00 PM, Phil Sutter wrote:
> Hi,
> 
> On Tue, Nov 27, 2012 at 04:04:15PM -0600, Scott Wood wrote:
> > On 11/21/2012 06:59:19 AM, Phil Sutter wrote:
> > > Without this patch, when the currently chosen environment to be
> > > written
> > > has bad blocks, saveenv fails completely. Instead, when there is
> > > redundant environment fall back to the other copy. Environment  
> reading
> > > needs no adjustment, as the fallback logic for incomplete writes
> > > applies
> > > to this case as well.
> > >
> > > Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
> >
> > Isn't this what CONFIG_ENV_RANGE is supposed to deal with?
> 
> Yes, that is more or less what is supposed to help for cases like  
> this.
> But given the fact that CONFIG_ENV_RANGE needs to span multiple erase
> pages which in our case are 128k in size, this is quite a deal.
> Especially since one needs to have multiple pages for both normal and
> redundant environment to be really sure.

And *that* is what CONFIG_ENV_OFFSET_OOB is supposed to deal with. :-)

Though at the moment redundant environment is not supported with  
CONFIG_ENV_OFFSET_OOB.

> But, we already have a fixed hashmap in field, so using  
> CONFIG_ENV_RANGE
> is simply no option.

That's relevant to what you put in your product, but it shouldn't be  
the basis of how mainline U-Boot does things for all boards.

> > Redundant environment is to deal with other problems such as a power
> > failure during saveenv.  If you just fall back to the other copy,
> > you're silently losing the redundancy.
> 
> The alternative to silently losing redundancy in case one of the  
> blocks
> in either normal or redundant env areas turns bad is to not being able
> to save the environment at all anymore. I'd prefer dropping the
> redundancy but still having a working system then. ;)

Another alternative is to noisily lose redundancy.

-Scott