New NAND flash die rev recommends 4 bit ECC

New NAND flash die rev recommends 4 bit ECC

[Tim Barr]

I just got a notice from Micron that they are making changes to the
29F2G08/16 (2 Gbit SLC device). For instance, the 29F2G0816AAD is going
EOL this month and is being replaced by the MT29F2G08ABAEA. The problem
is that the new data sheet is recommending 4 bit per 526 byte ECC
instead of 1 bit per 526 byte ECC. As far as I can tell, the processor
we are using (AT91SAM9G20) only does 1 bit HW ECC and the software ECC
code for MTD is also 1 bit. The new NAND Flash die does have a HW 4 bit
ECC engine added in, which probably would need to have code written to
support it in order to be able to use it.

So, is anyone working on a 4 bit software ECC code or code modifications
to utilize the on chip HW ECC engine?

Right now we can use a part from an alternate vendor or do a lifetime
buy, but I am wondering if this is a trend as die size shrinks and other
vendors will soon require higher level ECC as well.

Tim Barr 
Development Engineer 
Multi-Tech Systems, Inc. 
 

Re: New NAND flash die rev recommends 4 bit ECC

[twebb]

> I just got a notice from Micron that they are making changes to the
> 29F2G08/16 (2 Gbit SLC device). For instance, the 29F2G0816AAD is going
> EOL this month and is being replaced by the MT29F2G08ABAEA. The problem
> is that the new data sheet is recommending 4 bit per 526 byte ECC
> instead of 1 bit per 526 byte ECC. As far as I can tell, the processor
> we are using (AT91SAM9G20) only does 1 bit HW ECC and the software ECC
> code for MTD is also 1 bit. The new NAND Flash die does have a HW 4 bit
> ECC engine added in, which probably would need to have code written to
> support it in order to be able to use it.
>
> So, is anyone working on a 4 bit software ECC code or code modifications
> to utilize the on chip HW ECC engine?
>
> Right now we can use a part from an alternate vendor or do a lifetime
> buy, but I am wondering if this is a trend as die size shrinks and other
> vendors will soon require higher level ECC as well.

Yes, I believe this is a trend.

Since the new part has on-board ECC, can you just configure your NAND
controller to NOT use ECC?  Then, in theory, it's business as usual
but you just won't ever get any correctable or uncorrectable bit
errors when you read the flash because the on-board ECC will handle
it.

twebb

Re: New NAND flash die rev recommends 4 bit ECC

[Peter Barada]

On 01/06/2011 08:08 PM, twebb wrote:
>> I just got a notice from Micron that they are making changes to the
>> 29F2G08/16 (2 Gbit SLC device). For instance, the 29F2G0816AAD is going
>> EOL this month and is being replaced by the MT29F2G08ABAEA. The problem
>> is that the new data sheet is recommending 4 bit per 526 byte ECC
>> instead of 1 bit per 526 byte ECC. As far as I can tell, the processor
>> we are using (AT91SAM9G20) only does 1 bit HW ECC and the software ECC
>> code for MTD is also 1 bit. The new NAND Flash die does have a HW 4 bit
>> ECC engine added in, which probably would need to have code written to
>> support it in order to be able to use it.
>>
>> So, is anyone working on a 4 bit software ECC code or code modifications
>> to utilize the on chip HW ECC engine?
>>
>> Right now we can use a part from an alternate vendor or do a lifetime
>> buy, but I am wondering if this is a trend as die size shrinks and other
>> vendors will soon require higher level ECC as well.
> Yes, I believe this is a trend.
>
> Since the new part has on-board ECC, can you just configure your NAND
> controller to NOT use ECC?  Then, in theory, it's business as usual
> but you just won't ever get any correctable or uncorrectable bit
> errors when you read the flash because the on-board ECC will handle
> it.
Yes you can, at least on OMAP35x.

We're using a MT29C2G224MAKLAJG POP NAND/DDR in a OMAP35x design and its 
required a fair bit of work to integrate the NAND into the MTD layer.  
Once a read command is executed and the NAND is ready to return the 
data, a status command is required to determe if there's a hard/soft ECC 
error but on the soft there's no indication of the number of bits that 
required correction.  Worse the ECC in the OOB (on a 2KB/64 byte part) 
leaves only 16 bytes(corrected) out of the 64 byte spare area avaliable 
for meta data, barely enough for YAFFS2 to work (had to turn off tags 
ECC to have enough space to make it work (and the metadata in those 16 
bytes is already ECC'd)).

Unfortunately we're seeing a soft ECC rate of somewhere around 1E-10 
(far less than the assumed 10E-16 error rate for SLC NAND), enough that 
leads YAFFS2 to retire blocks waaaaay too quickly.  We've worked around 
it so far by raising the "strike count" in YAFFS2 to not retire blocks 
too quickly, but the proper fix is to modify the NAND driver to re-read 
the page w/o ECC on a soft ECC error and count the bit errors by hand 
(since it already has the corrected data available) - something I 
haven't coded up yet.
> twebb
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: New NAND flash die rev recommends 4 bit ECC

[Ivan Djelic]

On Thu, Jan 06, 2011 at 09:34:31PM +0000, Tim Barr wrote:
> I just got a notice from Micron that they are making changes to the
> 29F2G08/16 (2 Gbit SLC device). For instance, the 29F2G0816AAD is going
> EOL this month and is being replaced by the MT29F2G08ABAEA. The problem
> is that the new data sheet is recommending 4 bit per 526 byte ECC
> instead of 1 bit per 526 byte ECC. As far as I can tell, the processor
> we are using (AT91SAM9G20) only does 1 bit HW ECC and the software ECC
> code for MTD is also 1 bit. The new NAND Flash die does have a HW 4 bit
> ECC engine added in, which probably would need to have code written to
> support it in order to be able to use it.
> 
> So, is anyone working on a 4 bit software ECC code or code modifications
> to utilize the on chip HW ECC engine?

Hello Tim,

I am currently working on a generic software BCH encoder/decoder that can
handle modern NAND ECC requirements (4 bits, or actually any number of bits per
any number of bytes). This BCH engine can also to be used on "hybrid" systems
in which a NAND controller can compute BCH parity bits (such as OMAP3630 GPMC),
but is not able to perform error correction (which is quite more involved than
Hamming 1 bit correction).

If you need to use the on-die ecc of your NAND device, this wiki has a few
interesting bits: http://processors.wiki.ti.com/index.php/GPMC_ECC
One of the main issues is spare area utilization: if you plan to use YAFFS2,
you'll need to squeeze its metadata into the remaining available spare space
once the NAND on-die ecc is enabled (still possible with 4bit ecc, probably
impossible with 8bit ecc ?). An alternative is to use UBIFS, as it does not
store any information in spare area.
BR,

Ivan