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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
