state of support for "external ECC hardware"

Ricard Wanderlof ricard.wanderlof at
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 

"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 

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 Wolf Wanderlöf                           ricardw(at)
Axis Communications AB, Lund, Sweden  
Phone +46 46 272 2016                           Fax +46 46 13 61 30

More information about the linux-mtd mailing list