OpenWrt Forum Archive

Topic: Reflashing CFE using JTAG + HairyDairyMaid util

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

I recently bricked my router, a WRT54g v1.0, and was unable to recover using the shorting pins + tftp method, so I constructed a JTAG cable and I am trying to reflash the CFE using the utility written by HairyDairyMaid.  I got a new CFE.bin from this site: http://lonewolf.hacker-nin.com/wrt/cfe/

I am running the utility on Windows.  I loaded the giveio driver, and I was able to get my PC to talk to the router, and I get the following output, using v4.5 of the utility:

******************************************************

C:\openwrt\flash>wrt54g -flash:cfe /noreset /nobreak /silent

====================================
WRT54G/GS EJTAG Debrick Utility v4.5
====================================

Probing bus ... Done

Instruction Length set to 5

CPU Chip ID: 00000100011100010000000101111111 (0471017F)
*** Found a Broadcom BCM4702 Rev 1 CPU chip ***

    - EJTAG IMPCODE ....... : 00000000100000000000100100001000 (00800908)
    - EJTAG Version ....... : 1 or 2.0
    - EJTAG DMA Support ... : Yes

Issuing Processor / Peripheral Reset ... Skipped
Enabling Memory Writes ... Done
Halting Processor ... Skipped
Clearing Watchdog ... Done

Probing Flash at (Flash Window: 0x1fc00000) ... Done

Flash Vendor ID: 00000000000000000000000000000001 (00000001)
Flash Device ID: 00000000000000000010001011111001 (000022F9)
*** Found a AMD 29lv320DB 2Mx16 BotB   (4MB) Flash Chip ***

    - Flash Chip Window Start .... : 1fc00000
    - Flash Chip Window Length ... : 00400000
    - Selected Area Start ........ : 1fc00000
    - Selected Area Length ....... : 00040000

*** You Selected to Flash the CFE.BIN ***

=========================
Flashing Routine Started
=========================
Total Blocks to Erase: 11

Erasing block: 1 (addr = 1fc00000)...Done

Erasing block: 2 (addr = 1fc02000)...Done

Erasing block: 3 (addr = 1fc04000)...Done

Erasing block: 4 (addr = 1fc06000)...Done

Erasing block: 5 (addr = 1fc08000)...Done

Erasing block: 6 (addr = 1fc0a000)...Done

Erasing block: 7 (addr = 1fc0c000)...Done

Erasing block: 8 (addr = 1fc0e000)...Done

Erasing block: 9 (addr = 1fc10000)...Done

Erasing block: 10 (addr = 1fc20000)...Done

Erasing block: 11 (addr = 1fc30000)...Done


Loading CFE.BIN to Flash Memory...
   4%   bytes = 12216

********************************************

It always halts at this point during the flash.  I have tried starting the flash within 1 second of the router being powered on, or powering it on and waiting an hour or two, but to no avail.  I have to use the /noreset /nobreak switches or it halts during the "Clearing watchdog" step.  Before I tried this, I was able to successfully run -backup:cfe, -erase:nvram, and -erase:kernel, but unfortunately that still did not produce a ping response, so I am trying to reflash the CFE.  Does anyone have any idea why this might be failing?  Could it be a problem with the CFEs from that site?  I don't think that's it since it fails even while trying to reflash the backup.  Could it be a problem with the cable, or with my PC?  Should I try running the utility from Linux?  Any ideas or thoughts would be greatly apprecated, as non v5 routers are currently a bit expensive on ebay.  Thank you very much.

-Anthony

I constructed a CFE.BIN using the utility you posted and I tried it again, but I still get the same result.  It hangs at "4%   bytes = 12216".  Actually, the link that I posted in my original post did allow me to specifiy the MAC address of the router so I doubt that's the problem.  That is a pretty useful tool to have around though.  Any other ideas?  This is really annoying.

