public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Vipin Kumar <vipin.kumar@st.com>
To: Ivan Djelic <ivan.djelic@parrot.com>
Cc: "Artem.Bityutskiy@nokia.com" <Artem.Bityutskiy@nokia.com>,
	Viresh KUMAR <viresh.kumar@st.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"David.Woodhouse@intel.com" <David.Woodhouse@intel.com>
Subject: Re: [PATCH] Newly erased page read workaround
Date: Thu, 24 Feb 2011 17:06:10 +0530	[thread overview]
Message-ID: <4D6642AA.9090505@st.com> (raw)
In-Reply-To: <20110224111021.GA8650@parrot.com>

On 2/24/2011 4:40 PM, Ivan Djelic wrote:
> On Thu, Feb 24, 2011 at 10:20:59AM +0000, Vipin Kumar wrote:
>> On 2/24/2011 3:08 PM, Ivan Djelic wrote:
> (...)
>>> Just a suggestion: maybe you could mention in your comments the fact that you
>>> cannot workaround the problem using a mask to get a valid ECC on erased pages,
>>> because your controller does not allow it ?
>>>
>>> If you plan to use your workaround on recent NAND devices with UBIFS, you may
>>> still experience problems because of uncorrected bitflips on erased pages, and
>>> get errors such as:
>>>
>>
>> Let me explain the problem again.
>>
>> The problem is that the BCH algorithm (used by this controller to generate ecc 
>> and correct bitflips) generates an ecc which is not 0xffff for an erased 512 
>> bytes.
>>
>> Since erasing a page results in all data including the spare area of the page 
>> resetting to 0xffff, and the ecc written in the spare area is incorrect.
>> This ecc is not useful to correct bitflips
>>
>> One way to solve this problem is to write the correct ecc in the erased pages 
>> spare area. The other is to ensure that the page is erased and not run the 
>> correction algorithm.
> 
> There is a third option: add (before writing oob/after reading oob) a fixed
> polynomial to your HW-generated BCH ECC codeword. This polynomial is chosen such
> that your ECC code on an erased page now becomes a sequence of 0xff bytes.
> That way, erased pages can be read with ECC check enabled. That was my point.
> 
> I assume you cannot alter oob contents as described above, because your controller
> performs error detection "on-the-fly" as you transfer data to/from NAND device (?).
> 

This is true. the controller performs the error detection on the fly ie. as the cpu 
reads the oob bytes
The expectation of the controller is

1. reset ecc logic
2. start reading 512 bytes + 13 bytes (ecc - lying in oob)
3. the controller would provide the information about flipped bit offsets

This is the reason that the above option would not work

>> We are using the second option but there would not be 
>> any unwanted bitflips in any of the cases.
> 
> On recent NAND devices, bitflips _do_ appear on erased pages, sometimes immediately
> after a block erase.
> 
> Regards,
> 
> Ivan
> .
> 

Regards
Vipin

  reply	other threads:[~2011-02-24 11:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-24  6:10 [PATCH] Newly erased page read workaround Viresh Kumar
2011-02-24  9:38 ` Ivan Djelic
2011-02-24 10:20   ` Vipin Kumar
2011-02-24 11:10     ` Ivan Djelic
2011-02-24 11:36       ` Vipin Kumar [this message]
2011-03-22  4:36 ` viresh kumar
2011-03-31 13:51 ` Artem Bityutskiy
2011-04-01  6:28   ` Vipin Kumar
2011-04-01  6:51     ` Artem Bityutskiy
2011-04-01  8:33       ` Vipin Kumar
2011-04-01  8:39         ` Artem Bityutskiy
2011-04-01  9:06           ` Vipin Kumar
2011-04-01  9:42             ` Artem Bityutskiy
2011-04-01 12:14             ` Ivan Djelic
2011-04-01 13:04               ` Artem Bityutskiy
2011-04-01 14:04                 ` Ivan Djelic
2011-04-01 14:16                   ` Artem Bityutskiy
2011-04-01 14:49                     ` Ivan Djelic
2011-04-01 14:58                       ` Ricard Wanderlof
2011-04-01 15:46                         ` Ivan Djelic
2011-04-01 16:09                     ` Ivan Djelic
2011-04-01 16:16                       ` Artem Bityutskiy

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=4D6642AA.9090505@st.com \
    --to=vipin.kumar@st.com \
    --cc=Artem.Bityutskiy@nokia.com \
    --cc=David.Woodhouse@intel.com \
    --cc=ivan.djelic@parrot.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=viresh.kumar@st.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox