From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Thu, 6 Dec 2012 12:18:39 -0600
Subject: [U-Boot] [PATCH 2/4] env_nand.c: support falling back to
 redundant env when writing
In-Reply-To: <20121128210600.GA3220@philter.vipri.net> (from
	phil.sutter@viprinet.com on Wed Nov 28 15:06:00 2012)
Message-ID: <1354817919.8062.8@snotra>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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