Wow, okay, so I got it to work.  This is weird though.  The only way I was able to get the CFE to work was to create a CFE for a WRT54G v1.1 - however, my WRT is -definitely- a 1.0.  The serial number starts with CDF1 and the wireless NIC is a mini-pci card, not soldered to the board.  But as soon as I tried the CFE.bin for a 1.1, it loaded flawlessly and sat there and waited patiently for me to tftp it some OpenWRT goodness, and in a few minutes I was staring open-mouthed at a telnet prompt.  Well, I guess I don't care much why it's working, as long as it's working, but has anyone ever ran into this issue before?  Maybe the v1.0 CFEs that are out there on the net are not correct.  Oh well, thanks for your help.

-Anthony

hmmm this is soo strange. The jtag should be loading ANY file into flash no matter the substance of the file itself. Why would it lock up with different CFE?

Anyone has any good ideas about that? I shoud be able to load most any CFE, of course doesnt mean the router will work but the LOAD SHOULD WORK all the time?

Thanks
~Boyan

What´s the diferences to use HeiryDairyMaid util with WRT54G version 6 ? Where can i get an updated CFE for this hw ?

theunf wrote:

What´s the diferences to use HeiryDairyMaid util with WRT54G version 6 ? Where can i get an updated CFE for this hw ?

I saw v5 CFE at the site that the original poster worte:

http://lonewolf.hacker-nin.com/wrt/cfe/

Oops my bad, you need v6 and that is NOT published on the German site.

(Last edited by ds18s20 on 5 Mar 2007, 06:37)

midblue wrote:

It always halts at this point during the flash.  I have tried starting the flash within 1 second of the router being powered on, or powering it on and waiting an hour or two, but to no avail.  I have to use the /noreset /nobreak switches or it halts during the "Clearing watchdog" step.  Before I tried this, I was able to successfully run -backup:cfe, -erase:nvram, and -erase:kernel, but unfortunately that still did not produce a ping response, so I am trying to reflash the CFE.  Does anyone have any idea why this might be failing?  Could it be a problem with the CFEs from that site?  I don't think that's it since it fails even while trying to reflash the backup.  Could it be a problem with the cable, or with my PC?  Should I try running the utility from Linux?  Any ideas or thoughts would be greatly apprecated, as non v5 routers are currently a bit expensive on ebay.  Thank you very much.

-Anthony

I just recently had the EXACT same problem with my WRT54G v1.0. Flashing with CFE.BIN would stop/freeze at 4% no matter what I do. I will try your solution and see what happens. I will post the results as soon as I try that....

Ray_A wrote:

I just recently had the EXACT same problem with my WRT54G v1.0. Flashing with CFE.BIN would stop/freeze at 4% no matter what I do. I will try your solution and see what happens. I will post the results as soon as I try that....

Wow...The same solution (loading a CFE.BIN for version 1.1 of the router) worked for me as well.  The CFE.BIN is being flashed as we speak and it already past %4 mark where it used to freeze before. Let's see how the rest of the recovery will go. Will post results...

Ray_A wrote:

Wow...The same solution (loading a CFE.BIN for version 1.1 of the router) worked for me as well.  The CFE.BIN is being flashed as we speak and it already past %4 mark where it used to freeze before. Let's see how the rest of the recovery will go. Will post results...

SUCCESS!! with flashing the CFE.BIN. Now the red diag led is off and other LEDs started to flash too. Looks like the router will be back in business. Further updates will follow....

YUP!, back in business with the version 4.30 of the stock firmware flashed and the config data recovered from disk.  Awesome!!!.... I almost tossed this router to garbage. Now it's time to de-commission the D-Link DI-624 (which keeps dropping network connections) I was using as a replacement. My old trusty Linksys never had that kind of problem and it was rock solid.... Many thanks go to each and every person who shared/made available their experiences/knowledge in debricking.

im out of business, is there a linux version of skynet?  i really do NOT want to wine skynet repair kit to generate cfe images as i do not want to install wine to support a singular prog and have wine cluttering things up.

The discussion might have continued from here.