Hi!

I have a wrt54g v2 box which looks like dead, firmware loading does not start.
This happened after manual clearing all variables from nvram.
I made a serial console adapter, plugged it in, but wrt54g doesn't output any signal to console.
Console adapter works fine with another wrt54g box.
It is unable to ping or arping the device.
Power led is blinking,  wired interface led shows some activity (i.e. when packets are being sent from NIC to wrt54g device).

Can anyone suggest how to revive this box?
Is it able to access PMON in this case?

Should I assume that you already tried this?

http://voidmain.is-a-geek.net/redhat/wr … vival.html

You're absolutelly right 
Shorting of pins 15-16 doesn't change behavior.

Wow, maybe it's really bricked?

I don't beleive there is no way to recover it.
If I have flash programming device which understands this chip (Intel Flash TE28F320) I can pull out it from bricked unit and alive unit and just copy content from one flash to another. I beleive it will help. But I don't have such device. Maybe there are other ways to recover wrt54g box.

I found this at seattlewireless site:
--------------
(3) the NVRAM *IS* needed for proper operation of the PMON; if you trash that into worthless garbage .. well you need a serial port to access the 'user' interface of PMON to update the required parameters back to sane values
--------------
Does anybody know how can I access PMON in this case?

DO NOT DELETE ANY NVRAM VARIABLES

The nvram area is a fixed size, deleting an nvram variable will free a few bytes of nvram storage but the savings are insignifigant -- the nvram area can only be used to store nvram data and most people already have a few k of nvram free. OpenWRT does not require any modifications to nvram and will not create any new variables; packages and modified files are stored on a jffs2 filesystem which is compressed and separate from nvram.

The bootloader (pmon for 1.x and cfe for 2.x/gs) will require a handful of variables to even boot -- deleting these variables will break your unit.

DO NOT DELETE ANY NVRAM VARIABLES

The pin 15/16 trick ties two address bits together which essentially redirects the read from one address to another address which differs by one bit. This rearranegment of data will be detected when the bootloader performs a CRC check just prior to booting, triggering a state similar to that of boot_wait.

The key thing here is that pins 15 and 16 are specific to the v2 and will only cause corruption of the firmware; this works great for recovering from bad firmware but if nvram is broken the bootloader may not even get to the point of trying to the firmware.

Here are some notes which may help:
* The power led of any v1.1 or later can be set to blink, the blinking is done in hardware and the led will continue to blink until set otherwise, even if the software crashes.

* The lan ports will all flash briefly when the admtek chip controlling the switch is reset; this happens once at powerup and again when the ethernet drivers are loaded. (OpenWRT will stop the power/diag flashes and turn on the DMZ led at bootup   prior to loading the ethernet driver)

* Holding down the reset button while powering on a v2 will cause the nvram to be reset to defaults stored in cfe, but not until after cfe tries initialize itself using a few variables from nvram.

* Shorting a different set of address pins may hide the starting signature of nvram forcing cfe to boot entirely from the copy of nvram embedded in cfe.

...

Given that nothing happens on the serial I'd be concerned if the bootloader was even working.

Thank you for tips.

1 and 2 - clear.
3 - does not help. reset button has no effect.
4 - where can I find details which exactly pins I need to short?

pinouts for the intel flash chips can be found at developer.intel.com

I believe I must be misunderstanding what you are saying above. The way I read the above you are saying that shorting pins 15 and 16 will only work on the v2 routers. I do know that this also works on the v1.1 routers because that's what I used in my revival HOWTO. Can you clarify your quote so I understand it clearly? Do you see any problems with my document (other than it will not recover deleted NVRAM variables)? Here's the one I am referring to:

http://voidmain.is-a-geek.net/redhat/wr … vival.html

You seem very knowledgeable on the subject and I would like to be as accurate as possible. The above document receives quite a number of hits (relative to the rest of my shabby site) and I believe it has helped some people.

Sorry if this is off topic.

