state of support for "external ECC hardware"
Ricard Wanderlof
ricard.wanderlof at axis.com
Fri Nov 9 03:46:49 EST 2012
On Thu, 8 Nov 2012, Gerlando Falauto wrote:
>> We had BCH8 code running, but it wasn't enough. The main reason we
>> switched away from host side ECC was because we were getting bitflips
>> within the ECC codeword data itself.
>
> Wow... I mean, I figured it wouldn't be that easy to (purposedly) get
> bitflips in any area, I wonder what kind of test you managed to come up
> with in order to get bitflips within the ECC area itself. In my case it
> takes several hours (of continuous reads) to get a single bitflip within
> a 1Gb (128MB) flash.
There are 1Gb flashes and 1Gb flashes. Depending on the technology used
during manufacture (essentially the scale of the on-chip structures,
usually specified as 'xxx nm technology') the bit error probabilities can
vary.
"Traditional" 1Gb flashes where the manufacturer recommends 1-bit ECC in
practice very rarely exhibit bit flips. I have seen bit flips in the OOB
area as well as the main area (there was a bug in nand_ecc.c many years
ago which didn't handle this correctly which is how I discovered what was
going on); indeed there's nothing different about the OOB area in terms of
bit flips, it's just another area of (the same type of) flash. The
probability for the whole OOB area is of course less than for the rest as
it is smaller, but it is the same per bit if I understand it correctly.
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.
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.
/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