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

[Phil Sutter]

On Fri, Dec 07, 2012 at 11:38:11AM -0600, Scott Wood wrote:
> On 12/07/2012 10:58:53 AM, Phil Sutter wrote:
> > Scott,
> > 
> > On Fri, Dec 07, 2012 at 12:53:34PM +0100, Phil Sutter wrote:
> > > 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.
> > 
> > Hmm. Does not look like CONFIG_ENV_OFFSET_OOB is used to select the
> > block(s) within the erase page to save the environment. Looking at
> > common/env_nand.c:318, the environment offset saved in the OOB seems  
> > to
> > be in erase page unit.
> 
> I'm not sure what you mean by "block(s) within the erase page" --  
> blocks are the unit of erasing, and of bad block marking.

Not always, at least not with NAND flash. Erase pages are mostly bigger
than write pages (or "blocks"). In my case, flash consists of 0x800
bytes write pages and 0x2000 bytes erase pages.

> The block to hold the environment is stored in the OOB of block zero,  
> which is usually guaranteed to not be bad.

Erase or write block? Note that every write block has it's own OOB.

> > On the other hand, I could not find code that alters this setting  
> > based
> > on bad blocks found or whatever. This seems to simply be an  
> > alternative
> > to setting CONFIG_ENV_OFFSET at build-time.
> 
> It is set by the "nand env.oob" command.  It is currently a manual  
> process (or rather, automation is left to the user's board preparation  
> process rather than being built into U-Boot), as U-Boot wouldn't know  
> how to give back unused blocks to other purposes.

So that assumes that any block initially identified 'good' will ever
turn 'bad' later on?

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