Re: state of support for "external ECC hardware"

[Gerlando Falauto <gerlando.falauto@keymile.com>]

Hi everyone,

first of all I am very grateful for your feedback. Thanks a lot to all 
of you!!

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
> rate.

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 
understanding correct?

Thank you again,
Gerlando




>
> /Ricard