Thanks, varanoid, for pointing out the wiki pages. I got here following the same path you did and being a newbie to dd-wrt myself, wasn't sure how to do what they were suggesting in this thread.
The router specific wiki page cleared it all up. It would be nice to have a link to that page from the Router Database page.
i got here from the Peacock to and i just thought i would post a little info for those who might come here with a Linksys WRT54GS v1.1 router...
i got this router about a month ago for $5 (i know i got a solid buy on it ) and it had stock Linksys firmware v3.37.x.xxx on it so i updated it to this FIRST...
but basically the link that pmerchant73 linked to above with the 'WRT54GS v2.0' is pretty much what i did for the 'WRT54GS v1.1' router i have as the process is basically the same.
the v2.0 page in his link is updated where as the v1.1 page (i.e. http://goo.gl/kSu1Z (currently OUTDATED as it don't mention to flash to v4.71.4 besides the "Other Notes" part by "[comment added 08/05/10 by crazyzeke]") ) is a little out of date it seems as is not as detailed on the exact process to do in order to avoid any potential bricking (i.e. killing) of the router and it's linking to older non-recommended firmware to.
but after i updated to the newest stock firmware (i.e. that file in my link above) and after the 30 second reset and once i got DD-WRT on the WRT54GS v1.1 router with the MINI build (i.e. dd-wrt.v24-15230_VINT_mini.bin (although the 13491 VINT in the v2.0 Wiki page will be fine to)) i used the 'erase nvram' / 'reboot' commands myself instead of holding reset for 30 seconds and after that was done i used the web interface to flash to "dd-wrt.v24-15230_VINT_mega.bin" (for those who want MEGA build) and after that was done (waiting 5minutes like wiki says) i did another 'erase nvram' / 'reboot' thing and then configured router to my liking.
what i am doing should be safe right? (because i assume that once i initially updated to v4.71.4 FACTORY firmware that it fixes the CFE issues that where talked about in these forums so it don't brick when doing a 30-30-30 or 'erase nvram' commands?)
i just asked that question above to get confirmation from others just to make sure what i am saying is safe for more than just me. _________________ Primary Router: Linksys WRT54GS v1.1 /w dd-wrt.v24_mini_generic (r46640 May 13th 2021) ; new Panasonic capacitors Feb 11th 2020 | Backup Router: Linksys WRT54GS v6 /w dd-wrt.v24_micro_generic (r46640 May 13th 2021)
what i am doing should be safe right? (because i assume that once i initially updated to v4.71.4 FACTORY firmware that it fixes the CFE issues that where talked about in these forums so it don't brick when doing a 30-30-30 or 'erase nvram' commands?)
Why do you think changing the kernel would fix a CFE issue. You could flash dd-wrt, factory firmware or moondogger.bin....none of these will have the slightest impact on the CFE.
what i am doing should be safe right? (because i assume that once i initially updated to v4.71.4 FACTORY firmware that it fixes the CFE issues that where talked about in these forums so it don't brick when doing a 30-30-30 or 'erase nvram' commands?)
Why do you think changing the kernel would fix a CFE issue. You could flash dd-wrt, factory firmware or moondogger.bin....none of these will have the slightest impact on the CFE.
so am i just lucky as to why i can do 'erase nvram'? (because it did it at least twice so far and no issues here)
OR... is that bricking issue solely related of holding the reset button for the full 90 (i.e. 30-30-30) seconds?
i just kind of assumed that since the CFE is a program inside the router that it could be updated from a flash. or is it not possible to be updated during a standard firmware flash? ( i just assumed that maybe the newest 4.71.4 factory firmware might have fixed the 30-30-30 bricking issue )
but assuming your right, i take it that the only fix is to re-flash the CFE after the hex edit? (because i seen some people talking about how to fix it with hex edit etc (i did not look into details on it but i got the basic idea))
but if the bricking is only triggered by holding reset button for the 90 seconds (i.e. 30-30-30) then ill just avoid doing that on the router as i suppose that will be safer than attempting to flash the modified CFE.BIN back to the router through DD-WRT firmware (which it shows how to do on CFE Wiki page)
p.s. and i know that dd-wrt firmware does not flash the CFE. i just figured that maybe the factory firmware may have been able to flash it if they knew that people could kill their routers simply by holding a reset button to long basically.
but i guess if that 30-30-30 bricking was discovered AFTER the date of the newest official firmware than that would answer my question right there. but i don't know the date of the newest official factory firmware off the top of my head. _________________ Primary Router: Linksys WRT54GS v1.1 /w dd-wrt.v24_mini_generic (r46640 May 13th 2021) ; new Panasonic capacitors Feb 11th 2020 | Backup Router: Linksys WRT54GS v6 /w dd-wrt.v24_micro_generic (r46640 May 13th 2021)
I've read several threads on this issue and it's clear that the above commands fix the router so this problem won't occur.
However, I'm assuming that you can only run those commands on a working router, before the problem happens? (or is there a way to get into a bricked one to issue those?)
I have a WRT54GS v1.1 that was bricked by a 30-30-30 a few years ago. I don't know what firmware was on it, don't have any cfe backups and don't even know what ip it was/is on. I only have the unit that just fast flashes the power led forever - no other led's light. I believe this indicates a broken boot loader.
What is/are my way(s) to fix this unit? - do I need to use JTAG?
I have purchased a JTAG cable and the process seems well documented, but please could someone confirm this is what I need to do, before I read up on and attempt it.
As I don't have any cfe backups - do I need to upload someone else's or do. Not need to replace that?
Wow, bit of a surprise to see my post from nearly three years ago being quoted. I still have that WRT54GS 1.1, it's rock solid and works perfectly so worth trying to resurrect yours.
JTAG is the way to go. I got mine working by pin shorting because I didn't have JTAG at that time and needed to do something quick. However, you are definitely on your own if you go that route.
You shouldn't need to do anything to the cfe. Chances are it's still ok. When you can access the router again then you can update the cfe to make the fix permanent if you want. I found some old notes I made at the time about this.
1. Backup cfe using http://192.168.1.1/backup/cfe.bin
2. Edit cfe.bin using an editor which allows binary editing. Change boot_wait=off to boot_wait=on and sdram_init=0x000b to sdram_init=0x010b (I think I used bpe on linux to do this).
3. Copy updated cfe back to the router to /tmp/newcfe.bin
4. Enter command mtd unlock cfe
5. Enter command mtd write -f/tmp/newcfe.bin cfe
1. Backup cfe using http://192.168.1.1/backup/cfe.bin
2. Edit cfe.bin using an editor which allows binary editing. Change boot_wait=off to boot_wait=on and sdram_init=0x000b to sdram_init=0x010b (I think I used bpe on linux to do this).
3. Copy updated cfe back to the router to /tmp/newcfe.bin
Doesn't the: erase nvram, nvram set sdram_init=0x010b do the same? - or is that way not permanent?
Which part of the JTAG process did you find fixed this problem?
I've got the JTAG pins on, wrt54g -probeonly seems to regognise an Intel chip, wrt54g -erase:nvram worked ok but the problem seems to be still there and i'm just running -erase:kernel now....
Will the kernel one fix it and allow tftp upload of a new image?
It wasn't JTAG that got mine working initially. As I said earlier I did the pin shorting method. Anyhow, I guess it doesn't really matter now as you found the solution.
All seemed to be working ok, so I used PSPad (which someone else mentioned) to edit a saved cfe.bin file with the 2 changes you mentioned, used winscp to copy it up and used those commands to write it.
Reboot seemed to work ok, so I decided to try a 30/30/30.....however this bricked it again!
Still had the JTAG connected, so erased nvram and kernel like I did before but it didn't seem to do anything.
I'm just trying to restore the cfe.bin I (luckly) backed up with JTAG earlier.
Hopefully that will fix it again, and if it does, i'll try and JTAG the modified cfe.bin over instead of using ssh.
When you changed boot_wait from off to on, did you just leave a space after the on?
No, I didn't leave a space after the "on". I'm not sure if that is what caused your problem though. As I understand it, boot_wait=on means the router pauses longer during the boot process to allow the tftp of firmware. I read somewhere on here a long time ago that it makes it easier to recover from a bad flash.
) and it had stock Linksys firmware v3.37.x.xxx on it so i updated it to this FIRST...