Likely bricked my TL-WDR3600

Installing and Using OpenWrt
1

Hi guys,

I screwed up a little bit a flashed a wrong firmware onto my wdr3600 (V1.5). After that I bought a USB <-> Serial TTL Adapter and tried to perform the Serial TFTP flash, which worked pretty well, but after trimming the official rom to 8,126,464 bytes and performing the flash via serial TTL, I got weird error messages and a boot loop after the reset:

U-Boot 1.1.4 (Oct 21 2014 - 12:49:00)

U-boot DB120


DRAM:  128 MB
id read 0x100000ff
flash size 8MB, sector count = 128
Flash:  8 MB
Using default environment

PCIe Reset OK!!!!!!
In:    serial
Out:   serial
Err:   serial
Net:   ag934x_enet_initialize...
No valid address in Flash. Using fixed address
 wasp  reset mask:c03300 
WASP  ----> S17 PHY *
: cfg1 0x7 cfg2 0x7114
eth0: ba:be:fa:ce:08:41
athrs17_reg_init: complete
eth0 up
eth0
Autobooting in 1 seconds
## Booting image at 9f020000 ...
   Uncompressing Kernel Image ... Stream with EOS marker is not supportedLZMA ERROR 1 - must RESET board to recover

U-Boot 1.1.4 (Oct 21 2014 - 12:49:00)

U-boot DB120


DRAM:  128 MB

The printenv of my device looked like this

db12x> printenv
bootargs=console=ttyS0,115200 root=31:02 rootfstype=squashfs init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),64k(mib0),64k(ART)
bootcmd=bootm 0x9f020000
bootdelay=1
baudrate=115200
ethaddr=0xba:0xbe:0xfa:0xce:0x08:0x41
dir=
lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize;cp.b $fileaddr 0x9f000000 $filesize
lf=tftp 0x80060000 ${dir}db12x${bc}-jffs2&&erase 0x9f050000 +0x630000;cp.b $fileaddr 0x9f050000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize;cp.b $fileaddr 0x9f680000 $filesize
stdin=serial
stdout=serial
stderr=serial
ethact=eth0
filesize=7d0200
fileaddr=80060000
ipaddr=192.168.1.111
serverip=192.168.1.100

After that I did the bad thing and thought I could just flash the unstripped image and just start at 0x9f000000 instead of 0x9f020000:

db12x> tftp 0x80060000 wdr3600.bin
Using eth0 device
TFTP from server 192.168.1.100; our IP address is 192.168.1.111
Filename 'wdr3600.bin'.
Load address: 0x80060000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #########################################
done
Bytes transferred = 8192512 (7d0200 hex)
db12x> erase 0x9f000000 +7d0200

First 0x0 last 0x7d sector size 0x10000
 125
Erased 126 sectors
db12x> cp.b 0x80060000 0x9f000000 0x7d0200
Copy to Flash... write addr: 9f000000
done
db12x> reset

That is the last I've ever heard of my wdr3600. Since then only the power led is on and the lan led whenever a cable is connected. It does not seem to do anything anymore.

I've got two questions now:

  1. Is there anything I can do to still salvage my wdr3600 and get it back to working (I am afraid this is now extremely hard/unlikely, but maybe there is hope)?

and

  1. Apparently what I did (flash the full image including the bootloader part) was a bad idea and the wiki page did warn about not to continue if the image wasn't exactly 8126464 bytes, but I would still like to understand what exactly happened when I did what I did. Apparently the bootloader part does not start at 0x9f000000 or the image does not contain the bootloader at the start or something else.

Best regards and thanks a lot for this awesome wiki and detailed explanation. I've already come a lot farther than I would have imagined.

Mehrtürer

1 Like
2

Yes you've clobbered the bootloader, so now you need to use a SPI programmer to write a copy of the bootloader directly to the flash chip. The bootloader can be extracted from the official firmware, look for the distinctive vector table that occurs at the start of a MIPS bootloader. It is exactly 1kB of a repeating pattern with lots of zeros like this:

0000000 1000 00ff 0000 0000 1000 00fd 0000 0000
0000010 1000 0185 0000 0000 1000 0183 0000 0000
0000020 1000 0181 0000 0000 1000 017f 0000 0000
...

Try to get a backup of the ART partition (the last 64kiB block in flash) before writing anything-- if it hasn't already been clobbered that is unit specific data which is not readily replaceable.

Once you get it to boot again I recommend loading the initramfs image of OpenWrt and using it to sysupgrade to a release image. This is much safer than writing to flash directly.

On many models the factory MAC addresses and WPS PIN (not that you actually need that) from the sticker on the bottom are patched into the bootloader partition.

3

WDR3600 also got a 14-pin EJTAG header (JP1) which allows flashing via OpenOCD.

4

Thx a lot guys.
Unfortunately both is extremely unfamiliar ground to me.
Do you have any resources on what I have to do to get that going. I'm not even sure if I need any additional hardware for that EJTAG + OpenOCD thing.
As you can tell, I don't have any experience with that low level hacking so far, but I am willing to learn :slight_smile:

