OpenWrt Forum Archive

Topic: Hairydairymaid debrick vs. jtag tools

The content of this topic has been archived on 2 Mar 2018. Unfortunately there are posts – most likely complete pages – missing.

I found some interesting things about the wrt54g debrick utility when trying to erase or flash the NVRAM on the Motorola WR850G v3. 

The program will not ERASE the flash in that location of the NVRAM 1fff0000.  If you attempt to flash that area it does try to erase it but really does not and then will only overwrite the nvram area with your nvram.bin by changing any 0 bits to a 1.  Trying to erase the NVRAM with the command wrt54g.exe -erase:nvram will not erase anything.  Trying to flash the NVRAM will result in a corrupted NVRAM because the program does not erase before flashing.   The -erase:nvram should change all bytes in the nvram area to FF but it doesn't - just gives the 0 blocks erased message. 

I believe this is happening because the minimum block size for the debrick utility is 128K and the flash area is only 64K. 

To get around this, I used a custom erase of
wrt54g.exe -erase:custom /window:1fc00000 /start:1ffe0000 /length:1  This will erase the upper 64K of the kernel (which isn't being used anyway) along with the entire 64K of NVRAM in flash memory.  Then I've been able to flash a new NVRAM.BIN or just let the CFE create a new one.

Jeff

(Last edited by dobkin on 29 Dec 2010, 01:38)

Hey Jeff,

So if it is NOT implemented into the CFE then I am curious why does one find a string "boot_wait" if one lookd at the CFE binary with a hex editor such as Hex Workshop. I looked at the binary which I just freshly downloaded using debrick utility via jtag and I swear - I can find a string that says "boot_wait"

Of course it could be something other than the actual message that CFE sends but then the question is where would the CFE be seding messages to begin with? There is no such thing as CFE debug via serial or whatever right?

The CFE in general is a basic IP stack with TFTP server integrated plus Broadcom int handlers etc just to make the platform run and not reset itself by the watchdog, etc complexities related to the hardware.

Anyway, if you find anything else do post it here. I am interested as I am sure are all the others fellas

~Boyan

Hello All,

I've got several Motorola WR850G routers that are half-bricked and I just can't get them to play nice on the wired ports.

I can access via WLAN but not LAN/WAN ports.
It doesn't matter what firmware I use, the symptoms are the same.

Any suggestions would be greatly appreciated.
Thanks in advance,
John

I have the WRT54G v6.0 router, which has the Broadcom BCM5352 Rev 1 CPU (CPU Chip ID: 0535217F).

I have made a JTAG cable, and it appears to be working (at least I am able ti pull the CPU id from the router), and I am running version 4.5 of the tool.

Can't seem to get anywhere.

After the tool reads the CPU Chip ID, then does "Issuing Processor / Peripheral Reset ... Done"
It stalls on "Enabling Writes ..."
Doesn't go any further.

I have tried using various options like /nodma, /noemw, /noreset. I have also tried to do the -backup:cfe and -erase:nvram,
and nothing has worked.

Please, can anyone point me in the right direction to get this working?

Wow this is a blast from the past wink

The /noemw (IIRC) tells the tool not to try to enable memory writes - are you still getting the message "Enabling Writes ..." when you use the /noemw switch?

Telek wrote:

Wow this is a blast from the past wink

The /noemw (IIRC) tells the tool not to try to enable memory writes - are you still getting the message "Enabling Writes ..." when you use the /noemw switch?

Hello,

I have the same problem with my WRT54G V6 router. I've build the jtag cable, and trying to run wrt54g.exe program. It is stopping on "Enabling Memory Writes...". The "/noemw" option helps me to skip this step. What actually this step mean ("Enabling Memory Writes")? What means if it is freezing on this step?

So did you succeed in reviving your router? What steps did you follow?

Thank you in advance...

The discussion might have continued from here.