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

[Phil Sutter]

Scott,

On Thu, Dec 06, 2012 at 12:18:39PM -0600, Scott Wood wrote:
> 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 at 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. :-)

Good to know, I already wondered what exactly this option is there for.

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

I will have a look at it now, because that could be an elegant solution
for both of us I think.

> > 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.

Yes, of course. That was merely me explaining myself, not so much of a
real point in matters of what should go mainline and what not.

> > > 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.

Would that be an acceptable alternative from your point of view? Having
CONFIG_ENV_OFFSET_OOB in mind, there may be situations where all blocks
of either one of the redundant environments get bad (quite artificial, I
know). Losing redundancy in exchange for keeping env writeability could
still be an option then. What do you think?

Best wishes,

Phil Sutter
Software Engineer

-- 
Viprinet Europe GmbH
Mainzer Str. 43
55411 Bingen am Rhein
Germany

Phone/Zentrale:               +49 6721 49030-0
Direct line/Durchwahl:        +49 6721 49030-134
Fax:                          +49 6721 49030-109

phil.sutter at viprinet.com
http://www.viprinet.com

Registered office/Sitz der Gesellschaft: Bingen am Rhein, Germany
Commercial register/Handelsregister: Amtsgericht Mainz HRB44090
CEO/Geschäftsführer: Simon Kissel