5

Both, raw access to SPI flash and JTAG require additional hardware.

For SPI access there are cheap kits on ebay with CH341 chip and clamps to connect to common SPI flash packages without having to unsolder them from the board.

For JTAG there are (more expensive) ready-made adapters, but you can also quite easily use an FTDI FT2232H breakout board and two 4k7 resistors to make a JTAG adapter yourself.

If you are unfamiliar with both, probably hooking up the SPI flash is the easier way.

1 Like
6

Working tl-wdr3600 routers tend to sell for under 10 EUR on the used markets, choose wisely what makes sense from an economical point of view.

--
While I would not exactly recommend buying 802.11n devices in 2021 (better ones supporting 802.11ac aren't necessarily more expensive, if you are patient and persistent in your hunting), spending money on broken ones makes even less sense.

7

Some JTAG basics -

http://www.tiaowiki.com/w/Debrick_Routers_Using_JTAG_Cable

Notice in the tutorial that "pogo pins" are used, which don't require soldering.

8

You just won't find any computer with that old-school DB25 parallel port which allows you to build the JTAG wiggler adapter... Apart from the cool "pogo pins" it's kinda all useless information nowadays (unless you are going to de-brick good-old WRT54G using a similarly old computer and Windows OS...)

More up-to-date information:

https://openocd.org/doc/html/Debug-Adapter-Hardware.html#USB-FT2232-Based

Also note that nowadays you wouldn't use device-specific software or even just try to access the flash chip directly via JTAG (OpenOCD has some support for doing so and transparently accessing flash banks using JTAG -- better don't waste your time with that...). Instead, you just load a special version of U-Boot into the RAM via JTAG and let the CPU run it, then use it to access flash using U-Boot once it loaded.
pepe2k provides U-Boot to do this:

2 Likes
9

Yeah, that was a JTAG intro from a few years ago, so thought it might give the OP an
"overview".

Didn't want the soldering part to scare the OP off...since it's not necessary with pogo pins.

Lots of USB JTAG cables available...I'll probably pick one up for myself.

Thanks for the update.

10

Imho the best is to get the most simple FTDI FT2232H breakout board (doesn't need to be genuine FT2232H Mini Module, I used a much cheaper no-name module with annoyingly bright green LEDs...), 2x 4k7 resistor and some jumper wires, that's all you need to get started (total cost ~$20).
All you need is to pull TMS to 3.3V with 4k7 and pull TCLK to GND with 4k7.
Then connect FTDI FT2232H breakout as described here

https://wiki.paparazziuav.org/wiki/Debug_Probes#FLOSS_JTAG

Buffered/isolated adapters are nicer (as in: safer to use), but also cost real money. Some are open hardware, I built mine inspired from Flyswatter by TinCanTools.com

3 Likes
11

I have a wdr3600 here with a sticky node on it "bootloader?"

And for the ecological point of view I like to repair it rather than let it become landfill just because of "broken" software.

Indeed, we know this. But some people like to throw in their knowledge - if it is outdated or even simply wrong. Luckily we are in a forum and can correct them :brain:

Valuable information! I will need to look into some boxes but should be able to call two ftdi boards my own.

12

Make sure it's the USB 2.0 "High-Speed" FT2232H chip, not the (much more common and also much cheaper) USB 1.1 "Full-Speed" FT232L chip. FT232L will not work as JTAG, only FT2232H can do that afaik (thanks to FTDI's MPSSE feature).

2 Likes
13

Thx a lot guys. I'll try to read up as much as I can. Investing 20$ although I could just get a replacement for 10$ is not really my concern. I was just looking if I can learn and understand how to debrick the wdr3600 myself. I will try my best and let you guys know if I was successful. Thx again.

Mehrtürer

14

One more question: I'm still not fully sure what exactly went wrong with my command.
Is it not possible to flash the full (i.e. unstripped) firmware (with "boot" in the name) via the serial TTL method? Could/Should I just have started at another address (with the erase and cp.b command)? Or do I have to copy the boot and firmware parts of the firmware .bin file to separate locations? If explaning that would go too much into detail, I'd understand if you would understand. But maybe there is a simple answer :slight_smile:

16

The answer is pretty simple. By doing this:

You have deleted the bootloader and subsequently written the firmware image there. As you can see in the bootloader environment, the firmware image is expected by the bootloader at 0x9f020000 rather than 0x9f000000 which is the location of the bootloader itself...

17

But what is the first part of the "boot" firmware images, that has to be stripped away? I thought it was the bootloader, but apparently it seems to be something else. Or is it the bootloader, but has to be decrypted/deflated somehow before copying?

18

We don't build the buildloader for (most) QCA MIPS devices. The difference between factory and sysupgrade image is that the factory image is accepted by the vendors web interface while sysupgrade works with OpenWrt already installed. Both images do not contain the bootloader.