Linksys EA8500 uboot damaged after wrongly flashing with empty $loadaddr

Hello,

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.

Could anyone help with a damaged uboot? Thanks.

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.

Thanks a lot! I shall message the guy what you said and hope he would give it a try.

Then the next request from me then would be I hope someone here on the forum could bother himself doing a

cat /dev/mtd0 > /tmp/bootloader.bin

then hopefully he can share the dump with me?

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.


Using this project https://github.com/skypiece/rpi-tsop48-nand with some hacks for this particular Spansion flash, now I able to read and write flash through Raspberry PI.

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 :frowning:
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)

No.: Name             Attributes            Start             Size
  0: 0:SBL1           0x0000ffff              0x0          0x40000
  1: 0:MIBIB          0x0000ffff          0x40000         0x140000
  2: 0:SBL2           0x0000ffff         0x180000         0x140000
  3: 0:SBL3           0x0000ffff         0x2c0000         0x280000
  4: 0:DDRCONFIG      0x0000ffff         0x540000         0x120000
  5: 0:SSD            0x0000ffff         0x660000         0x120000
  6: 0:TZ             0x0000ffff         0x780000         0x280000
  7: 0:RPM            0x0000ffff         0xa00000         0x280000
  8: 0:ART            0x0000ffff         0xc80000         0x140000
  9: 0:APPSBL         0x0000ffff         0xdc0000         0x100000
 10: u_env            0x0000ffff         0xec0000          0x40000
 11: s_env            0x0000ffff         0xf00000          0x40000
 12: devinfo          0x0000ffff         0xf40000          0x40000
 13: kernel           0x0000ffff         0xf80000         0x300000
 14: rootfs           0x0000ffff        0x1280000        0x2500000
 15: alt_kernel       0x0000ffff        0x3780000         0x300000
 16: alt_rootfs       0x0000ffff        0x3a80000        0x2500000
 17: syscfg           0x0000ffff        0x5f80000        0x2080000

BTW, if anyone has a EA7500v1 with working OpenWRT, I will appreciate if you can dump mtd0 - mtd12 for rescuing my router :slight_smile:

This is my version https://github.com/iglooom/rpi-tsop48-nand able to program Spansion S34MS01G2 NAND

1 Like

Wow, thank you for that. What a coincidence for both of us. I do have a working EA7500v1!!!!

ea7500v1mtd.tar.xz

If it helps at all, please let me know. I hope you can help me with soldering the wire and reflash the damaged EA8500!

1 Like

Unfortunately nothing changed :frowning:
May be mtd17 needs as well. Can you dump mtd17 too?

Make sure to try really hard to recover your own wifi calibration data, before fashing anything else.

It in ART partition?
IPQ8064 doesn't boot with data from another similar router?

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.

So it was not enough to flash mtd0 - 12. Your rescue of ea7500v1 was not successful?

Yep. Or maybe I do something wrong with nand flashing. I'll try one more time today.

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 :slight_smile:

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.

Seems to be nanddump may help.

Can you try these two dumps?

nanddump without -n flag tar.xz

nanddump with -n flag tar.xz

1 Like