All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: Huang Shijie <b32955@freescale.com>
Cc: Vikram Narayanan <vikram186@gmail.com>, linux-mtd@lists.infradead.org
Subject: Re: mtd_oobtest fails with GPMI-NAND
Date: Mon, 13 May 2013 11:22:17 +0200	[thread overview]
Message-ID: <5190B0C9.5000006@denx.de> (raw)
In-Reply-To: <5190ABF0.10501@freescale.com>

On 05/13/2013 11:01 AM, Huang Shijie wrote:
>> Please correct me if I'm wrong, but from my understanding the Linux GPMI
>> NAND driver configures the timings. So this is not board platform code
>> related but NAND driver related.
>>
>> Do you have any hints where to "tune/change" some values (timing or
>> signal related) to fix this error?
>>
> Please check the schematic, is there some pin conflict with the gpmi-nand?
> What's the pad value for these pins? You can take a reference with 
> current dts file.

We're currently using the same values as in imx6q-sabresd.dts. With this
addition:

+	soc {
+		nfc: gpmi-nand@00112000 {
+			status = "enabled";
+		};
+	};

to enable NAND support. So the pin muxing from imx6q.dtsi (gpmi-nand-1)
is used (which is what is also connected physically). Again, I don't
think that pin-muxing is our problem here.

>>> The key issue (i want to emphosis ) is that the current gpmi-nand does
>>> not support the
>>> subpage operations.
>> Yes. And this is disabled via setting NAND_NO_SUBPAGE_WRITE in the
>> options variable in the GPMI NAND driver.
>>
>> BTW: I just tested with the "mtd_nandbiterrs" test. This fails directly.
>> I would have expected the ECC to being able to at least correct the
>> errors for some loops:
>>
>> # insmod mtd_nandbiterrs.ko dev=3 mode=0

<snip>

>> Huang, is this to be expected? How does this look on one of your
>> officially "supported" imx6 boards with NAND support?
>>
> I suggest you do not use the mtd_nandbiterrs.ko. It will call the 
> mtd_write_oob() which will definitely lead to the
> -EBADMSG (-74) error.
> 
> The mtd_write_oob() in mtd_nandbiterrs.ko writes a whole page without 
> enabling the BCH to do the hardware ECC.
> But mtd_read() in mtd_nandbiterrs.ko DOES do the hardware ECC by the BCH.
> It's normal that you meet -74.

Okay. Thanks for the explanation.

> You can use the mtd_torturetest, such as:
> 
> #insmod mtd_torturetest.ko dev=3 check=1 cycles_count=1 eb=0 ebcnt=4 gran=1

Done. But no errors in this test though. Even with increasing the
cycles_count. I don't want to destroy this chip, so I'm not increasing
the cycles too much.

Which NAND devices did you test with on imx6? Did you also tests with a
"similar" Micron ONFI chip as this one (MT29F4G08ABADAH4)?

>> SLC. Why do you ask?
> For the MLC, if you write the OOB, it will impacts other part of the 
> page. For some nands, you will meet a -74.
> that's another story.

Thanks,
Stefan

  reply	other threads:[~2013-05-13  9:22 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-18 16:52 mtd_oobtest fails with GPMI-NAND Vikram Narayanan
2013-01-21  2:12 ` Huang Shijie
2013-01-28  2:39   ` Vikram Narayanan
2013-01-28  3:20     ` Huang Shijie
2013-01-28 17:04       ` Vikram Narayanan
2013-01-29  2:06         ` Huang Shijie
2013-01-29  2:26           ` Vikram Narayanan
2013-01-29  2:36             ` Huang Shijie
2013-01-29 16:28               ` Vikram Narayanan
2013-01-30  2:27                 ` Huang Shijie
2013-02-02  6:41                   ` Vikram Narayanan
2013-02-02  7:42                     ` Huang Shijie
2013-02-02  7:46                       ` Huang Shijie
2013-05-08 14:33                     ` Stefan Roese
2013-05-09 12:30                       ` Vikram Narayanan
2013-05-10  6:20                         ` Stefan Roese
2013-05-12 12:10                           ` Vikram Narayanan
2013-05-12 15:09                             ` Stefan Roese
2013-05-13 16:38                               ` Vikram Narayanan
2013-05-13  2:51                           ` Huang Shijie
2013-05-13  8:01                             ` Stefan Roese
2013-05-13  9:01                               ` Huang Shijie
2013-05-13  9:22                                 ` Stefan Roese [this message]
2013-05-13  9:34                                   ` Huang Shijie
2013-05-13 10:02                                     ` Stefan Roese
2013-05-14  2:09                                       ` Huang Shijie
2013-05-14  2:11                                       ` Huang Shijie
2013-05-13 16:51                                 ` Vikram Narayanan
2013-05-14  2:23                                   ` Huang Shijie
2013-05-14  2:33                                     ` Vikram Narayanan
2013-05-14  2:47                                       ` Huang Shijie
2013-05-13 16:43                               ` Vikram Narayanan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5190B0C9.5000006@denx.de \
    --to=sr@denx.de \
    --cc=b32955@freescale.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vikram186@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.