dm8168 nand flash crc error

Xavier,

I don't think it is the real bad blocks that is causing this trouble. I believe its the wrong implementation of the BCH8 ecc algorithm that's causing this trouble.

Hi

Thank you for your replay!

This runs okay, but occasionally (~every 15 minutes) spits out the following:

Read of newly-erased block at <block address> failed: -74. Putting on bad_list
JFFS2: marking eraseblock at <block address> as bad,

i search this problem in e2e,

http://e2e.ti.com/support/embedded/linux/f/354/p/191572/866365.aspx#866365,

this problem has fixed in dvrrdk 3.0, but it does not  tell clearly how this problem solved,

only that " revert to 1-BIT ECC in UBOOT as well as in kernel (nand driver) to make it work."

however in the u-boot guide i found no 1-BIT ECC support,

I think it seems jffs2 does not support HW ECC 8,jffs2 has its own ecc,

i want to close the hw ecc in kernel,

but i am not clearly how to do this then?

I also read the release note for dvrrdk 3.0, it fixs this problem, and a web site is supplied as follow

http:/ / ap-fpdsp-swapps. dal. design. ti. com/ index. php/ DVR_RDK_V3. 0_GA_App_Notes_Flash_FS

but it can not access any more,

as we develop on dvrrdk2.8 for a long time ,we do not want to use dvrrdk3.0 to replace immediately ,

could you give me some help then ?

best regards

xavier

Xavier,

Its not really a fix. Its a workaround. Using 1-bit ECC will reduce your file system's data integrity. There are few issues in the implementation of BCH8. This can be fixed as well.

Hi Renjith ，

As you it will reduce file system's data integrity，how can i sovle this problem completely？

could you tell me how to set 1 bit ecc in kernel？

other way i want to try to close the hw ecc in kernel,

but i am not clearly how to do this then?

can you give me some help

best regards

xavier

Xavier,

Could you please send me the following files to renjith.thomas@pathpartnertech.com? Are you using the EVM or your own custom board?

arch/arm/mach-omap2/board-ti8168-evm.c or your board file?
arch/arm/mach-omap2/board-flash.c
arch/arm/mach-omap2/gpmc.c
drivers/mtd/nand/nand_base.c
drivers/mtd/nand/omap2.c

Hi Renjith:

i use my own board,

and i send the files to your mailbox with two different versions

best regards

xavier

Hi,

I think you should check OOB size of nand flash.

If nand flash have 64 bytes OOB, You can not BCH ecc with jffs2 file system.

Formally, TotaBCH ecc occupy 14bytes for each 512 bytes, therefore, 52 bytes for 2048bytes. by the way jffs2 clean marker use 8bytes. So, remain OOB is 52 bytes. this would be used BCH ecc. But, manufacturor use 2 bytes for bad block marker. This is lack of OOB used for BCH+jffs2.

So, you should 1 bit hamming ecc for jffs2 for 64bytes OOB.

BR,

Choi 

Xavier,

I haven't received the mail from you.

Choi,

1-bit will work fine. But is that sufficient for your system. Generally SLC NAND with 2K page size, the vendor recommends at least 4-bits of ECC. Considering this factor, 1-bit will be too much of a risk to take. This is my opinion. You can alternatively try to use a different file system like UBIFS which doesn't need so much space in spare area as well or try using BCH-4 to be on a safer side.

sorry, the mail has been snd back, as the attachments ,

and now i tried it again!