OpenWrt Forum Archive

Topic: WRT54G3G v1.1 with power LED flashing - how to debrick?

The content of this topic has been archived on 18 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

I've got a WRT54G3G v1.1 where the power LED is rapidly flashing. I can ping it under 192.168.1.1 and tftp a .bin file into it
but it doesn't execute it. Connecting to the serial port, I see

CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: Mon Jul  3 15:34:01 CST 2006 (root@RedHat9)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.

Initializing Arena
Initializing Devices.

No DPN
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.90.37.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)
CPU type 0x29007: 200MHz
Total memory: 16384 KBytes

Total memory used by CFE:  0x80300000 - 0x803A3A00 (670208)
Initialized Data:          0x80339910 - 0x8033C020 (10000)
BSS Area:                  0x8033C020 - 0x8033DA00 (6624)
Local Heap:                0x8033DA00 - 0x803A1A00 (409600)
Stack Area:                0x803A1A00 - 0x803A3A00 (8192)
Text (code) segment:       0x80300000 - 0x80339910 (235792)
Boot area (physical):      0x003A4000 - 0x003E4000
Relocation Factor:         I:00000000 - D:00000000

Boot version: v3.6
The boot is CFE

No mac find, use default mac

No eou key find
Device eth0:  hwaddr 00-1C-10-1B-7D-47, ipaddr 192.168.1.1, mask 
255.255.255.0
         gateway not set, nameserver not set
Invalid boot block on disk
Reading :: Failed.: Timeout occured
Reading :: Failed.: Timeout occured

I've checked the flash content, seems like the firmware uploaded by tftp (last try was openwrt-freifunk-1.6.30) is correctly located in the device flash0.trx (the "d" command to display is broken, I used "save" instead).

The env variable STARTUP contains "go;".

I don't understand the above error

Invalid boot block on disk

.

Is it save to erase the complete nvram on a WRT54G3G?

I've checked the flash content after uploading an image into the tftp server of the bootloader again and it contains errornous bytes at the
offsets 0, 0x200, 0x400, 0x600, ... (offset from HDR0 marker). Just one byte is wrong at the distance of 512 bytes ...?!
I've sniffed the contents of the tftp packets to the bootloader (as these packets contain a payload of 512 byte each) - they contain the correct data.

I really wonder if this is a bug in the bootloader code or if someone has damaged the flash chip (maybe by shortening some pins).
I'll try to upload the firmware by some other CFE commands. Will do JTAG later when I've soldered a Wiggler clone.

Anyone out there who has successfully flashed an image into a WRT54G3G v1.1 by using tftp?

Update:
It seems like the bootloader can't read the flash content reliably:

CFE> d -b bc000000 10                                                           
BC000000: 17 FF FB FF FB FF FB F9 FB FF FB FF 00 FF FB FF  ................     
*** command status = 0                                                          
CFE> d -b bfc00000 10                                                           
BFC00000: FF FF FB F9 FB FF 00 FF FB FF FB 00 FB 00 FB FF  ................

The same happens with the save command (but not so many Fs there).

I've tried to flash Kamikaze 7.09 with an unbuffered JTAG cable. Reading the kernel back several times matches the image written, but the bootloader still fails with the error above ("invalid bootblock").
I've tried two other bootloader found in the web, one for WRT54G3G v1.0 and another from a WRT54GS v1.1. The first one throws a couple of exception during start and hangs while the second one has the same error as the original CFE.

If the flash device or the bus drivers (hw) were damaged by a previous owner (e.g. by pin shortening), I'd expect random problems while starting the bootloader and problems to write the flash with JTAG.

Maybe the flash is accessed too fast, i.e. the bootloader programs too few waitstates for the chip select?
Does someone know if I can set the number of waitstates for flash access by a nvram setting?

The discussion might have continued from here.