Problem with Micron 256 MB NAND on 440EPx

Problem with Micron 256 MB NAND on 440EPx

[Andrew E. Mileski]

I'm looking for some pointers in the right direction with this problem
I'm having with Micron 256 MB NAND part MT29F2G08AACWP:C with a JFFS2
filesystem on a AMCC PowerPC 440EPx board using the NDFC driver.

This NAND part has a 2 KB page size, 64 byte OOB area, 128 KB block
size.  I'm basically using the a stock Sequoia eval board code in a Denx
kernel, but with a 64 byte ECC layout copied from nand_oob_64 in
drivers/mtd/nand/nand_base.c

On any write over the 2 KB page size, the Linux kernel reports errors on
trying to verify 2 KB pages after the first.  It seems writes of 2 KB or
less are fine.

For example:
   dd if=/dev/urandom of=test bs=2k count=2

Write verify error (ECC correction failed) at 0e480000. Wrote:
00000000: 19 85 e0 02 00 00 04 44 c0 83 e7 3a 00 00 00 03
...
Read back:
00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
00000040: 19 85 e0 02 00 00 04 44 c0 83 e7 3a 00 00 00 03

Notice that the data appears to be "offset" by 64 bytes, which just
happens to be the size of the OOB, but that could be a coincidence.

I've tried increasing bus timings to max with no change in behavior.
Reducing NR_SCAN_PAGES to 1 from 4 in fs/jffs2/wbuf.c reduces the
"offset" to 28 bytes (I was seeing 152 byte OOB operations, which seemed
odd when there are only 64 bytes, so I tried this).

Also as a secondary problem, how do set the NAND_BBT_SCAN2NDPAGE flag?
I don't see how to reach the BBT option field via the structures passed
to platform_device_register().

Thanks.

-- 
Andrew E. Mileski

Re: Problem with Micron 256 MB NAND on 440EPx

[Andrew E. Mileski]

Andrew E. Mileski wrote:
> I'm looking for some pointers in the right direction with this problem
> I'm having with Micron 256 MB NAND part MT29F2G08AACWP:C with a JFFS2
> filesystem on a AMCC PowerPC 440EPx board using the NDFC driver.
> 
snip
> 
> Write verify error (ECC correction failed) at 0e480000. Wrote:
> 00000000: 19 85 e0 02 00 00 04 44 c0 83 e7 3a 00 00 00 03
> ...
> Read back:
> 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 00000040: 19 85 e0 02 00 00 04 44 c0 83 e7 3a 00 00 00 03
> 
> Notice that the data appears to be "offset" by 64 bytes, which just
> happens to be the size of the OOB, but that could be a coincidence.

I've now verified with a logic analyzer that the NFREN strobe is active 
during when NFRDYBSY is low (NAND chip is busy), and latching bogus data 
as a result (the bus has pull-ups so 0xff).

I've verified the pin is connected, and I have seen transitions on it 
through the PPC register.

Any suggestions on what I might be missing still?

Thanks.

-- 
Andrew E. Mileski

Re: Problem with Micron 256 MB NAND on 440EPx

[Alessandro Rubini]

> I've now verified with a logic analyzer that the NFREN strobe is active 
> during when NFRDYBSY is low (NAND chip is busy), and latching bogus data 
> as a result (the bus has pull-ups so 0xff).

I had a similar problem with the NDFC on an old kernel. I finally
tracked it down to a missing mb() (i.e. eieio on the ppc).  The
problem was triggered by DMA activity on the bus, but could also be
exposed by lowering NDFC speed.  The hw controller would thus check
the R/B* pin before the command reached the nand device, so it was not
busy (yet).  Since I was working with an old kernel and always tight
of time, I didn't check if the problem was still present in modern
code.

>From your description it looks like it's the same problem.
Back then, the fix was the following one on a 2.6.19.2 .

--- ./drivers/mtd/nand/ndfc.c	19 Mar 2007 09:53:08 -0000	1.1
+++ ./drivers/mtd/nand/ndfc.c	31 Aug 2007 15:40:48 -0000
@@ -76,6 +76,7 @@
 {
 	struct ndfc_controller *ndfc = &ndfc_ctrl;
 
+	wmb();
 	return __raw_readl(ndfc->ndfcbase + NDFC_STAT) & NDFC_STAT_IS_READY;
 }

Hope this helps
/alessandro

Re: Problem with Micron 256 MB NAND on 440EPx

[Andrew E. Mileski]

Alessandro Rubini wrote:
>> I've now verified with a logic analyzer that the NFREN strobe is active 
>> during when NFRDYBSY is low (NAND chip is busy), and latching bogus data 
>> as a result (the bus has pull-ups so 0xff).
> 
> I had a similar problem with the NDFC on an old kernel. I finally
> tracked it down to a missing mb() (i.e. eieio on the ppc).  The
> problem was triggered by DMA activity on the bus, but could also be
> exposed by lowering NDFC speed.  The hw controller would thus check
> the R/B* pin before the command reached the nand device, so it was not
> busy (yet).  Since I was working with an old kernel and always tight
> of time, I didn't check if the problem was still present in modern
> code.

I hadn't considered a sequencing problem.  I'll give your patch a try 
too.  Thanks!

I went back and noticed that tWB is hardcoded everywhere to 100ns (no 
define or config variable? *sigh*).  My chip can require up to 150ns.  I 
also increased a few other delays.  Those changes, plus the timeout 
calculation bug I posted on in another thread, and adding timeout 
expired warnings (previously silent errors), and it seems to be working 
at the moment.

I'll roll up a patch of it all when I'm satisfied with it after more 
testing.

-- 
Andrew E. Mileski