Am 2013-09-23 21:08, schrieb Gabor Juhos: > It should be possible to fix the board via JTAG. At least it seems that the > PCB > has an unpopulated JTAG header. Yes I thought about this too, but since I didn't found an openocd configuration which should work with this SoC, I didn't even tried it. I guess I would download U-Boot to RAM and try to reflash U-Boot from there, right? Do you have a working JTAG toolchain for this SoC?
Today I tested the driver. After adding the relevant Kernel configuration (CONFIG_MTD_NAND_AR934X_HW_ECC) I could successfully read from the device, data look good. However, when I tried to dd the whole kernel I get some errors: # dd if=/dev/mtdblock7 of=/tmp/wndr4300-mtd7-kernel.img [ 325.310000] end_request: I/O error, dev mtdblock7, sector 424 [ 325.310000] Buffer I/O error on device mtdblock7, logical block 53 [ 325.340000] end_request: I/O error, dev mtdblock7, sector 536 [ 325.340000] Buffer I/O error on device mtdblock7, logical block 67 [ 325.380000] end_request: I/O error, dev mtdblock7, sector 424 [ 325.380000] Buffer I/O error on device mtdblock7, logical block 53 dd: /dev/mtdblock7: Input/output error My first guess was this is/are bad blocks. But U-Boot seems not to support this idea: ar7240> nand bad Device 0 bad blocks: ar7240> Maybe U-Boot's bad block management doesn't work with those information... A dd command with conv=noerror leads to a image witch is 16KiB smaller than it should be. After working only with initramfs, the default Firmware doesn't boot anymore: ** check rootfs image ** Verifying Checksum ... Bad Data CRC This CRC checks the rootfs. Netgear put another uImage header just before the rootfs partition (but still in the kernel partition). It looks like the Kernel already changed something on NAND, which causes this Bad Data CRC... I then flashed the latest Netgear Firmware again. Guess what, I could successfully dd the whole kernel... But dd the rootfs still has Buffer I/O errors. Any idea what could go wrong here? I think it would be a good idea to figure out whats wrong before doing further steps... -- Stefan _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
