I tried to flash my ea8500 with openwrt firmware but it ended up with a bad uboot it seems.
What I did: I followed device page and especially the tftp method.
Initially it complained about bad checksum: bad data crc. I tried several recent firmware releases such as 19.07 and 21.01, even the snapshot; it was all the same. It could not boot into the kernel because of the failed checksum, the bad crc (kernel image could not be found).
Then accidentally I zeroed out the $loadaddr environment variable because I noticed there was a difference between my boot log and the one posted on the device page. The next flash after emptying $loadaddr, nand write got stuck on the screen before it was finished. Seemed to me the usb ttl connection was lost because of a bad nand write. At this stage, after powering on the device, only LAN light turns on. Uboot seems to be damaged and there is no output on putty console from usb ttl connection at all.
At this point it's effectively game over. ipq806x doesn't have ROM based recovery mechanisms (at least none known so far), so if either PBL, SBL or APPSBL (u-boot) gets damaged, there is no reasonable way to recover - especially not on NAND based devices (as you can't simply unsolder the BGA NAND chip and reprogram it externally, which would be an option for spi-nor based flash).
The only recovery mechanism available on these devices is implemented via tftp in APPSBL (u-boot), it's fine to recover your firmware images (kernel/ rootfs), but it can't recover the bootloader itself.
Looking at the PCB in detail, there seems to be an unpopulated JTAG header, as well as an unpopulated header for an alternative spi-nor flash (and a NAND_Boot jumper to toggle between them), quite a lot of early PCB design leftovers and debugging aids, which might help your case. But this is uncharted territory and requires rather advanced experience - and might still not succeed in the end.
There is no simple fix, the device is dead as-is. Everything from here on would require very intimate familiarity with PCB design and ARM booting/ JTAG access. If you have to ask, it's probably not going to work.
Thanks. Today I was contacted by a repairer who told me he is willing to have a go. He suggested we reflash the dead 128MB spansion NAND using a working image given that ECC verification could be met. So the possible route is buy another working EA8500, desolder the spansion chip, dump everything on the chip, obtain the image then use that image to replace the damaged image on the dead EA8500. I don't know about the details but I am thinking would it be possible to dump what is on the working NAND using `dd' under linux without desoldering?
Then if `dd' the NAND chip is possible, is there anyone willing to obtain and share the image? Thanks.
Yes you can get the bootloader image from a working OpenWrt by copying it out of the mtd device. cat /dev/mtd0 > /tmp/bootloader.bin
This only works if there are no bad blocks in the bootloader partition, but generally the flash chip manufacturer guarantees the first part of the chip will be error free so that the ROM bootloader that loads the flash bootloader doesn't have to account for bad blocks.
Hi, what a coincidence, yesterday I've ruined my EA7500v1 at almost the same way by damaging u-boot.
Just for fun I've tried upgrade RAM up to 512Mb. Soldering new chips and booting after was fine, but system doesn't saw new full memory size. So I decided to flash u-boot from EA8500, but this doesn't work at all.
On bottom side of PCB I found all necessary signals for programming NAND flash.
Linksys was kindly enough to put testpoints on signals and even labeled it.
Unfortunately during first attempts to read/erase/write flash I seems to be somehow managed to damage other partitions.
I've asked @RadioOperator to dump partitions from 0 to 12, but for my case this doesn't help either
I assume he don't mind if I share their dumps.
You can download it here ea8500mtd.rar
Partitions table from 7500v1, U-Boot located at mtd9 (APPSBL)
Booting, yes - but ART contains the measured offsets to account for production variances of your radio hardware, to keep it within spec/ on-channel. It"s unique to your device, once it's gone, it's non-retrievable.
Checked that I have a dump of my ART partition. As it not affect boot process then I'll restore it later if can boot again.
Now I don't fully understand what's wrong with it. After I damaged only u-boot, router draw about 200-250mA and CPU was warm, now it draw 100-150mA and cpu is cold.
Seems to be it failed on earlier steps, may be qualcomm needs unique signed SBL1/2/3 for each CPU like on some smartphones.
I assume it is maybe something NAND-specific about badblocks and so on, but don't know how exactly work with it yet.
In older routers with NOR flash it was a way simpler
The repairer I contacted told me something like ECC verification or stuff like that about which I have no idea. He said if I have a working 8500 then both routers will be desoldered and resoldered. What he suggested was using a bga63 programmer adapter.
@slh Do you have knowledge about accessing NAND from openwrt?
I think we need full raw dump including 'spare' parts of nand's pages, which seems to be contain ECC data. Is it possible from openwrt firmware?
As far as I can tell dumping through /dev/mtd* only get 2048bytes of page without spare 64bytes.