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