From: Ivan Djelic <ivan.djelic@parrot.com>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH/RFC v4 1/3] Shared BCH ECC library
Date: Tue, 29 Mar 2011 17:03:13 +0200 [thread overview]
Message-ID: <20110329150313.GA15405@parrot.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1103291534110.25520@lnxricardw.se.axis.com>
On Tue, Mar 29, 2011 at 02:55:19PM +0100, Ricard Wanderlof wrote:
> However, if I introduce a single bit error in the page, bch_decode() fails
> with -EBADMSG, and some further debugging reveals that
> bch.c:compute_error_locator_polynomial() returns 4 in this particular
> case, whereas bch.c:find_poly_roots() returns 0, the two don't match, and
> the function exits with an error. I'm no wizard with the algorithms used
> so i have no idea what is reasonable. I would assume both would return 1,
> as there is one bit error that I've introduced.
Yes you are correct, the computed error locator polynomial seems wrong, it
should be of degree 1.
> I've dumped the read and calculated ECC and it looks like they are being
> generated as expected; indeed, if there was a fault there reading ok pages
> would also fail.
>
> I'm a bit bewildered, as the algorithm appearently has been tested on a
> Mips (albeit under QEMU). Of course it's very likely that I've made a
> mistake somewhere, in that case it must be in the set-up, as the two files
> which actually implement the algorithm are new and not patches to existing
> files. I was thinking it was perhaps an endianess problem (our MIPS is
> little-endian), but I see it's been tested on x86 too so it shouldn't be
> that.
>
> Any ideas?
I should be able to help if you provide me with the following information:
- your patch against 2.6.35
- on an erased page, could you please program just the first byte to 0x7f (in
raw mode, no ecc), then read the page back normally with ecc, and dump the
calculated ecc ?
If you wish I can also send you the userland test suite that I use for
validation.
Best Regards,
--
Ivan
next prev parent reply other threads:[~2011-03-29 15:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-11 10:05 [PATCH/RFC v4 1/3] Shared BCH ECC library Ivan Djelic
2011-03-11 10:05 ` Ivan Djelic
2011-03-11 10:05 ` [PATCH/RFC v4 2/3] mtd: nand: add software BCH ECC support Ivan Djelic
2011-03-11 10:05 ` Ivan Djelic
2011-03-11 10:05 ` [PATCH/RFC v4 3/3] mtd: nand: enable software BCH ECC in nand simulator Ivan Djelic
2011-03-11 10:05 ` Ivan Djelic
2011-03-11 10:50 ` [PATCH/RFC v4 1/3] Shared BCH ECC library Artem Bityutskiy
2011-03-11 10:50 ` Artem Bityutskiy
2011-03-29 13:55 ` Ricard Wanderlof
2011-03-29 15:03 ` Ivan Djelic [this message]
2011-03-29 15:23 ` Ricard Wanderlof
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=20110329150313.GA15405@parrot.com \
--to=ivan.djelic@parrot.com \
--cc=linux-mtd@lists.infradead.org \
--cc=ricard.wanderlof@axis.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.