*SOLVED* WRT54GS resetting NVRAM bricks router...

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3  Next
Author Message
pmerchant73
DD-WRT Novice


Joined: 26 Mar 2011
Posts: 1

PostPosted: Sat Mar 26, 2011 15:22    Post subject: Reply with quote
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.

http://www.dd-wrt.com/wiki/index.php/Linksys_WRT54GS_v2.0
Sponsor
ThaCrip
DD-WRT User


Joined: 05 May 2008
Posts: 299

PostPosted: Fri Jun 10, 2011 7:39    Post subject: Reply with quote
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 Wink ) and it had stock Linksys firmware v3.37.x.xxx on it so i updated it to this FIRST...

http://homedownloads.cisco.com/downloads/firmware/WRT54GSv3_4.71.4.001_fw.bin (which is the current newest STOCK firmware for the WRT54GS v1.1 router)

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.

_________________
Linksys WRT54GS v1.1 /w dd-wrt.v24_mini_generic (r43190 May 18th 2020) @ 240Mhz ; new Panasonic capacitors Feb 11th 2020 | ASUS WL-520gU /w dd-wrt.v24_mini_generic (r43192 May 19th 2020) | Linksys WRT54GS v6 /w DD-WRT v24-12548_NEWD_micro | Belkin F5D7230-4 v1444 /w dd-wrt.v24_micro_generic (r41392 May 19th 2020) @ 240Mhz
OrangePeel
DD-WRT User


Joined: 23 May 2011
Posts: 51

PostPosted: Fri Jun 10, 2011 12:45    Post subject: Reply with quote
ThaCrip wrote:
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.
ThaCrip
DD-WRT User


Joined: 05 May 2008
Posts: 299

PostPosted: Sat Jun 11, 2011 4:09    Post subject: Reply with quote
OrangePeel wrote:
ThaCrip wrote:
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.

_________________
Linksys WRT54GS v1.1 /w dd-wrt.v24_mini_generic (r43190 May 18th 2020) @ 240Mhz ; new Panasonic capacitors Feb 11th 2020 | ASUS WL-520gU /w dd-wrt.v24_mini_generic (r43192 May 19th 2020) | Linksys WRT54GS v6 /w DD-WRT v24-12548_NEWD_micro | Belkin F5D7230-4 v1444 /w dd-wrt.v24_micro_generic (r41392 May 19th 2020) @ 240Mhz
ichilton
DD-WRT User


Joined: 26 Jun 2007
Posts: 115

PostPosted: Sun Jun 19, 2011 8:28    Post subject: Reply with quote
Hi,

vulcan59 wrote:
erase nvram
nvram set sdram_init=0x010b
reboot

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?

Thanks,

Ian
vulcan59
DD-WRT User


Joined: 26 Apr 2008
Posts: 65
Location: UK

PostPosted: Sun Jun 19, 2011 10:43    Post subject: Reply with quote
Hi Ian,

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

Hope that helps. Good luck.
ichilton
DD-WRT User


Joined: 26 Jun 2007
Posts: 115

PostPosted: Sun Jun 19, 2011 11:57    Post subject: Reply with quote
Hi,

Thanks - i'm going to work on the JTAG now.

vulcan59 wrote:
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?

Thanks,

Ian
vulcan59
DD-WRT User


Joined: 26 Apr 2008
Posts: 65
Location: UK

PostPosted: Sun Jun 19, 2011 12:20    Post subject: Reply with quote
ichilton wrote:
Hi,

Doesn't the: erase nvram, nvram set sdram_init=0x010b do the same? - or is that way not permanent?


Those commands do not permanently update the cfe. You either need to enter the commands each time you do a reset or permanently update the cfe.
ichilton
DD-WRT User


Joined: 26 Jun 2007
Posts: 115

PostPosted: Sun Jun 19, 2011 13:07    Post subject: Reply with quote
Hi,

ok, that makes sense.

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?

Thanks,

Ian
ichilton
DD-WRT User


Joined: 26 Jun 2007
Posts: 115

PostPosted: Sun Jun 19, 2011 13:33    Post subject: Reply with quote
ok, kernel one worked!
(the 2nd time at least, 1st time seemed to get stuck so I stopped it, started it again and it worked).

I've now uploaded a mini firmware via tftp and am going to look at doing the above fix.
vulcan59
DD-WRT User


Joined: 26 Apr 2008
Posts: 65
Location: UK

PostPosted: Sun Jun 19, 2011 14:09    Post subject: Reply with quote
Excellent. Sounds like you're nearly there.

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.
ichilton
DD-WRT User


Joined: 26 Jun 2007
Posts: 115

PostPosted: Sun Jun 19, 2011 14:24    Post subject: Reply with quote
Hi,

Ah yes, you did say that.

It's all gone a bit wrong again though.

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?

What does boot_wait do anyway?

Thanks,

Ian
vulcan59
DD-WRT User


Joined: 26 Apr 2008
Posts: 65
Location: UK

PostPosted: Sun Jun 19, 2011 14:38    Post subject: Reply with quote
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.
vulcan59
DD-WRT User


Joined: 26 Apr 2008
Posts: 65
Location: UK

PostPosted: Sun Jun 19, 2011 14:43    Post subject: Reply with quote
Here's the relevant bit of my cfe so you can see what it looks like.

Code:
ADDRESS      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F   ASCII
-------------------------------------------------------------------------------
0x00001200   30 00 6F 73 5F 72 61 6D 5F 61 64 64 72 3D 38 30   0.os_ram_addr=80
0x00001210   30 30 31 30 30 30 00 6F 73 5F 66 6C 61 73 68 5F   001000.os_flash_
0x00001220   61 64 64 72 3D 62 66 63 34 30 30 30 30 00 6C 61   addr=bfc40000.la
0x00001230   6E 5F 69 70 61 64 64 72 3D 31 39 32 2E 31 36 38   n_ipaddr=192.168
0x00001240   2E 31 2E 31 00 6C 61 6E 5F 6E 65 74 6D 61 73 6B   .1.1.lan_netmask
0x00001250   3D 32 35 35 2E 32 35 35 2E 32 35 35 2E 30 00 73   =255.255.255.0.s
0x00001260   63 72 61 74 63 68 3D 61 30 31 38 30 30 30 30 00   cratch=a0180000.
0x00001270   62 6F 6F 74 5F 77 61 69 74 3D 6F 6E 00 77 61 74   boot_wait=on.wat
0x00001280   63 68 64 6F 67 3D 35 30 30 30 00 62 6F 6F 74 6E   chdog=5000.bootn
0x00001290   76 5F 76 65 72 3D 32 00 00 00 00 00 00 00 00 00   v_ver=2.........
ichilton
DD-WRT User


Joined: 26 Jun 2007
Posts: 115

PostPosted: Sun Jun 19, 2011 16:41    Post subject: Reply with quote
Hi,

All working again now - and i've just done a 30/30/30 and all seems fine!

I have a hunch that what I might have done the 1st time around is used 001 instead of 010 in the modification.

I did have to leave a space after on as it wouldn't let me delete the f so I had to make it a space. All seems ok though.

Thanks for your help!

Ian
Goto page Previous  1, 2, 3  Next Display posts from previous:    Page 2 of 3
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum