NAND bbt build reads wrong oob data

NAND bbt build reads wrong oob data

[Todd Poynor]

The recent change to read only the bad block marker while building the
bad block table is giving me some trouble on an OMAP16xx H2, and I'm
trying to figure out where the problem lies (and I'm pretty new at NAND
flash as may become obvious).

The value read seems to be a different byte, perhaps offset 14 instead
of offset 5 as specified by the placement scheme.  The hack that seems
to fix it for me, namely to read the whole OOB area instead of the
individual byte, is below.  (I also got rid of some refs to scanlen
which is forced to zero for the ! NAND_BBT_SCANEMPTY case, and
NAND_BBT_SCAN2NDPAGE is triggering a BUG I haven't investigated yet.)

If anybody has a clue for me I'd be thankful; in any case, I'll further
educate myself on how this is supposed to work. -- Todd

Index: linux/drivers/mtd/nand/nand_bbt.c
===================================================================
--- linux.orig/drivers/mtd/nand/nand_bbt.c	2005-07-15 02:26:18.000000000 +0000
+++ linux/drivers/mtd/nand/nand_bbt.c	2005-07-15 02:42:41.000000000 +0000
@@ -300,7 +300,7 @@
 	if (!(bd->options & NAND_BBT_SCANEMPTY)) {
 		/* We need only read few bytes from the OOB area */
 		scanlen = ooblen = 0;
-		readlen = bd->len;
+		readlen = mtd->oobblock;
 	} else {
 		/* Full page content should be read */
 		scanlen	= mtd->oobblock + mtd->oobsize;
@@ -338,12 +338,13 @@
 				size_t retlen;
 				
 				/* No need to read pages fully, just read required OOB bytes */
-				ret = mtd->read_oob(mtd, from + j * mtd->oobblock + bd->offs,
-							readlen, &retlen, &buf[0]);
+				ret = mtd->read_oob(mtd, 
+						    from + j * mtd->oobblock,
+						    readlen, &retlen, &buf[0]);
 				if (ret)
 					return ret;
 
-				if (check_short_pattern (&buf[j * scanlen], scanlen, mtd->oobblock, bd)) {
+				if (check_short_pattern (&buf[bd->offs], readlen, mtd->oobblock, bd)) {
 					this->bbt[i >> 3] |= 0x03 << (i & 0x6);
 					printk (KERN_WARNING "Bad eraseblock %d at 0x%08x\n", 
 						i >> 1, (unsigned int) from);
@@ -969,7 +970,7 @@
 static uint8_t scan_ff_pattern[] = { 0xff, 0xff };
 
 static struct nand_bbt_descr smallpage_memorybased = {
-	.options = NAND_BBT_SCAN2NDPAGE,
+	.options = 0,
 	.offs = 5,
 	.len = 1,
 	.pattern = scan_ff_pattern

Re: NAND bbt build reads wrong oob data

[Thomas Gleixner]

On Thu, 2005-07-14 at 20:19 -0700, Todd Poynor wrote:
> The value read seems to be a different byte, perhaps offset 14 instead
> of offset 5 as specified by the placement scheme.  The hack that seems
> to fix it for me, namely to read the whole OOB area instead of the
> individual byte, is below. 

That's pretty strange. Which chip type are you using ? 

>(I also got rid of some refs to scanlen
> which is forced to zero for the ! NAND_BBT_SCANEMPTY case, 

The check_short stuff carries some needless arguments anyway. I
committed a cleanup, no functional change. I like to know more about
that before changing it.

> and
> NAND_BBT_SCAN2NDPAGE is triggering a BUG I haven't investigated yet.)

You introduced it by setting readlen = mtd->ooblock. I know that the
name of this is confusing. oobblock is the page size. So readlen is >
buffersize.

tglx

Re: NAND bbt build reads wrong oob data

[Todd Poynor]

Thomas Gleixner wrote:
> On Thu, 2005-07-14 at 20:19 -0700, Todd Poynor wrote:
> 
>>The value read seems to be a different byte, perhaps offset 14 instead
>>of offset 5 as specified by the placement scheme.  The hack that seems
>>to fix it for me, namely to read the whole OOB area instead of the
>>individual byte, is below. 
> 
> 
> That's pretty strange. Which chip type are you using ? 

NAND device: Manufacturer ID: 0xec, Chip ID: 0x45 (Samsung NAND 32MiB
1,8V 16-bit)

using omap-nand-flash.c driver from OMAP community tree 
linux-omap-2.6.git at source.mvista.com (which is slated for sending to 
linux-mtd after conversion of board specifics to LDM platform device stuff).

OK, this is pretty unexpected, so I'll try harder to figure out where it 
goes wrong or whether I've got another board that it affects (a 
colleague reported some new bad blocks messages after upgrading to the 
same software on a different board, will see if there's a similar 
situation).

>>and
>>NAND_BBT_SCAN2NDPAGE is triggering a BUG I haven't investigated yet.)
> 
> 
> You introduced it by setting readlen = mtd->ooblock. I know that the
> name of this is confusing. oobblock is the page size. So readlen is >
> buffersize.

d'oh!  Thanks,

-- 
Todd

Re: NAND bbt build reads wrong oob data

[Thomas Gleixner]

On Fri, 2005-07-15 at 00:58 -0700, Todd Poynor wrote:
> Thomas Gleixner wrote:
> > On Thu, 2005-07-14 at 20:19 -0700, Todd Poynor wrote:
> > 
> > That's pretty strange. Which chip type are you using ? 
> 
> NAND device: Manufacturer ID: 0xec, Chip ID: 0x45 (Samsung NAND 32MiB
> 1,8V 16-bit)

I know whats the source of the problem.

The read_oob code is not handling 16 bit correctly. The nand_bbt code
wants to read 1 byte at an odd address which does not work for 16 bit
access.

I committed a similar workaround as you suggested, jst without the
builtin long read OOPS :)

tglx

RE: NAND bbt build reads wrong oob data

[Martin Fouts]

 

-----Original Message-----
From: linux-mtd-bounces@lists.infradead.org
[mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Todd Poynor
Sent: Friday, July 15, 2005 12:59 AM
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: Re: NAND bbt build reads wrong oob data


> OK, this is pretty unexpected, so I'll try harder to figure out where
it goes wrong or whether 
> I've got another board that it affects (a colleague reported some new
bad blocks messages after 
> upgrading to the same software on a different board, will see if
there's a similar situation).

I can confirm that it happens on other boards. I have the same problem
with the same NAND chip on a P2 board.  I haven't had time to
investigate yet.

Marty

Re: NAND bbt build reads wrong oob data

[Todd Poynor]

Verified this fixes my board, many thanks, Thomas!

From: gleixner@infradead.org
Date: Fri, 15 Jul 2005 14:53:51 +0100
Subject: mtd/drivers/mtd/nand nand_bbt.c,1.34,1.35

Modified Files:
	nand_bbt.c
Log Message:
[MTD] NAND: Fix broken bad block scan for 16 bit devices

The previous change to read a single byte from oob breaks the
bad block scan on 16 bit devices, when the byte is on an odd
address. Read the complete oob for now

-- 
Todd

RE: NAND bbt build reads wrong oob data

[Thomas Gleixner]

On Fri, 2005-07-15 at 09:55 -0700, Martin Fouts wrote:
> Sorry for the repeat, but mailman doesn't like my headers, but won't
> tell me why, so I figured I send this direct. 

It got caught by the inclusion of the original raw message headers. 

-----Original Message-----
From: linux-mtd-bounces@lists.infradead.org
[mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Todd Poynor
Sent: Friday, July 15, 2005 12:59 AM
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: Re: NAND bbt build reads wrong oob data

Please don't do that. It's not only caught by the spam barriers, it's
also irrelevant and makes mail hard to read.

Read http://www.infradead.org/~dwmw2/email.html

This is volunteer work and we have therefor to insist on acceptance of
the rules for simple and efficient mail communication. 

We are really interested to improve the code and help users to fix their
problems, but we can only provide this _free of charge_ service when
those who take up the service cooperate on our simple and basic demands.

tglx

RE: NAND bbt build reads wrong oob data

[David Woodhouse]

On Fri, 2005-07-15 at 22:32 +0200, Thomas Gleixner wrote:
> On Fri, 2005-07-15 at 09:55 -0700, Martin Fouts wrote:
> > Sorry for the repeat, but mailman doesn't like my headers, but won't
> > tell me why, so I figured I send this direct. 

Your email program is broken. It doesn't include References: or
In-Reply-To: headers when you reply to a message, which breaks the
threading on the mailing list.

Please use a non-broken email program.

You last mail, which Thomas mistakenly approved instead of rejecting,
also quoted Todd's earlier mail _extremely_ unreadably. The part where
you quoted Todd looked like alternate lines of quotation and your own
text, like this...

> OK, this is pretty unexpected, so I'll try harder to figure out where
it goes wrong or whether 
> I've got another board that it affects (a colleague reported some new
bad blocks messages after 
> upgrading to the same software on a different board, will see if
there's a similar situation).

Please make at least a small amount of effort to communicate
effectively. We're not here just to try and filter through the dross
when you can't even be bothered to make yourself understandable in the
noise.
> 
-- 
dwmw2