Write JFFS2 Image to NAND on UBOOT

Hi,

This may be due to the different ECC layouts being followed by u-boot and Linux Kernel. Latest u-boot/kernel follow the same ECC layout and hence these kind of errors are not observed. You can refer to the source code of latest u-boot/kernel and try to port them back to u-boot/kernel, you are using.

Regards, Sudhakar

Hi,

Thank you for the reply...

Since I recently move to the arago uboot v2010.09 and using it with my old mvl_4.0.1 based kernel, it would be logical to change my kernel source. 

How can I learn the most suitable kernel source tree with v2010.09 uboot?

Can you give me where I should look for in source tree for back-porting ECC code? Is it also related to the JFFS2 code? Because I can succesfully write uImage and ramdisk.gz files on Uboot but not jffs2 image. 

Regards,

Ferhat

Can you provide the version number where u-boot was changed to be compatible with kernel ECC?  I'm using DVSDK_4_00_00_22 distribution and this is not the case.

John A

Dear John,

I could not understand which version number you want me to provide but I can say that I have never used a compatible uboot-kernel pair for this jffs2 image write issue.

Previously I was using DVSDK_1_30_01_41 with uboot-1.2.0 in PSP_01_20_00_014.  There were ECC errors while mounting a uboot written jffs2 images.

Now I move on to arago uboot v2010.09 for a NAND usage optimization. And the same problem still exist.

I hope I can answer ypur question.

Ferhat

Sudhakar said:

Latest u-boot/kernel follow the same ECC layout and hence these kind of errors are not observed. You can refer to the source code of latest u-boot/kernel and try to port them back to u-boot/kernel, you are using.

Hi,

Linux Kernel - 2.6.32-rc2, file: driverd/mtd/nand/davinci_nand.c

500 /* An ECC layout for using 4-bit ECC with large-page (2048bytes) flash,
501  * storing ten ECC bytes plus the manufacturer's bad block marker byte,
502  * and not overlapping the default BBT markers.
503  */
504 static struct nand_ecclayout hwecc4_2048 __initconst = {
505         .eccbytes = 40,
506         .eccpos = {
507                 /* at the end of spare sector */
508                 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
509                 34, 35, 36, 37, 38, 39, 40, 41, 42, 43,
510                 44, 45, 46, 47, 48, 49, 50, 51, 52, 53,
511                 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
512                 },
513         .oobfree = {
514                 /* 2 bytes at offset 0 hold manufacturer badblock markers */
515                 {.offset = 2, .length = 22, },
516                 /* 5 bytes at offset 8 hold BBT markers */
517                 /* 8 bytes at offset 16 hold JFFS2 clean markers */
518         },
519 };

U-Boot version 2009.03, file:driverd/mtd/nand/davinci_nand.c

 384 #ifdef CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
 385 static struct nand_ecclayout nand_davinci_4bit_layout_oobfirst = {
 386 #ifdef CONFIG_SYS_NAND_PAGE_2K
 387         .eccbytes = 40,
 388         .eccpos = {
 389                 24, 25, 26, 27, 28,
 390                 29, 30, 31, 32, 33, 34, 35, 36, 37, 38,
 391                 39, 40, 41, 42, 43, 44, 45, 46, 47, 48,
 392                 49, 50, 51, 52, 53, 54, 55, 56, 57, 58,
 393                 59, 60, 61, 62, 63,
 394                 },
 395         .oobfree = {
 396                 {.offset = 2, .length = 22, },
 397         },

If you are using 4-bit ECC support on DM365 (which is the default mode) then as you can see from above, both U-Boot and Linux Kernel are using same ECC layouts. Here both U-Boot and Kernel are taken from PSP r37 release available at http://arago-project.org/files/releases/davinci-psp_3.x.0.0-r37/sources/. AFAIK, DVSDK_4_00_00_22 is using the same PSP release.

Regards, Sudhakar

Sudhakar said:

If you are using 4-bit ECC support on DM365 (which is the default mode)

What is the issue in DM644x?  I read a lot from E2E forums but could not conclude ? Are there any ECC compatible  kernel -uboot pair for DM644x?

Regards,

Ferhat