2013.09.24. 23:07 keltezéssel, Stefan Agner írta: > Am 2013-09-24 19:09, schrieb Gabor Juhos: >>> A dd command with conv=noerror leads to a image witch is 16KiB smaller >>> than it should be. >> >> Don't use dd on NAND flashes. Use the nanddump utility from the mtd-utils >> package instead. > > Ok I understand that /dev/mtdblock[x] is not the way to handle NAND, but > reading should work anyway.
Yes, it should work. However the mtdblock layer can't handle bad blocks/ecc errors so that throws error messages. > By using nanddump I could successfully dump the images, although the ECC > check corrected bitflips. I guess that when using this NAND through mtdblock, > this leads to an I/O error (since its the exactly same place, 2880*512 = > 0x00168000). > > root@OpenWrt:/tmp# dd if=/dev/mtdblock10 of=/tmp/gaga > [ 1350.920000] end_request: I/O error, dev mtdblock10, sector 2880 > [ 1350.920000] Buffer I/O error on device mtdblock10, logical block 360 > [ 1351.000000] end_request: I/O error, dev mtdblock10, sector 2880 > [ 1351.000000] Buffer I/O error on device mtdblock10, logical block 360 > dd: /dev/mtdblock10: Input/output error > root@OpenWrt:/tmp# nanddump /dev/mtd10 >/tmp/wndr4300-mtd10-nanddump.img > --omito > ob --bb=skipbad > ECC failed: 0 > ECC corrected: 48 > Number of bad blocks: 0 > Number of bbt blocks: 0 > Block size 131072, page size 2048, OOB size 64 > Dumping data starting at 0x00000000 and ending at 0x01900000... > ECC: 16 corrected bitflip(s) at offset 0x00168000 > > But this is not a showstopper than, since the driver seems to work > correctly using the mtd interface. > > >> Did you write/erase the any of the partitions by any chance? > Hm, I think I played around mounting the jffs2 partition once.. this > should be after the CRC checked squashfs, but maybe I used the wrong > mtd. This would explain the error. I reflashed the image, since then it > boots fine even after using nanddump etc. from initram Ok. Even if you have used the correct mtd device, writing something into that can cause bit-flips in other erase blocks due to the common 'Write Disturb' problem. > Now I tried to create a UBI volume using the initramfs-Kernel. I get > this kernel crash dump: > > # ubiattach -m 8 /dev/ubi_ctrl > [ 3712.320000] UBI: attaching mtd8 to ubi0 > [ 3712.510000] UBI: scanning is finished > [ 3712.520000] UBI: empty MTD device detected > [ 3712.520000] CPU 0 Unable to handle kernel paging request at virtual > address 00000000, epc == 00000000, ra == 802094fc > [ 3712.530000] Oops[#1]: > [ 3712.530000] CPU: 0 PID: 1216 Comm: ubiattach Not tainted 3.10.12 #10 > [ 3712.530000] task: 878b5d50 ti: 8654c000 task.ti: 8654c000 > [ 3712.530000] $ 0 : 00000000 00000001 00000000 8037c810 > [ 3712.530000] $ 4 : 87826010 00000001 000001ff 00000200 > [ 3712.530000] $ 8 : 00000005 80064830 00000000 00000000 > [ 3712.530000] $12 : 00000000 d8197822 00000000 00000000 > [ 3712.530000] $16 : 878261b8 00000000 87826010 86e34000 > [ 3712.530000] $20 : 00000200 86e34500 86e34d00 00000007 > [ 3712.530000] $24 : 00000000 00000000 > [ 3712.530000] $28 : 8654c000 8654dae8 00000000 802094fc > [ 3712.530000] Hi : 00000000 > [ 3712.530000] Lo : 00000010 > [ 3712.530000] epc : 00000000 (null) > [ 3712.530000] Not tainted > [ 3712.530000] ra : 802094fc nand_write_subpage_hwecc+0xa0/0x1c4 Hm, this is a NULL pointer dereference. It seems that the nand_write_subpage_hwecc function tries to run a callback which is not initialized by the ar934x-nfc driver. I will look into that later. In the past, I have tested the ar934x-nfc driver (w/o hw ECC) with the modules provided by the mtdtests package and it passed all tests. Ideally, it should be tested again with hw ECC support but that is quite dangerous on devices which are using a NAND flash only. -Gabor _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