It works with board 1.1

It works not, if nvram contains garbage.

Is there a way to reanimate nvram for 1.1 (flash is ok) ?

What has happened:

1. Update to OpenWRT CVS version 2004-09-26

2. Change of wan ip address in nvram

3. nvram commit

4. after return of "nvram commit" powercycle

Now red led is on (not flashing). Pin 15/16 shortcircuit does no longer work.

I have a Linksys v.1, also changed the wan address and the thing shows a steady red diag light after reboot.

When you turn it on now, both diag and power burn continuesly.

and no, also for me the pin shortcut trick does not seem to work...

Using todays cvs code, maybe this is a new "feature" ?

I found out that my Linksys does not have the Intel Flash, but an AMD version (AM29LV320DB). AMD has a pdf with the layout online. I tried connecting pin 12 to both Vss(27) and Vcc (37) but no luck...

See http://www.amd.com/us-en/assets/content … 3579c5.pdf

My Wrt54g v1.0 the same

have commit an lan_ipaddr change,

reboot

and now: DIAG = RED permanent

I had this happen to my v1.0 yesterday, and was a bit dissapointed because til that point, OpenWRT had been an absolute blast.

I've got a serial port on it, and pmon just keeps looping this about once every second:

I tried the pin 15-16 trick, no change. So I tried further on... 16-17, no change. 17-18, no change. Now at some point things DID change, but I'm not sure if it was 17-18 or 18-19. Now this is a fairly dangerous thing to do, but I figured the unit was dead anyway, no point holding back!

What happened when the last pair of pins was shorted was pmon rewrote the NVRAM from it's internal copy, then rebooted and loaded up normally.

I don't know if my results are reproducable.

I hadn't heard of the problem before, but it looks like it's fairly common. And from something as simple as changing an IP address. :cry:

I'll see if I can find out exactly what's going on...

Just tested something: Telnet in, nvram commit (no other changes made), reboot... dead router. :cry:

