[PATCH/RFC v4 1/3] Shared BCH ECC library
Ricard Wanderlof
ricard.wanderlof at axis.com
Tue Mar 29 11:23:13 EDT 2011
On Tue, 29 Mar 2011, Ivan Djelic wrote:
> 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 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.
Thanks for your quick reply.
However, I think I may have found the source of my problem, I think i'm
doing something wrong when forcing bit errors using nandwrite with an
image containing an oob, so I in fact introduce a wrong ECC. I found this
out by trying the same scenario using the standard 1-bit ECC algorithm,
which also fails in much the same way.
Sorry for the confusion.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
More information about the linux-mtd
mailing list