• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 2331 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

nandwrite from Linux: "ECC: uncorrectable"

Christian Barth
Intellectual 290 points

I have a problem writing a new kernel image into the nand from Linux. We need this for an update procedure.

I used "nandwrite -s 0x200000 -p /dev/mtd3 uImage_new" ("-s 0x200000" because i dont want to destroy the working kernel). I reboot our board and load the new kernel with nand "read 0x81000000 0x480000 0x200000;bootm 0x81000000" (0x280000 is partition start for /dev/mtd3). The Result is: 

NAND read: device 0 offset 0x480000, size 0x200000
ECC: uncorrectable.
ECC: uncorrectable.
ECC: uncorrectable.
....
NAND read from offset 480000 failed -74
 2097152 bytes read: ERROR
## Booting kernel from Legacy Image at 81000000 ...
 Image Name: Linux-2.6.37+
 Image Type: ARM Linux Kernel Image (uncompressed)
 Data Size: 2038324 Bytes = 1.9 MiB
 Load Address: 80008000
 Entry Point: 80008000
 Verifying Checksum ... OK
 Loading Kernel Image ... OK
OK

In spite of the ECC-errors the Kernel boots up correct. So the payload ar correct.
I checked the OOB-Data of the first block after writing from Linux and from uboot. There are some differences:

nandwrite from Linux:
OOB Data: ff ff 10 8c 40 b2 00 48 60 35 68 86 1a 01 08 00  |....@..H`5h.....|
OOB Data: 00 0e d1 90 12 08 04 10 68 06 10 8b 08 00 00 0a  |........h.......|
OOB Data: 40 e0 10 48 20 18 08 04 00 5b 00 00 00 08 81 e2  |@..H ....[......|
OOB Data: 12 08 64 21 40 84 0a 19 02 00 ff ff ff ff ff ff  |..d!@...........|
nandwrite from uboot:
OOB Data: ff ff 59 cc 66 b2 8c 5a fa 37 e8 8e ff 01 bc 00  |..Y.f..Z.7......|
OOB Data: c5 5e f5 99 5a 88 1e 52 7c 77 d0 ab ad 00 87 1b  |.^..Z..R|w......|
OOB Data: 6e e1 5d 4a 20 5a 19 15 c5 5f b1 00 af 49 ad eb  |n.]J Z..._...I..|
OOB Data: df 18 fe a1 55 ec ab 3d 23 00 ff ff ff ff ff ff  |....U..=#.......|


Board-Data:
CPU: DM8168
Board: custom derived from the EVM
NAND: Micron MT29F1G08
EZSDK: 5_05_02_00
UBoot: u-boot-04.04.00.02
Linux: linux-04.04.00.02

There are some commits in the omap3 tree with a nand correlation after version 04.04.00.02: http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog
Are they possible notable?
  • 0
    Intellectual 290 points

    I have some strange effects if I use an kernel upgraded with the nand patches from the omap3-master. I report about this on Monday (Its 1600 in Germany on Friday, Weekend calling).

    With the 04.04.00.02 kernel I had succes erasing the flash before the nandwrite command with flash_erase /dev/mtd3 0 34.

    nice weekend to all

  • 0 in reply to Christian Barth
    Intellectual 290 points

    Today I checkt the behavior of the linux-omap3-master. ECC is configured as OMAP_ECC_BCH8_CODE_HW.

    All is ok until loading ubifs. I got ECC errors and a kernel panic.

    [    5.350000] UBI error: ubi_io_read: error -74 (ECC error) while reading 128 bytes from PEB 154:92592, read 0 bytes
    [    5.360000] UBIFS error (pid 1): ubifs_leb_read: reading 128 bytes from LEB 152:88496 failed, error -5
    [    5.370000] UBIFS error (pid 1): ubifs_iget: failed to read inode 1, error -5
    [    5.370000] VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0)
    [    5.380000] Please append a correct "root=" boot option; here are the available partitions:
    [    5.390000] 1f00            1536 mtdblock0  (driver?)
    [    5.400000] 1f01            2432 mtdblock1  (driver?)
    [    5.400000] 1f02             128 mtdblock2  (driver?)
    [    5.410000] 1f03            4352 mtdblock3  (driver?)
    [    5.410000] 1f04          124160 mtdblock4  (driver?)
    [    5.420000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
    [    5.430000] Backtrace:
    [    5.430000] [<c004abdc>] (dump_backtrace+0x0/0x110) from [<c02d7f2c>] (dump_stack+0x18/0x1c)
    [    5.440000]  r7:d3413000 r6:c0073464 r5:c002b6fc r4:c0406750
    [    5.440000] [<c02d7f14>] (dump_stack+0x0/0x1c) from [<c02d7f90>] (panic+0x60/0x17c)
    [    5.450000] [<c02d7f30>] (panic+0x0/0x17c) from [<c0008ff8>] (mount_block_root+0x264/0x2b4)
    [    5.460000]  r3:00000000 r2:00000000 r1:d342bf78 r0:c03699ac
    [    5.470000] [<c0008d94>] (mount_block_root+0x0/0x2b4) from [<c0009144>] (prepare_namespace+0x94/0x1d4)
    [    5.480000] [<c00090b0>] (prepare_namespace+0x0/0x1d4) from [<c0008544>] (kernel_init+0x114/0x154)
    [    5.480000]  r5:c0008430 r4:c0405b80
    [    5.490000] [<c0008430>] (kernel_init+0x0/0x154) from [<c0073464>] (do_exit+0x0/0x5e4)
    [    5.500000]  r5:c0008430 r4:00000000

    The differences to the working kernel in the log are an detection print from omap2-nand and (this is interesting) another max. sequence number reported by UBI from 163(old) to 199(linux-omap3).

    I seems that the ECC calculation is different between 04.04.00.02 and linux-omap3.master. I think this shouldn't happen.

  • 0 in reply to Christian Barth
    Intellectual 310 points

    hi Christian

    i have am335x evm  board, i want to boot from nand and have your problem exactly,

    can you solve your problem?

    can you help me?

  • 0 in reply to mammad yasak
    Intellectual 290 points

    Hi


    I forgot an option for the creation of the ubifs-image.

    I create the FS with: sudo mkfs.ubifs -r ./rootfs/ -o ubifs.img -m 2KiB -e 124KiB -c 957

    -m -e -c depends on your NAND.

    I missed the -F option. [--space-fixup   file-system free space has to be fixed up on first mount]

    With this option the first boot takes some seconds, but I didnt see any errors the last months.

    I found the anwser there: http://processors.wiki.ti.com/index.php/UBIFS_Support#Creating_UBIFS_file_system