Where is the nvram utility from (I don't have time to look now)? GS sources? Looks like it doesn't like the AMD flash chips on the v1.0 units.

I download this: http://www.amd.com/us-en/assets/content … 3579c5.pdf

What do you mean whit 17-18 or 18-19 Pin?

The CONNECTION DIAGRAMS in this pdf files says e.g.

pin 11 = WE#
pin 12 = RESET
pin 13 = NC
pin 14 = WP#/ACC
pin 15 = RY/BY#
pin 16 = A18
pin 17 = A17
pin 18 = A7
pin 19 = A6

I want to repair my baby, please give me a hint!  :?:

To tell you the truth I'm not really sure. It might be as far up as 18-19. It seems the worst you can do though is lock the unit up, which can be fixed by a power cycle.

pmon seems to reboot about twice a second so all you need to do is quickly join the pins and let go again, if the DMZ light doesn't come on in a few seconds power cycle and try again.

v1.0 issues:

I was looking into the 'nvram commit broke it' issues earlier today and confirmed the issue exists on the v1.0 (and hence the sticky post at the top of this forum). The fact that it actually broke took me a bit by surprise, but the device was easily recovered.

It runs in my mind that I used pins 15-16 (I didn't have the AMD datasheet handy) but I haven't gone back to confirm this.

steps taken
1. unplug

2. open
(on v1.0's you don't need to remove the antennas)

3. short pins of the flash (15-16?)

4. carefully plug in
(while still shorting the pins -- easier said than done)

5. watch bootup
When the switch powers up it will flash all the switch leds breifly

-- If the switch leds don't light: You've shorted more than just the flash, immediately stop shorting the pins. The switch leds should light as soon as you stop shorting the pins; if they don't flash the next time you power on, check to see that none of the pins are bent.

-- After they switch leds flash, watch the diag and dmz leds. If there's any change in the dmz led you should stop shorting the pins and wait for bootup. The diag led will go off and the dmz led should come on; the dmz led signals openwrt booting and running the preinit script. When openwrt is fully booted the dmz led will go off and the wireless led will be on.

-- If openwrt is booting but you still can't get in, use openwrt's failsafe mode: reboot by unplugging and wait for the dmz led (you don't need to short pins, nvram was already reset) press and hold the reset button for 1-2 seconds as soon as you see the dmz led, telnet to 192.168.1.1

-- Switching firmwares: Since the nvram command can't be used for setting boot_wait, the recommended solution is to use the mtd write command. This will require a trx file; see the following example:

cd /tmp
wget http://openwrt.org/downloads/openwrt-v1-recovery.trx
mtd write openwrt-v1-recovery.trx linux
reboot

(the above trx is just the normal snapshot from 20040918, confirmed to work on the v1.0)

...

If all else fails let us know, but at the very least the v1.0 has a minipci wireless card that you can use yourself or sell on ebay.

Okay Thx for that Instruction Sheet but i still have a problem where are the Pin 15 and 16? On my Wrt54g v1.0 i found no AMD Chip or something like that. I google for it but i only found images of the version 1.1<=. It would be really nice if someone can take a shot of his Wrt54g and mark the 2 Pins I need to reset

I think the 1.0 board is similar to the 1.1 board but doesn't have the riser board. You should find an Intel Flash chip (should be written right on the chip). I have pictures in my howto that should give you a hint. The board is marked with the first and last pin numbers in the row of pins and there should be a white mark every 5 pins. Here are some pictures:

http://voidmain.is-a-geek.net/redhat/wr … vival.html

Click on the pictures to enlarge.

AMD flash Recovery:

- Put pin 14 to ground and power on the AP.
- Use TFTP to upgrade firmware (use original linksys firmware).
- Wait boot.
- http://"ip-ap"
- Restore default configuration.
- Reboot
- Upgrade AP firmware if you want.

It seems that I have the same problem as MBM. A FW upgrade to 3.04 for the WAP54G(v1) didn’t seem to take, now I cannot access the ap at neither its previous settings nor the factory defaults (after resetting, etc). Mine also uses AMD’s flash chip; shorting pin 16 to 17 and grounding 14 have no effect. The diag light does not stay on, and it seems that the unit successfully boots. When it’s hooked up to a lan (accommodating the factory default) or directly up to my laptop (which is MDIX enabled) the link/act led flickers. Angel (or anybody!), is there anything else I should try before salvaging the wireless mini pci and burning the rest?

This probably goes without saying, but the wifi link led is on yet netstumbler reports no activity in the air.

I have, (or perhaps should I say I had), a WAP54G v.1.0 with an AMD flash chip,
until I tried to upgrade the firmware to version 3.0x. 

Now the situation seems to be exactly what bloobooger and mbm describe above,
namely:

a. the WAP appears to boot without problems, the diagnosis red led
    does not remain on.

b. the WLAN led stays is on, however there is no detectable WLAN
     connectivity

c. when connected directly to a computer the three LAN leds
     are on, and at the top the activity led  flickers when I try
     to ping or to ftp to 192.168.1.1

d. I ping, or ftp to 192.168.1.1 or to 192.168.1.245 goes unanswered.

e. the reset button does not seem to anything at all, no matter how long
     one holds it.

I have tried shorting pins 16 and 17, as well as grounding a few others.
I have also made a clumsy attempt to use a serial cable which came
with a cisco catalyst switch.   I would also like to know whether there
is anything else which one can still try to load new firmware.

Also since I have only used linksys firmware I wonder whether somebody
might have tried to get help from them.

Thanks!

Yeah, I have the same problem as these guys. I installed the latest openwrt on my WRT54G v1.0, wrote an ip address change to the device and it friggin bricked...that sucks :-(
I can't recover it using any of the methods described (pin shorting, grounding 14, etc).
The green power and red diag lights are the only things that work when I plug it in - and they stay on, no blinking.
Anyone have any ideas or is it time to buy a new one?