[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