Bricked WRT32X

Hello,

So about 2 years ago I bought this router, and modified it to run OpenWRT, but I believe I was either flashing a new update, or flashing back to the default firmware where it then broke. Somewhere along the road, I must've overwritten both firmwares, so it is now stuck with just the ethernet port(s) blinking when devices are plugged in, and the power LED stays off.

Fast forward to today, I've bought some TTL cables, and attempted to see if anything else other than the firmware is broken, but it seems to only allow the serial connection if I unplug the cable from the serial port and plug it back in. From this I can get an output in PuTTY, but I cannot prevent the boot process by pressing any key. Sometimes, the power LED flashes (from what I understand is if it detects the cable?), but doesn't provide me with an output in PuTTY whatsoever.

Below is the output I can get, but I cannot press any key to prevent the boot sequence, and thus try to get this thing working again. I haven't been able to find other things I could try, as most of what I've seen is suggesting the cables are incorrectly placed, but surely getting an output at all would mean they are correct? (I've never used serial for debugging before though)

As for the cables I bought: link

DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
Not detected suspend to RAM indication
BootROM: Image checksum verification PASSED


U-Boot 2013.01 (May 18 2017 - 16:37:44) Marvell version: 2015_T1.QA.0p16

Boot version : v2.0.9

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 4294 [MHz]
       L2     @ 4294 [MHz]
       TClock @ 200 [MHz]
       DDR3    @ 4294 [MHz]
       DDR3 32 Bit Width,FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB
NAND:  256 MiB
MMC:   mv_sdh: 0


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == 1
[u_env] get boot_part_ready == 3
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

[boot_count_read] block:0x220000, size:128KB, records:64
[boot_count_read_record] boot_count:3, next_record:4

[auto_recovery_init] BOOT_COUNT_TO_RECOVERY
[boot_count_write] erase:0, auto_recovery->block_offset:0x220000 offset=0x222000

Updating boot_count ...
[boot_count_write] offset:0x222000 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode

Map:   Code:                    0x1feaf000:0x1ff75960
       BSS:                     0x1ffef0dc
       Stack:                   0x1f9aef20
       Heap:                    0x1f9af000:0x1feaf000
       U-Boot Environment:      0x00200000:0x00220000 (NAND)

Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
| egiga2 |   SGMII   |   In-Band    |
egiga0 [PRIME], egiga1, egiga2
Saving Environment to NAND...
Erasing Nand...
Writing to Nand... done
#### auto_recovery:2 ####
auto_recovery_check changes bootcmd: run altnandboot
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0x8400000, size 0x600000
 6291456 bytes read: OK

Starting kernel ...

Sometimes I can get it to have the VENOM> prompt, but it doesn't run any commands.

Any help would be greatly appreciated.

Well there is a good chance that the cables are the reason for your difficulties.
It might help to PwrOn the device first and then immediately connect your ttl device to get the chance to interrupt the boot. I'm not sure if it has to be the spacebar? (My last ttl flashes I did on Wrt54G :D). Maybe spam it to get i through.

What is the command "help" showing? Usually you don't want to do much on console. Just start the tftp process.

If you cannot enter any command then your putty settings are not accurate. Either for serial connection itself (e.g. flow control) or the terminal (e.g. disable/enable local echo). I don't have all options in mind. You have to try or wait for someone who is fimilar with this device and its putty settings.

PL2303 adapters are a bit dodgy with Windows. But if it has recognized the port and received from the router it should be OK on sending as well.

Test your serial adapter by connecting TX (green wire) and RX (white wire) together without connecting to a router. You should see what you type in the terminal. If you break the connection you should not see what you type. If you see every character twice when connected that means local echo is on, it should be off.

Of course in this application don't connect the red wire to anything. Only connect ground, transmit, and receive.

the default wrt32x u-boot has the SILENT=1 option, which shuts down messages during boot, and makes serial access seemingly fail.
enter these commands from u-boot:

setenv silent
saveenv

see this thread

So funnily enough, I didn't realise when on the "press any key" prompt, I had to click a key then enter (I was assuming it was literally just pressing a key and it will work. Weirdly enough it didn't work with just pressing enter a bunch of times which is what I usually do with things like this.

So I've manged to get into the VENOM>> prompt, and run a few commands, however even after finding a flat img file it didn't want to boot. Fortunately however, I did a further few restarts and it's now working with the Linksys firmware.

In all I've:

• Switched on the router, and proceeded to fiddle around with the serial cable in the port to get the power LED to flash on/off
• On PuTTY, press any key followed by [enter/return] to enter the VENOM>> prompt
• Ran the following ip configuration/TFTPD commands:

setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.2          -- or whatever you set your local address to on your PC
setenv firmwareName linksys.img
run update_both_images

From there, I've managed to get myself back into the default firmware.

For future info in case I end up bricking it when installing other firmware later down the line:

It's always the little details

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.