state of support for "external ECC hardware"
gerlando.falauto at keymile.com
Mon Nov 12 12:19:57 EST 2012
first of all I am very grateful for your feedback. Thanks a lot to all
On 11/09/2012 09:46 AM, Ricard Wanderlof wrote:
> Some manufacturers (Micron for instance I believe) have started to deliver
> 1 Gb chips using a higher density technology where they specify a
> requirement for 4-bit ECC. These naturally exhibit a much higher bitflip
Would there be any reason *NOT* to use 4-bit ECC with parts which do not
require it? Apart from performance, of course.
I mean, we need to be as flexible as possible as far as hardware parts
are concerned, as long as the basic requirements are met.
So we would like to have a single kernel which can run on different
flash parts, past, present, and (as far as we can predict) future.
As pointed out within this thread, dynamic detection might be a bit
tricky, so perhaps finding a common solution might be a good compromise.
> At any rate, the ECC algorithm itself should be able to take care of bit
> flips in the ECC codes. For the 1-bit algorithm in nand_ecc.c it does this
> by comparing the computed ECC with the actual ECC; if there's a difference
> of exactly one bit (rather than a more complex diff which after
> calculations points out the flipped bit in the main area), it is assumed
> that the bitflip is in the ECC area rather than the data. I don't know how
> BCH does this though.
Ivan, I came to understand (but I am not sure), that the implementation
you provided (and currently mainlined) *DOES* handle this correctly. It
was instead an old one which did not handle this properly. Is my
Thank you again,
More information about the linux-mtd