Ok. I'm getting sick and tired of everyone starting a new thread for their broken routers; it just clutters up the search results making it harder to find answers.
This thread is a collection of the various threads on the subject; please don't start any more threads on the subject.
Set boot_wait. Enabling this option makes it much easier to recover firmwares; everyone who actually read the userguide should have it set.
Try failsafe mode. Power up, wait for the DMZ led, hold down the reset button for 2 seconds.
WARNING: holding down the reset button while powering up will unset boot_wait and restore nvram to factory defaults - wait for the DMZ led.
DO NOT RETURN BROKEN ROUTERS. Admit the fact that you broke it and fix it yourself; loading 3rd party firmwares is not covered by waranty.
WRT54G: (4M intel/amd flash)
Shorting pins 15-16 generally works to recover from a broken firmware. Unplug, short pins, plug in ..
To fix a corrupted NVRAM, such as the (now fixed) commit bug on the v1.0, power up, wait for all the switch leds to light then short pins 2-3. If it's a v2.0 you can just do the reset trick above.
WRT54GS: (8M intel flash)
Shorting pins 5-6 generally works to recover from a broken firmware. Unplug, short pins, plug in ..
What the hell does shorting the pins do / how do you know what pins?
The pins listed are address lines, if you grab the datasheet for any of the flash chips they'll be shown as a0, a1, a2 ...
Each address line represents 1 bit -- Suppose you wanted the 12th byte off the chip, 12 translates to 1100 in binary which means you'd need 4 address lines and they'd be set on or off (voltage, no voltage) depending on if the bit is 1 or 0.
If you short the pins, that changes the address the chip sees as requested. Continuing with the earlier example, suppose of those 4 address lines, the middle two were shorted:
The requested address, 1100 gets seen as 1110; a request for address 12 got turned into a request for address 14. Likewise 3 (0011) becomes 7 (0110), 4 (0100) becomes 6 (0110) .. etc.
Result: It's actually impossible to read the value at 12 in this case, and it's likely that address 14 holds a different value. If this were a firmware, the bootloader would attempt to verify the firmware on bootup with a CRC check, mangling the addresses would change the data read and the CRC wouldn't match.
In the end, there's nothing really magical about pins 15-16; you can pick any address lines and short them and *something* will happen; if you didn't short the addresses of the bootloader there's a good chance it'll boot up and wait for a firmware.
This hw fix applies to the wrt54g version 2 hardware ONLY (US version). I have not tried it on any other units.
User's assume ALL risk in utilizing this information in any manner what so ever.
If you do not take full responsibility for your own actions, don't read this post any further.
This may ruin you wrt54g Version 2 HW, or other hw, if not a wrt54g, and god know what other possible harm may come to you or others using this information. Use at you own risk. Also, if you bricked your unit, do be a wus and just return it. Take responsibility for you actions, don't sluff it on to others.
Also, be sure you have read and understand http://openwrt.ksilebo.net/temp/00-WARNING.TXT
End of Disclaimer.
Really, you're still reading. This is all up to you, don't blame me, this website or anyone else for problems resulting from attempting to utilize this information in any shape or form. It is up to you to take care of yourself, property, etc.... Use your head, take your time, read twice, flash once or not at all.
Before I begin, props to [mbm], mjn3, and others for all their hard work and getting things to where they are at.
Also, thanks to gps (for being one of the first to use this de-bricking trick).
Enough of that, here's my story and I'm sticking to it.
I'm a dumb-ass and bricked 3 wrt54g hardware v2 units attempting to use b4-pre.
2 of the 3 had boot_wait=on in nvram, the other didn't. It's a funny story, but this post is already running way long.
Here are my lessons learned:
1) Use a normal tftp client for attempting to send an image during the boot_wait interval.
1a Be sure binary mode in enabled,
1b Set the retransmission interval (rexmt 1) in the tftp client to 1 second. Mine defaulted to 5 (you can miss lots of windows with the 5 second interval)
1c With one of my units the tftps were starting, but failing to complete. I needed to go to 10Mb hub and try several times before it completed correctly.
1d If you are familiar with ethereal or other sniffers, it useful to monitor the packets into and out of the unit. That's how I knew, the tftp's were actually starting, but not finishing (no last packet).
1e the status command in the tftp client shows you mode, retransmission intervals and other stuff, use it a check before you type the put code.bin command
1f try to uses a known good images (in my case the image was not known to work on the v2 units)
1g I used the arp -s command to statically set the MAC addr of the wrt (it's on the bottom of the unit).
1i my tftp client is tftp-hpa 0.34 (just fyi for the curious or desperate)
These steps allowed me to de-brick 1 of my three units. The other 2 seemed toast. 1 was rebooting every 3 seconds, and the other was KNOWN to have boot_wait=off and rebooting every 15-20 seconds.
Did I say you should try this at you own risk ? It's all up to you.
The last 2 units we revived by shorting two pins on the flash chip. Specifically, white stenciled pins 15-16 near the LED end of the board.
With the unit that was rebooting every 3 seconds, I kept moving along the address line pins. I had kind of given up hope with the method, when the unit stopped rebooting and I saw the tftp xfer in the ethereal window. The first time surprised me and freaked me out a little. I had to power cycle the unit and find the pins again. I just shorted pins 15-16 together (note there is a white hash mark every 5 pins) and let the unit reboot. The tftp was running all the time with a 1 second rxmit interval and a timeout of 360 or 6 minutes of attempting before reissuing the command. Just like that, the unit was re-flashed. I waited for a couple minutes after the tftp completed (via live scrolling in ethereal) and it woke up de-bricked running the linksys firmware (with a minor ping tweak).
2 units de-bricked, 1 to go.
The flash pin short worked so well, I had to try it on the unit with the boot_wait=off. I had heard there was a tiny window during boot, even with boot_wait=off. I needed to have somebody power-on the unit while I was holding the short on the pins 15-16. You just keep those pins shorted and power-on as the tftp attempts are happening every second and it worked on the first real attempt.
All three unit fully recovered. Ready to test the next b4-pre.
Yes, I verified boot_wait=off on that unit. It was quickly changed to boot_wait=on and committed.
Good Luck fellow adventurers.
Thanks again [mbm], mjn3, and gps. I don't know who the other dev's are.
Oh yeah, last but not least, Ksilebo THANKS for hosting this wonderful effort!