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

[Scott Wood <scottwood@freescale.com>]

On 12/21/2012 04:34:03 AM, Phil Sutter wrote:
> On Thu, Dec 20, 2012 at 03:41:37PM -0600, Scott Wood wrote:
> > On 12/20/2012 03:28:39 PM, Phil Sutter wrote:
> > > On Tue, Dec 11, 2012 at 05:12:32PM -0600, Scott Wood wrote:
> > > > 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?
> >
> > Yes, it would disappear.  This is why erase operations skip bad  
> blocks,
> > unless the scrub option is uesd.
> 
> Which is apparently preventing good pages in a block with a bad page
> from being used, isn't it?

Right,  plus the knowledge of which pages within the block are bad  
simply isn't there.

> > > 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.
> >
> > Do you mean the lack of error checking if you pass a  
> non-block-aligned
> > offset into "nand markbad"?
> 
> I think the bigger "problem" is 'nand markbad' updating the bad block
> table along the go. So no real bad block detection occurs as far as I
> can tell.

I'm not sure what you mean here.

> > > 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.
> >
> > I'm not sure what you mean here -- where do "three", "four", and  
> "one"
> > come from?
> 
> Just some quantitative approach: given the environment residing at  
> block
> A and it's redundant copy at block B, four situations may occur: both
> blocks good, block A bad, block B bad or both blocks bad. Upstream  
> would
> fail in all cases but both blocks good. My patch would turn that into
> failing only if both blocks bad. So working in three of four cases
> instead of in only one of four.

Those two cases that would suddenly be working would be lacking  
redundancy -- would you want to ship it like that?  If U-Boot is noisy  
about it, then such units can still have their NAND chips replaced  
before shipping.

-Scott