2013.09.23. 22:07 keltezéssel, Stefan Agner írta:
> 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? 

Yes, that would be the simplest method.

> Do you have a working JTAG toolchain for this SoC?

Nope, I did not have to use JTAG on any AR934x based boards yet.

> 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...

Despite what U-Boot says, those still can be bad blocks. The ar934x-ncf driver
has no special bad block handling yet.

> 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.

> 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...

Well, the hardware ECC support in ar934x-nfc driver might contain some bugs.
However, I don't think that the kernel writes anything into the flash by itself.

Did you write/erase the any of the partitions by any chance?

-Gabor
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to