uncorrectable error : with mtd nand

I am using 3.2.16 kernel and trying to write my filesystem to nand.

I have tried JFFS2, UBIFS and YAFFS2 but all experience the same issue - which makes me think that the issue is with the mtd driver.

It worked with my old kernel 3.0.7 but no longer works with 3.2.16.

After boot I get the following message and then the unit becomes very unstable… varies with each boot.
uncorrectable error :

I read in a forum:

It sounds like your MTD driver isn’t setup correctly. It could be
either your u-boot or linux MTD driver where one is writing with an ECC
method that is different than what the other is reading.

how do you write you images to NAND? THere are mtd-utils specially
created for this purpose

I am using mtd-utils 1.4.9-r1 from the Angstrom repo.
I use:

flash_erase /dev/mtd4 0 0

ubiattach /dev/ubi_ctrl -m 4
ubimkvol /dev/ubi0 -N rootfs -s 240MiB
mount -t ubifs ubi0:rootfs /mnt/flash
cd /mnt/flash
tar xvpjf /rootfs.tar.bz2 -C /mnt/flash/
cd …
umount /mnt/flash/

Then add this to my boot cmd:
bootargs ‘console=ttyO2,115200n8 ubi.mtd=4 root=ubi0:rootfs rootwait rootfstype=ubifs ro’

Sometimes it boots fine.
Sometimes I get a bunch of these error messages:

uncorrectable error :
Sometimes it fails to boot with a kernel panic.

Doesn’t matter if the file system type is Yaffs2, JFFS2 or UBIFS I get the same "uncorrectable error : "
This makes me think after reading on the net that there is an ECC problem between the driver and uboot? or maybe my board file?

Any help would be much appreciated!


How does relate to u-boot if you pass arguments to the kernel?

I guessed it was probably not uboot… thanks for the confirmation.
Is this likely to be an mtd driver issue that I will have to wait to be patched in the next kernel release?

I would stay on the stable kernel release

Yeah - it is a stable release kernel.
I understand that the nand system is being completely re-written and will be introduced 3.5

Still having issues with this problem…

Further information:

flash_erase /dev/mtd4 0 0

Erasing 128 Kibyte @ 4e0000 – 1 % complete flash_erase: Skipping bad block at 00500000
Eras[ 17.944488] nand_erase_nand: attempt to erase a bad block at page 0x00003c00
Erasing 128 Kibyte @ 1440000 – 8 % complete flash_erase: Skipping bad block at 01460000
Erasing 128 Kibyte @ 1500000 – 8 % complete flash_erase: Skipping bad block at 01520000
Erasing 128 Kibyte @ 15c0000 – 8 % complete flash_erase: Skipping bad block at 015e0000
Erasing 128 Kibyte @ 1780000 – 9 % complete libmtd: error!: MEMERASE64 ioctl failed for eraseblock 188 (mtd4)
error 5 (Input/output error)
flash_erase: error!: /dev/mtd4: MTD Erase failure
error 5 (Input/output error)
Erasing 128 Kibyte @ 19e0000 – 10 % complete flash_erase: Skipping bad block at 01a00000
Erasing 128 Kibyte @ 4940000 – 29 % complete flash_erase: Skipping bad block at 04960000
Erasing 128 Kibyte @ 7480000 – 46 % complete flash_erase: Skipping bad block at 074a0000
Erasing 128 Kibyte @ 9d20000 – 62 % complete flash_erase: Skipping bad block at 09d40000
Erasing 128 Kibyte @ f960000 – 100 % complete

After this when I try and write data to mtd4 this happens:

[ 63.202484] uncorrectable error : feed.conf
[ 63.206542] uncorrectable error : etc/opkg/debug-feed.conf
[ 63.225921] uncorrectable error : etc/rc1.d/

The unit does not boot and throws a bunch of uncorrectable errors.
As I said in the thread this worked fine in 3.0.7 and is now broken on the stable 3.2.21

Any ideas what might be causing this?

Further tests:

nandtest -l 4194304 -k -p 5 /dev/mtd4

ECC corrections: 45
ECC failures : 156
Bad blocks : 14
BBT blocks : 0
00180000: reading…
ECC corrected at 00180000
001e0000: reading…
ECC failed at 001e0000
001e0000: checking…compare failed. seed 121987888

Byte 0x9000 is 30 should be 84
Byte 0x9001 is ff should be 08
Byte 0x9002 is ff should be 3d
Byte 0x9003 is ff should be 53
Byte 0x9004 is ff should be 2c
Byte 0x9005 is ff should be 38
Byte 0x9006 is ff should be 44
Byte 0x9007 is ff should be 28
Byte 0x9008 is ff should be ed
Byte 0x9009 is ff should be 8d
Byte 0x900a is ff should be ab
Byte 0x900b is ff should be f6
Byte 0x900c is ff should be 28
Byte 0x900d is ff should be 7d
Byte 0x900e is ff should be 30
Byte 0x900f is ff should be ee
Byte 0x9010 is ff should be 5b
Byte 0x9011 is ff should be 7b
Byte 0x9012 is ff should be a8
Byte 0x9013 is ff should be bd
Byte 0x9014 is ff should be 81
Byte 0x9015 is ff should be ed
Byte 0x9016 is ff should be 9f
Byte 0x9017 is ff should be d4
… etc

Seems like a pretty core issue.

I have this issue back … works fine on 3.0.36 stable - broken on 3.1.10 stable
The only change a made was altering the omap3 timer in my board file to port it from 3.0.36 - 3.1.10

I guess either there is a big change in the nand or mtd drivers in 3.1 or the timer changes broke it.

Hi Chris,

Did you ever find the root cause of this issue? I am also seeing it on a 3.1.10 kernel…and would prefer to not re-create your debugging procedure. Hope all is well!


This issue was due to the board file…
It should be:
.timer = &omap3_timer,

When it was broken I had it as:
.timer = &omap3_secure_timer,

Apparently the ‘secure’ part is only for the Beagle Board due to a hardware issue or quirk.


I’m trying to do something similar, with a different problem, I’m running angstrom with kernel 3.2.28 and kernel 2.6.39.
When I try to mount the filesystem partition in the nand (/dev/mtdblock4) with kernel 3.2.28 $mount -t jffs2 /dev/mtdblock4 /mnt/nand
mount says that filesystem type ‘jffs2’ is unknown. But when I try the same exact command with kernel 2.6.39 it works fine. I would like to know if there is any issue related to support for jffs2 in 3.2.28. So far I have compiled 3.2.28 twice making sure jffs2 support is enabled and some MTD options are enabled too, but without any success. I would like to know if there is any option or patch or tweak to apply to the kernel in order to get jffs2 recognized by mount and by kernel.

best reggards,