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

[Phil Sutter]

On Tue, Dec 11, 2012 at 05:12:32PM -0600, Scott Wood wrote:
> 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.

Ah, OK. Please excuse my humble nomenclature, I never cared enough to
sort out what is called what. Of course, this is not the best basis for
a discussion about these things.

But getting back to the topic: The assumption of blocks getting bad, not
pages within a block means that for any kind of bad block prevention,
multiple blocks need to be used. Although I'm honestly speaking not
really sure why this needs to be like that. Maybe the bad page marking
would disappear when erasing the block it belongs to?

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

Interesting. I had the impression of pages being marked bad and the
block's badness being taken from whether it contains bad pages. Probably
the 'nand markbad' command tricked me.

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

Well, as long as CONFIG_ENV_OFFSET_REDUND supported falling back to the
other copy in case of error there would be a working system in three of
four cases instead of only one.

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

No, sadly not. I'd guess this information depends on what hardware being
used specifically. But I suppose block zero being prone to becoming
worn just like any other block, although it not being erased as often
should help a lot.

Assuming a certain number of erase cycles after each block is worn out
and given the fact that CONFIG_ENV_OFFSET_REDUND has always both blocks
written (unless power failure occurs), they would turn bad at the same
time and therefore rendering the environment useless with or without
fallback. :)

Best wishes, Phil

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