NAND - u-boot ecc vs kernel ecc

David:

PSP user's guide discusses the two ECC layouts that are used by x-loader / u-boot and kernel/file system.

http://processors.wiki.ti.com/index.php/AM35x-OMAP35x-PSP_04.02.00.07_UserGuide#Selecting_ECC_algorithm

nandecc hw 1:

This is the ECC layout used to read/write the kernel and file system. The ECC bytes are at positions [40-51] in the OOB area.

nandecc hw 2:

This is the ECC layout used to read/write the xloader and uboot. The ECC bytes are at positions [2-13] in the OOB area.

Two layouts have to be used because the ROM code has to read the xloader and hence, the xloader has to have 'nandecc hw 2' layout. However, the same layout can't be used with file system because the ECC bytes then interfere with the bytes used to mark the JFFS2 related information for the file system. Thus 'nandecc hw 1' is used, where the ECC bytes are put at the end of the OOB area.

It looks like you have ECC parity written to both places in OOB.  Best to do an erase all and program NAND again from U-Boot.

Regards,

Michael T

PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

Hi,

Thanks for replying.

Looking at the dump made in U-boot (after erasing and writing the kernel partition), I can see ECC at offset [40-50] with 11 bytes.  But doing the same from the kernel, the ECC goes to offset [52-63] with 12 bytes.

The link you mentionned only gives the procedure for writing from U-Boot. I used the basic flash_eraseall / nandwrite from the kernel. Is this ok ?

The rootfs partition isn't read/write from U-Boot but only from the Kernel (update through a RamFS Kernel).

Regards

David

David:

PSP user guide referenced in previous post describes programming NAND from u-boot

including file system.   We currently have a problem with programming NAND using the

Linux kernel 2.6.37 as you indicated.

Regards,

Michael T

PS: Please mark this post as answered via the Verify Answer button below if you think it answers your question.  Thanks!

Hi Michael,

When will be a fix available ? Can I expect a fix for this issue too ?

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/115399.aspx

Regards

David

Hi,

Have you tried 4bit BCH ECC ?

For me, this worked .

1) I compiled kernel with 4bit BCH ECC.

2)Flashed the uImage.

3)Selected 4bit bch on u-boot [nandecc bch4_sw]

4)nand read at the kernel address.

Hi,

not tested. could be usefull as fallback, but  would prefer hw ecc. trying to get the status of this problem from TI.

Thanks for the info ! :-)

regards

David,

Sorry for delayed response,

I will update you once I validate this use-case.

Thanks,

Vaibhav

hi

I debugged and got it to work ;there are two issues here :

1) The ECC positions  as configured in the kernel is are at  byte-offsets 52 to 63 in the 64-byte OOB area, while for the u-boot ( when "nandecc hw 1" is selected which is default), the ECC positions are from 40 to 51 byte-offsets in the OOB. I'm not yet sure on which one to use.

2) the second issue is trivial - the ECC size config was being set improperly,  due to shifting of the value (by the feild-offset) twice, the patch is here (I'm not able to attach):

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1ed2648..d8d771d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -858,7 +858,7 @@ int gpmc_enable_hwecc(int ecc_type, int cs, int mode,
                         bch_mod = 1;
                         bch_wrapmode = 0x04;
                 } else
-                       eccsize1 = ((ecc_size >> 1) - 1) << 22;
+                       eccsize1 = ((ecc_size >> 1) - 1);
                 break;
 
         case GPMC_ECC_READSYN:
@@ -874,7 +874,7 @@ int gpmc_enable_hwecc(int ecc_type, int cs, int mode,
                         bch_mod = 1;
                         bch_wrapmode = 0x06;
                 } else
-                       eccsize1 = ((ecc_size >> 1) - 1) << 22;
+                       eccsize1 = ((ecc_size >> 1) - 1);
                 break;
 
         default:
--
1.7.1

Does anyone test the hardware ECC and software ECC nand flash throughput?

The test result is weird. SW ECC throughput is  more than HW ECC. And HW ECC with PIO mode is more than HW ECC with DMA mode.

The detail result is as below link.

http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/416/t/159484.aspx#579209

It's just test tool issue? or I mislead something?

Thanks help.

Hi Abhilash,

What was the solution for 1) that got things to work?

I too am having trouble with flash_eraseall/nandwrite (I applied the patch you provided).

Thanks,
...doug

I too applied Abhilash's patch and am still hitting the same compare error issue. I'm on DM3730 with 2.6.37 (using rowboat-android gingerbread 2.3.4 devkit 2.1) I posted it as a separate issue: http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/181553.aspx#654297