From: Ivan Djelic <ivan.djelic@parrot.com>
To: Vipin Kumar <vipin.kumar@st.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: Fri, 1 Apr 2011 14:14:47 +0200 [thread overview]
Message-ID: <20110401121447.GA19151@parrot.com> (raw)
In-Reply-To: <4D9595AB.1050604@st.com>
On Fri, Apr 01, 2011 at 10:06:51AM +0100, Vipin Kumar wrote:
> That's the problem. Ideally the ecc should have been programmed in OOB and then
> the driver would be able to correct the flipped bits. The problem happens only
> if we try to read the erased pages.
>
> >> Ideally, any filesystem would mark it as a bad block
> >
> > That's the point - no. This is normal on modern flashes.
> >
> > I think one solution could be that you make your check more
> > sophisticated. You check for 0xFFs, if this is not true, you see is this
> > "almost all 0xFFs" and count amount of non-0xFF bits. If the count is,
> > say, 2, you assume this page contains all 0xFFs plus 2 bit-flips. But
> > I'm not sure it would work.
> >
> > Anyway, If you do not care about such bit-flips for your SoC - fine. I
> > just wanted you to understand and accept the issue and write about it in
> > the comment. And I also wanted you to _not_ do expensive 0xFF comparison
> > every time - but it seems you accepted this :-)
> >
>
> Yes, I had to accept this :-)
> The flip side is that the hardware itself should not report errors when it
> reads all ff data and ff ecc..It should assume it as an erased page and not
> report any errors
Hello Vipin,
Did you consider this idea: if you have an unused byte available in oob,
program it to 0x00 when a page is programmed.
That way, you just need to check a single byte when you read a page in order
to distinguish erased pages from programmed pages. And by counting the number
of 1s in the byte, you can be robust to bitflips.
As a special refinement, you could also "cleanup" pages detected as erased, in
order to iron out possible bitflips.
I think that this method is used by Micron for their internal on-die ecc engine:
they add a parity byte (0x00 or 0x01) to their BCH code, which can be used to:
1) detect failures (using parity) when the max error count is reached
2) distinguish between erased and programmed pages
Best Regards,
Ivan
next prev parent reply other threads:[~2011-04-01 12:15 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
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 [this message]
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=20110401121447.GA19151@parrot.com \
--to=ivan.djelic@parrot.com \
--cc=Artem.Bityutskiy@nokia.com \
--cc=David.Woodhouse@intel.com \
--cc=linux-mtd@lists.infradead.org \
--cc=vipin.kumar@st.com \
--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 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.