From: Ivan Djelic <ivan.djelic@parrot.com>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: Vipin Kumar <vipin.kumar@st.com>,
Artem Bityutskiy <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 17:46:48 +0200 [thread overview]
Message-ID: <20110401154648.GA21475@parrot.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1104011653430.18181@lnxricardw.se.axis.com>
On Fri, Apr 01, 2011 at 03:58:47PM +0100, Ricard Wanderlof wrote:
>
> On Fri, 1 Apr 2011, Ivan Djelic wrote:
>
> >> I'm curious, if the OOB area is so unreliable, how can we trust it to
> >> store our ECC? We need a mini-ECC for the ECC then?
> >
> > The oob area is no different from the data area (same technology).
> > Fortunately, Hamming and BCH codes (and usual ECC codes in general) actually
> > have built-in robustness to corruption.
>
> At least with Hamming, when the ECC has been calculated, if it differs
> from the ECC read from the oob, and the difference is just a single bit,
> it is assumed that the ECC stored in the oob was subjected to a bitflip,
> and the data is in fact ok. (A long time ago there was a bug in this in
> mtd, so that a (single) bit flip in the ECC bytes was flagged as an ECC
> failure).
Exactly, because a single bitflip in data results in a 12-bit flip in a Hamming
24-bit code. Therefore you can easily distinguish a single bitflip in data
(12 bits change) from a single bitflip in the ECC code (1 bit change).
> I don't know how BCH (and other multiple-error-bit algorithms) deals with
> this though. Does it assume that there will be at most one bitflip within
> the ECC data (which is much smaller than the bytes covered by the ECC), or
> does it accept multiple bit errors also in the ECC data? One would assume
> that it would start to get difficult to distinguish multiple bit errors in
> the ECC data with valid ECC indicating bit errors in the data, but perhaps
> this isn't so thanks to the algorithm used?
With BCH and Reed-Solomon codes, data bytes and ecc bytes form a single
codeword. This whole codeword can be corrected, not just the data part.
Think of codewords as points in a space of binary words. In this space of
binary words, distance is measured as the number of differing bits between two
words.
A codeword has a remarkable property: it is distant from other codewords by at
least 2t+1 bits. You program the codeword to flash, and later read it back as a
(potentially) corrupted binary word. If you assume that this binary word is
distant from at most t bits from the original codeword (i.e. no more than t
bitflips occured in flash), then you can retrieve the original codeword (it is
the closest to your binary word).
The whole point of BCH (or RS) codes it to build such a codeword from the input
data, by adding the right ECC bits.
BR,
Ivan
next prev parent reply other threads:[~2011-04-01 15:47 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
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 [this message]
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=20110401154648.GA21475@parrot.com \
--to=ivan.djelic@parrot.com \
--cc=Artem.Bityutskiy@nokia.com \
--cc=David.Woodhouse@intel.com \
--cc=linux-mtd@lists.infradead.org \
--cc=ricard.wanderlof@axis.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox