Single bit error correction on NAND.

Single bit error correction on NAND.

[DataCom - Virgílio]

I have noticed that NAND support on MTD can detect/correct single bit errors 
in 256 bytes, using software ECC. However, the correct data is not written 
back to flash. In other words, the bit stays "flipped" in flash. Isn't that 
dangerous? I mean, if another bitflip occurs in the same 256 bytes, we won't 
be able to correct by software ECC...

Am I missing something here? Thanks in advance.

-- 
Virgílio Silva

Re: Single bit error correction on NAND.

[Thomas Gleixner]

On Thu, 2005-07-28 at 16:40 -0300, DataCom - Virgílio wrote:
> I have noticed that NAND support on MTD can detect/correct single bit errors 
> in 256 bytes, using software ECC. However, the correct data is not written 
> back to flash. In other words, the bit stays "flipped" in flash. Isn't that 
> dangerous? I mean, if another bitflip occurs in the same 256 bytes, we won't 
> be able to correct by software ECC...
> 
> Am I missing something here?

Yes. 

It is not and can not be the responsibility of the NAND driver to handle
this. Where to should it write the data ? The existing data _cannot_ be
overwritten, without erasing the whole eraseblock and the implied risk
of loosing _ALL_ the data on the block due to a powerfail.

The NAND driver returns the corrected data and an appropriate error code
and the calling (e.g. filesystem) driver has to deal with the data
copying or whatever the developer has decided to be the correct
solution.

The NAND driver provides only the lowest level of access to the flash
device.

tglx

Re: Single bit error correction on NAND.

[DataCom - Virgílio]

On Thursday 28 July 2005 18:06, Thomas Gleixner wrote:
> On Thu, 2005-07-28 at 16:40 -0300, DataCom - Virgílio wrote:
> > I have noticed that NAND support on MTD can detect/correct single bit
> > errors in 256 bytes, using software ECC. However, the correct data is not
> > written back to flash. In other words, the bit stays "flipped" in flash.
> > Isn't that dangerous? I mean, if another bitflip occurs in the same 256
> > bytes, we won't be able to correct by software ECC...
> >
> > Am I missing something here?
>
> Yes.
>
> It is not and can not be the responsibility of the NAND driver to handle
> this. Where to should it write the data ? The existing data _cannot_ be
> overwritten, without erasing the whole eraseblock and the implied risk
> of loosing _ALL_ the data on the block due to a powerfail.
>
> The NAND driver returns the corrected data and an appropriate error code

Maybe I'm missing something, but the function nand_do_read_ecc returns 
-EBADMSG only if an uncorrectable error is detected by nand_correct_data. If 
just one bit is flipped, nand_correct_data corrects it, and nand_do_read_ecc 
returns 0.

> and the calling (e.g. filesystem) driver has to deal with the data
> copying or whatever the developer has decided to be the correct
> solution.

So it would be JFFS2 responsability to write back the correct data to flash, 
after a bit-flip is detected and corrected by the NAND driver. However, 
apparently it doesn't.

My question is: do you think it's safe to just leave the bit flipped in flash? 
I mean, everytime I try to read it, ECC will handle it. But what are the odds 
of another bit-flip in the same 256 bytes?

-- 
VIRGÍLIO Silva

Re: Single bit error correction on NAND.

[Thomas Gleixner]

On Thu, 2005-07-28 at 18:40 -0300, DataCom - Virgílio wrote:
> > It is not and can not be the responsibility of the NAND driver to handle
> > this. Where to should it write the data ? The existing data _cannot_ be
> > overwritten, without erasing the whole eraseblock and the implied risk
> > of loosing _ALL_ the data on the block due to a powerfail.
> >
> > The NAND driver returns the corrected data and an appropriate error code
> 
> Maybe I'm missing something, but the function nand_do_read_ecc returns 
> -EBADMSG only if an uncorrectable error is detected by nand_correct_data. If 
> just one bit is flipped, nand_correct_data corrects it, and nand_do_read_ecc 
> returns 0.

Damn, you're right. I check into this.

tglx