| Message ID | 804opb7d2y.fsf@merkur.tec.linutronix.de |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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
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);
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(-)