Problem with Micron 256 MB NAND on 440EPx

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

snip

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

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.

Back then, the fix was the following one on a 2.6.19.2 .

@@ -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

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