* [PATCH] mxc_nand: i.MX35 hardware ECC fixups
@ 2009-11-03 17:06 John Ogness
[not found] ` <528f13590911071823sa26e1ane027d51d16357c79@mail.gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: John Ogness @ 2009-11-03 17:06 UTC (permalink / raw)
To: linux-mtd; +Cc: s.hauer
This patch is against the recently posted patches from Sascha Hauer
(21 Oct 2009 mxc_nand). This patch does the following:
- fixes ECC hardware error detection for the i.MX35
- sets up an appropriate ECC mode (4-bit) for the i.MX35
- configures the spare area size for the i.MX35
I tested this patch with ubifs on an i.MX35 PDK board.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
---
mxc_nand.c | 35 ++++++++++++++++++++++++++++++-----
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index d5445cd..de056aa 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -86,6 +86,7 @@
* Status operation */
#define NFC_INT 0x8000
+#define NFC_ECC_4BIT (1 << 0)
#define NFC_SP_EN (1 << 2)
#define NFC_ECC_EN (1 << 3)
#define NFC_INT_MSK (1 << 4)
@@ -351,11 +352,25 @@ static int mxc_nand_correct_data(struct mtd_info *mtd, u_char *dat,
*/
uint16_t ecc_status = readw(host->regs + NFC_ECC_STATUS_RESULT);
- if (((ecc_status & 0x3) == 2) || ((ecc_status >> 2) == 2)) {
- DEBUG(MTD_DEBUG_LEVEL0,
- "MXC_NAND: HWECC uncorrectable 2-bit ECC error\n");
- return -1;
- }
+ if (nfc_is_v21()) {
+ if ((ecc_status & 0xf) > 1 ||
+ ((ecc_status >> 4) & 0xf) > 1 ||
+ ((ecc_status >> 8) & 0xf) > 1 ||
+ ((ecc_status >> 12) & 0xf) > 1) {
+ DEBUG(MTD_DEBUG_LEVEL0,
+ "MXC_NAND: "
+ "HWECC uncorrectable 2-bit ECC error\n");
+ return -1;
+ }
+ } else if (nfc_is_v1()) {
+ if (((ecc_status & 0x3) == 2) || ((ecc_status >> 2) == 2)) {
+ DEBUG(MTD_DEBUG_LEVEL0,
+ "MXC_NAND: "
+ "HWECC uncorrectable 2-bit ECC error\n");
+ return -1;
+ }
+ } else
+ BUG();
return 0;
}
@@ -756,6 +771,8 @@ static int __init mxcnd_probe(struct platform_device *pdev)
tmp = readw(host->regs + NFC_CONFIG1);
tmp |= NFC_INT_MSK;
tmp &= ~NFC_SP_EN;
+ if (nfc_is_v21())
+ tmp |= NFC_ECC_4BIT;
writew(tmp, host->regs + NFC_CONFIG1);
init_waitqueue_head(&host->irq_waitq);
@@ -773,6 +790,14 @@ static int __init mxcnd_probe(struct platform_device *pdev)
/* Unlock the internal RAM Buffer */
writew(0x2, host->regs + NFC_CONFIG);
+ if (nfc_is_v21()) {
+ /* configure spare size (in 16-bit blocks) */
+ tmp = readw(host->regs + NFC_RSLTSPARE_AREA);
+ tmp &= ~0xff;
+ tmp |= host->spare_len / 2;
+ writew(tmp, host->regs + NFC_RSLTSPARE_AREA);
+ }
+
/* Blocks to be unlocked */
if (nfc_is_v21()) {
writew(0x0, host->regs + NFC_V21_UNLOCKSTART_BLKADDR);
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] mxc_nand: i.MX35 hardware ECC fixups
[not found] ` <80y6mg5e34.fsf@merkur.tec.linutronix.de>
@ 2009-12-12 23:58 ` alfred steele
2009-12-13 14:00 ` Eric Bénard
2009-12-13 14:36 ` John Ogness
0 siblings, 2 replies; 4+ messages in thread
From: alfred steele @ 2009-12-12 23:58 UTC (permalink / raw)
To: John Ogness; +Cc: linux-mtd
Hi John/Stephanie,
> The patch sets a few registers that Sascha's patches forgot. It also
> correctly notices if there were ECC errors. Without the patch, most ECC
> errors will go unnoticed.
I am having a issue with using nandwrite mtd util and it so happens
that the nandwrite gets stuck at a particular block and the sonsole
hangs there forever.
We are using the mx27(mxc) with a large size page NAND(4k). The annd
write suceeds for the kernel MTD parition. I am suspecting my NAND
driver is somehow obsolete. How do i find out as to what could be the
root cause of the problem?
What could be the pest debugging path?
Cheers,
Alfred.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mxc_nand: i.MX35 hardware ECC fixups
2009-12-12 23:58 ` alfred steele
@ 2009-12-13 14:00 ` Eric Bénard
2009-12-13 14:36 ` John Ogness
1 sibling, 0 replies; 4+ messages in thread
From: Eric Bénard @ 2009-12-13 14:00 UTC (permalink / raw)
To: alfred steele; +Cc: linux-mtd
Hi Alfred,
alfred steele a écrit :
> I am having a issue with using nandwrite mtd util and it so happens
> that the nandwrite gets stuck at a particular block and the sonsole
> hangs there forever.
> We are using the mx27(mxc) with a large size page NAND(4k). The annd
> write suceeds for the kernel MTD parition. I am suspecting my NAND
> driver is somehow obsolete. How do i find out as to what could be the
> root cause of the problem?
are you sure the i.MX27's NAND controler supports 4k NAND ?
From the Reference Manual is only support 512 & 2k :
The NFC interfaces standard NAND Flash devices to the IC and hides the
complexities of accessing the NAND Flash. It provides a glueless
interface to both 8-bit and 16-bit NAND Flash parts with page sizes
of 512 bytes or 2 Kbytes, and densities up to 64 Gbits per 2-Kbyte page
size NAND Flash, and 8 Gbits per 512 byte page size NAND Flash.
There is no mention of 4k NAND and the NFC's RAM buffer is only 2k + 64
which may be not enough for 4k NAND (the v2 NFC has 4k + 512 and support
4k).
Eric
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mxc_nand: i.MX35 hardware ECC fixups
2009-12-12 23:58 ` alfred steele
2009-12-13 14:00 ` Eric Bénard
@ 2009-12-13 14:36 ` John Ogness
1 sibling, 0 replies; 4+ messages in thread
From: John Ogness @ 2009-12-13 14:36 UTC (permalink / raw)
To: alfred steele; +Cc: linux-mtd
Hi Alfred,
On 2009-12-13, alfred steele <alfred.jaquez@gmail.com> wrote:
> I am having a issue with using nandwrite mtd util and it so happens
> that the nandwrite gets stuck at a particular block and the sonsole
> hangs there forever.
>
> We are using the mx27(mxc) with a large size page NAND(4k). The annd
> write suceeds for the kernel MTD parition. I am suspecting my NAND
> driver is somehow obsolete. How do i find out as to what could be the
> root cause of the problem?
>
> What could be the pest debugging path?
You may want to consider setting the kernel option MTD_DEBUG and setting
MTD_DEBUG_VERBOSE to 3 (noisy). It will generate a _lot_ of output on
the console, but may help you to identify where it is hanging.
John Ogness
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-12-13 14:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-03 17:06 [PATCH] mxc_nand: i.MX35 hardware ECC fixups John Ogness
[not found] ` <528f13590911071823sa26e1ane027d51d16357c79@mail.gmail.com>
[not found] ` <80y6mg5e34.fsf@merkur.tec.linutronix.de>
2009-12-12 23:58 ` alfred steele
2009-12-13 14:00 ` Eric Bénard
2009-12-13 14:36 ` John Ogness
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox