'ecc unrecoverable error' - An Explanation Please

My question is: what is the console report actually telling me?

Does 'ecc' refer to memory or something else? No additional address, data or error code is provided. I cannot determine if it was a read or write error or what the upgrade was doing at the time.

I had three Meraki MR18s I wanted to flash. I successfully flashed two literally out of the box with little issue. I also successfully loaded the boot image on to the third and got to the web interface. Now the problem starts. When I try to flash the upgrade via the web interface, as I had done on the previous two cases, I get "ecc unrecoverable error" reported on the console, usually twice.

The MR18 in question was given to me and I don't know for curtain why it was disposed of so it could be faulty. But it does reliably boot and no errors are reported on the the console. I'm therefore assuming the MR18 is functional.

In this context, ecc corresponds to the error correction for your NAND flash. NAND is more error prone than traditional NOR flash, but cheaper at larger flash sizes - it comes faulty blocks from the factory already (and might get new ones over time), so it needs a rather sophisticated badblock management and error correction. It's quite possible that you either got faulty blocks at the wrong location or that the previous owner damaged the ecc blocks by using cat/ dd on the raw device.

mine showed up some ecc errors in

mtd4: 00020000 00020000 "odm-caldata"

but it still works, not have any bad PEB's

[    0.000000] Kernel command line:  board=MR18 mtdparts=ar934x-nfc:512k(nandloader)ro,8M(kernel),8M(recovery),113664k(ubi),128k@130944k(odm-caldata)ro console=ttyS0,115200 rootfstype=squashfs noinitrd
[    0.824604] 0x000001080000-0x000007f80000 : "ubi"
[    1.630698] ubi0: attaching mtd3
[    3.027842] ubi0: scanning is finished
[    3.048424] ubi0: attached mtd3 (name "ubi", size 111 MiB)
[    3.054036] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
[    3.061008] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
[    3.067815] ubi0: VID header offset: 512 (aligned 512), data offset: 2048
[    3.074713] ubi0: good PEBs: 888, bad PEBs: 0, corrupted PEBs: 0
[    3.080800] ubi0: user volume: 9, internal volumes: 1, max. volumes count: 128
[    3.088135] ubi0: max/mean erase counter: 20/12, WL threshold: 4096, image sequence number: 0
[    3.096793] ubi0: available PEBs: 0, total reserved PEBs: 888, PEBs reserved for bad PEB handling: 20
[    3.106192] ubi0: background thread "ubi_bgt0d" started, PID 286
[    3.113803] block ubiblock0_7: created from ubi0:7(rootfs)
[    3.119370] ubiblock: device ubiblock0_7 (rootfs) set to be root filesystem
[    8.807253] UBIFS (ubi0:8): background thread "ubifs_bgt0_8" started, PID 367
[    8.886960] UBIFS (ubi0:8): recovery needed
[    9.056825] UBIFS (ubi0:8): recovery completed
[    9.061406] UBIFS (ubi0:8): UBIFS: mounted UBI device 0, volume 8, name "rootfs_data"
[    9.069381] UBIFS (ubi0:8): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    9.079453] UBIFS (ubi0:8): FS size: 49287168 bytes (47 MiB, 382 LEBs), journal size 2451456 bytes (2 MiB, 19 LEBs)
[    9.090042] UBIFS (ubi0:8): reserved for root: 2327954 bytes (2273 KiB)
[    9.096770] UBIFS (ubi0:8): media format: w4/r0 (latest is w5/r0), UUID E7DB9EB9-2D00-4DAA-92AE-9003E26DD4DF, small LPT model
[    9.122439] mount_root: switching to ubifs overlay

i had done a JTAG install as the other methods did not work

ebay used item

root@LiMe-7b1484:~# ubinfo -a
UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:59
Present UBI devices:            ubi0

Volumes count:                           9
Logical eraseblock size:                 129024 bytes, 126.0 KiB
Total amount of logical eraseblocks:     888 (114573312 bytes, 109.2 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  20
Current maximum erase counter value:     20
Minimum input/output unit size:          2048 bytes
Character device major/minor:            253:0
Present volumes:                         0, 1, 2, 3, 4, 5, 6, 7, 8

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        5 LEBs (645120 bytes, 630.0 KiB)
State:       OK
Name:        board-config
Character device major/minor: 253:1
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        163 LEBs (21030912 bytes, 20.0 MiB)
State:       OK
Name:        storage
Character device major/minor: 253:2
Volume ID:   2 (on ubi0)
Type:        static
Alignment:   1
Size:        44 LEBs (5677056 bytes, 5.4 MiB)
Data bytes:  5664768 bytes (5.4 MiB)
State:       OK
Name:        rootfs-25-201807311416-G4e64c798-rel-chalet-1
Character device major/minor: 253:3
Volume ID:   3 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        44 LEBs (5677056 bytes, 5.4 MiB)
State:       OK
Name:        rootfs-25-201807311416-G4e64c798-rel-chalet-2
Character device major/minor: 253:4
Volume ID:   4 (on ubi0)
Type:        static
Alignment:   1
Size:        68 LEBs (8773632 bytes, 8.3 MiB)
Data bytes:  8727997 bytes (8.3 MiB)
State:       OK
Name:        diagnostic1
Character device major/minor: 253:5
Volume ID:   5 (on ubi0)
Type:        static
Alignment:   1
Size:        68 LEBs (8773632 bytes, 8.3 MiB)
Data bytes:  8725121 bytes (8.3 MiB)
State:       OK
Name:        diagnostic2
Character device major/minor: 253:6
Volume ID:   6 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        2 LEBs (258048 bytes, 252.0 KiB)
State:       OK
Name:        caldata
Character device major/minor: 253:7
Volume ID:   7 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        78 LEBs (10063872 bytes, 9.5 MiB)
State:       OK
Name:        rootfs
Character device major/minor: 253:8
Volume ID:   8 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        392 LEBs (50577408 bytes, 48.2 MiB)
State:       OK
Name:        rootfs_data
Character device major/minor: 253:9

Thank you both, slh and markbirss, for you reply.

OK it seems the flash device is at least suspect. I could just replace it, however I might just remove devices and do a bit of reverse engineering. I suspect if I swap the flash chip then I will need to recover the caldata otherwise the MR18 is a pile of bits. But before I do anything I would appreciate a bit of free education on flash devices.

  1. Even if the flash chip has bad blocks are they not transparent, i.e. handled by the devices internals? So trying to write and read data should just happen. I'm assuming here there are enough good blocks available.

  2. Is there a command line tool to scan the device and force bad block removal. A memtest tool in effect?


From https://openwrt.org/docs/techref/flash#hardware_vs_software1

There are actually NAND chips available doing bad block management by their own. Although I never used them myself, what I read it sounds quite nice. Most bare flash however doesn’t deal with bad blocks.

1 Like

There is a standard for flash chip manufacturers to mark which blocks were found bad during the testing process. Devices that use the chip should look for and respect these flags.

Interestingly though the flags are erasable like any other part of the flash. If that happens, the OS will try to use bad blocks as if they were good, and errors are likely.

Thank you all for the help and bead-time reading, appreciated.

With specific regard to my original post: I have decided to scrap the unit and use it for spares or possibly to reverse engineer some aspects if I have time and feel so inclined. Also, I don't have an and appropriate programmer with which to recover the existing flash data. That would take more time and money and its cheaper to just buy a second hand unit. I have two flashed and working so I would rather focus on getting them configured.

Thanks again.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.