This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

jffs2 ECC errors

The short question is: I understand that the jffs2 filesystem must match what the kernel expects.  Does anyone know which parameters I should be looking at in my kernel source to be certain I am creating a compatible jffs2?  I suspect that a mismatch is my problem...

The long of it:

I have successfully loaded x-loader, u-boot, and various kernels onto our custom device but I'm having some issues loading the jffs2 filesystem with the kernel.  I have to upload the rootfs.jffs2 via u-boot and gkermit (same as I do the kernel), instead of the "preferred" way of using MTD drivers from inside linux (because this device has no MMC or other way to boot linux).  As the kernel boots, it spits out a slew of ECC errors:

Example message for 2.6.36-rc1 kernel:

[  171.528106] UNCORRECTED_ERROR default
[  171.532379] Correcting single bit ECC error at offset: 178, bit: 2
[  171.570739] ECC UNCORRECTED_ERROR B

-------------------------------------------------------------------------------------

Example messages for 2.6.29-omap1 kernel:

[   21.668548] CLEANMARKER node found at 0x00ae0000 has totlen 0xc != normal 0x0
[   23.471618] JFFS2 notice: (1) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[   23.492156] VFS: Mounted root (jffs2 filesystem) on device 31:4.
[   23.498474] Freeing init memory: 204K
[   23.543090] Erase at 0x06f40000 failed immediately: errno -5
...

[   34.726928] Erase at 0x01500000 failed immediately: errno -5
[   34.741577] jffs2_flush_wbuf(): Write failed with -5
[   34.746856] Write of 178 bytes at 0x00ae77d8 failed. returned -5, retlen 0
[   34.753753] Not marking the space at 0x00ae77d8 as dirty because the flash driver returned retlen zero
...

[   41.589691] Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is 0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
[   41.603576] Failed to allocate space for wbuf recovery. Data loss ensues.
[   41.610443] Write of 178 bytes at 0x06f60794 failed. returned -5, retlen 0
[   41.617370] Not marking the space at 0x06f60794 as dirty because the flash driver returned retlen zero
[   41.627258] Unable to handle kernel NULL pointer dereference at virtual address 00000024

-------------------------------------------------------------------------------------

FYI: Here is how I load the filesystem from u-boot:

mw.b 90000000 0 F980000 # blanking RAM, probably not needed

loadb 90000000  # kermit rootfs.jffs2

mtdparts default  # fs is at 0x680000, length: 0xF980000
nand unlock fs
nandecc sw
nand erase fs
nand write.jffs2 90000000 fs AE7000 # AE7000 is the length rounded up to the nearest page 4096 (0x1000). Issue?
nand lock

 

 

  • Or should I be asking how the kernel determines the expected jffs2 parameters?  From u-boot?

     

  • Using `mkfs.jffs2 -n` gets rid of the Cleanmarker messages.

    I have gotten the 2.6.29-omap1 kernel to load a 10M jffs2 filesystem without complaint.

    The 2.6.36-rc1 kernel complains about the usual ECC errors with the same 10M filesystem.

    So I guess the problem has something to do with kernel options or kernel source code.

     

     

  • I did/do have also problems with flash. I get off the uncorrectable error messages with inlcuding a patch in nand_base.c. Check the changes from version 05 to 06 (PSP).

    Nevertheless I do have some other messages, as "Empty flash at", and some jffs_scan_ ... an notice .

     

  • The problem was that someone hard-coded hardware ECC in drivers/mtd/nand/omap2.c

    The solution was to remove this:

    #define CONFIG_MTD_NAND_OMAP_HWECC

    Perhaps this would not have been an issue if the OMAP could handle the HW ECC.  There's some errata about certain chips not be able to handle 3bit HW ECC.