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

[Scott Wood]

On 12/10/2012 07:41:43 AM, Phil Sutter wrote:
> On Fri, Dec 07, 2012 at 11:38:11AM -0600, Scott Wood wrote:
> > On 12/07/2012 10:58:53 AM, Phil Sutter wrote:
> > > 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.

Erase blocks are larger than write pages, yes.  I've never heard erase  
blocks called "pages" or write pages called "blocks" -- but my main  
point is that the unit of erasing and the unit of badness are the same.

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

"block" means "erase block".

Every write page has its own OOB, but it is erase blocks that are  
marked bad.  Typically the block can be marked bad in either the first  
or the second page of the erase block.

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

We don't currently have any mechanism for that to happen with the  
environment -- which could be another good reason to have real  
redundancy that doesn't get crippled from day one by having one copy  
land on a factory bad block.  Of course, that requires someone to  
implement support for redundant environment combined with  
CONFIG_ENV_OFFSET_OOB.

Maybe a better option is to implement support for storing the  
environment in ubi, although usually if your environment is in NAND  
that means your U-Boot image is in NAND, so you have the same problem  
there.  Maybe you could have an SPL that contains ubi support, that  
fits in the guaranteed-good first block.

Do you have any data on how often a block might go bad that wasn't  
factory-bad, to what extent reads versus writes matter, and whether  
there is anything special about block zero beyond not being factory-bad?

-Scott