PDA

Bekijk de volledige versie : Funny WAN port dies workaround -- do not try this



Oleg
10-09-2004, 20:25
Guys,

I just want to let you to know. It's possible to workaround the WAN port dies problem by exchanging the roles of WAN and LAN ports. I.e. all 4 ports will become WAN, and WAN port will become LAN.
This requires several changes in the nvram, so I do not want to verify this on my unit. :D
This is very delicate operation. So, if anyone is interested in this, then let me know.

smallkeung
11-09-2004, 05:33
Guys,

I just want to let you to know. It's possible to workaround the WAN port dies problem by exchanging the roles of WAN and LAN ports. I.e. all 4 ports will become WAN, and WAN port will become LAN.
This requires several changes in the nvram, so I do not want to verify this on my unit. :D
This is very delicate operation. So, if anyone is interested in this, then let me know.

e....
it's funny..... i want to know ... Can you tell me?

Oleg
11-09-2004, 09:08
Well, I'm not responsible for any damage. :D

So, there are 2 nvram settings which determies the logical order of the ethernet ports: et0mdcport and et1mdcport. On my unit et0mdcport=0 and et1mdcport=1. So, to exchange these ports you just need to set et0mdcport=1 and et1mdcport=0. Also, there is a setting for phy addresses: et0phyaddr=30 and et1phyaddr=0, they should be also exchanged. So, the exact sequence (using any firmware, including provided by ASUS) should be as follows (execute via www backdoor or telnet/ssh in custom firmwares):

1. Verify current settings


nvram get et0mdcport
nvram get et1mdcport
nvram get et0phyaddr
nvram get et1phyaddr

This should produce 0, 1, 30, 0 correspondingly.

2. Set new values


nvram set et0mdcport=1
nvram set et1mdcport=0
nvram set et0phyaddr=0
nvram set et1phyaddr=30


3. Double check your changes:


nvram get et0mdcport
nvram get et1mdcport
nvram get et0phyaddr
nvram get et1phyaddr

This should produce 1, 0, 0, 30 correspondingly.

4. Commit & reboot


nvram commit
reboot


wl500g should reboot and use WAN port as LAN and vice versa.

The worst thing which could happen (but this is nearly imposible if you strictly follow the steps above) is that it can't boot. In this case wrt54g recover procedure should be used, i.e. shortening the flash pins.

wtzm
11-09-2004, 12:27
Well... I tried this. After the router had rebooted, it wouldn't start anymore. The power led goes on and blinks at regular intervalls (it blinks for the first time about 1 second after powerup, for the second time 9 seconds after powerup, for the third time 20 seconds after power up, ...)
Firmware Restoration isn't working anymore - in the past i could enter it in the usual way (powering down, pressing reset, powering up, releasing reset and the power light was flashing and I could use the ASUS Firmware Restoration Utility to upload a new firmware); the power led keeps blinking in this 8-11 second-intervall as described above.

Oleg
11-09-2004, 12:59
Shit happens...

So you need to either send it for warranty replacement or disassemble it and try the method described at this page
http://voidmain.is-a-geek.net:81/redhat/wrt54g_revival.html

This is for wrt54g unit. Yours use AMD flash - datasheet is at
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/23579c5.pdf

You need to shorten pins 9 and 10 (A19 & A20) or 16 and 17 (A17 & A18) - wl500g should think it has corrupted nvram and restore it using defaults.

In fact, after shortening these pins, it should go to firmware restoration mode and if does so, I will send you special firmware file...

It's better to send it to replacement, I think...

wtzm
11-09-2004, 13:18
hm... Warranty replacement is not an option with a broken warranty seal ;-)
I know of voidmans site and have already tried shortening pins 9 and 10 before switching the wl500g on but this didn't change the situation.
So I thought it would be better to short the exact same address lines as mentioned in voidmans description (pin #9 and #16 on the am29lv320dt). I succeeded in making a connection (it's not easy but possible to solder hair-thin wires with the right tools;)) but unfortunately the situation stays the same.
Well, I guess the unit is really dead - although I really don't know why...

Oleg
11-09-2004, 13:31
If still blinks with power led - it's ok. Pmon is alive.

Ok, if you can desolder pin 9 it will solve your problems. You need the following - desolder it and shorten it to ground. Power in the unit and check it's in recovery mode. It should there.
But do not try to restore the firmware it probably kill pmon!
Let me know if it can enter recovery mode in this way.

Oleg
11-09-2004, 13:38
The idea is following:

nvram address
1111111000000000000000

last pmon address
0000111111111111111111

so, only higher 4 bits could be changed. In fact if we desolder highest bit (pin 10) and shorten it to ground we could the flash 2 megs firmware, which will fix your problems...

wtzm
11-09-2004, 14:14
If still blinks with power led - it's ok. Pmon is alive.
It doesn't blink in the way it would normally blink - in fact it seems like pmon is in a kind of loop judging by the way the led is blinking:
*power is connected* -> LAN leds switch on -> PWR led blinks -> LAN leds switch off -> PWR led on for 8 seconds -> PWR led blinks -> PWR led on for 11 seconds -> PWR led blinks -> PWR led on for 8 seconds -> PWR led blinks -> PWR led on for 11 seconds -> ...
I don't understand why the restore mode isn't working anymore - isn't this a sign that the PMON-code is damaged? Or does PMON need valid data in the NVRAM partition to start the recovery mode?

Ok, if you can desolder pin 9 it will solve your problems.
I will try this, but desoldering only one pin is rather difficult (compared to desoldering a whole TSOP package;))

Oleg
11-09-2004, 14:35
It doesn't blink in the way it would normally blink - in fact it seems like pmon is in a kind of loop judging by the way the led is blinking:
*power is connected* -> LAN leds switch on -> PWR led blinks -> LAN leds switch off -> PWR led on for 8 seconds -> PWR led blinks -> PWR led on for 11 seconds -> PWR led blinks -> PWR led on for 8 seconds -> PWR led blinks -> PWR led on for 11 seconds -> ...
I don't understand why the restore mode isn't working anymore - isn't this a sign that the PMON-code is damaged? Or does PMON need valid data in the NVRAM partition to start the recovery mode?

I will try this, but desoldering only one pin is rather difficult (compared to desoldering a whole TSOP package;))
yes, pmon uses the same nvram data. so, it can't initialize ethernet port.
in fact, you could just try grounding the pin without desoldering it in the hope bcm4702 handles this (it should, but who knows)...
I've already prepared small firmware for you.
The exact sequence should be as following:
1) grounding pin
2) power wl on
3) wait for recover blinking
4) restore the pin
5) flash with small firmware
6) it should boot and stop blinking (but it will not be accessible)
7) turn off, restore connections and try to enter recovery mode
the firmware will be
here (http://wl500g.dyndns.org/wl500g-clear-nvram.trx) in a few moments.

wtzm
11-09-2004, 14:57
Thank you very much for the quick answers and instructions, Oleg! :)
I will try to flash the recovery firmware tomorrow and will post my post my results.

Oleg
11-09-2004, 15:46
Well, hope this helps.
You are the brave one. :)

wtzm
11-09-2004, 18:47
First results: not a complete success but more than nothing ;)
After connecting pin 10 to GND and applying power the router restarted in recovery mode. I removed the connection and uploaded the clear-nvram firmware and rebooted it. After that, I could enter recovery mode by pressing the reset button. I uploaded a normal firmware and rebooted the router.
But then the same problem as before reappeared: Rebooting in recovery mode is not possible and the same LED flashing loop as seen before...
I'll have to review the flash-chip connections tomorrow (this is very strenuous without daylight:rolleyes: ); maybe there is a solder bridge somewhere.

Oleg
11-09-2004, 18:53
Have you desolder pin 10 or just shortened to ground?
Also, just a suggestion - after rebooting the clear-nvram firmware allow it to boot again once more.

wtzm
11-09-2004, 18:54
I just connected pin 10 to ground without first desoldering it.

Oleg
11-09-2004, 19:02
I just connected pin 10 to ground without first desoldering it.
Well, hope bcm4702 survives this... If you've osciloscope you can check this. But as seems it's ok, cause it does not destroys pmon during large firmware upload.

Anyway, if it boots with clear-nvram firmware, then I could make another one with ethernet support...

Be carefull with pin 10 - you can destroy pmon if you attempt to write large firmware, while it's shortened to ground.

Also, after flashing the right firmware - have you tried accessing firmware restoration mode again?

wtzm
11-09-2004, 19:05
If I don't succeed with this method I'll just add a serial port as described by Technik - maybe the PMON messages give us a hint.

wtzm
11-09-2004, 19:08
Yes; after I entering the recovery mode in the normal way (by pressing the RST-button) and flashing one of your "normal" firmwares, I rebooted and tried to enter recovery mode by pressing the button again, but this time it failed.

wtzm
12-09-2004, 10:28
I really have to thank you, Oleg - you made wl500g work again!
ldd showed me that mtdutil needs libnvram, which was missing in the clear nvram firmware; I added it, flashed
it again and my problems were solved (recovery mode + custom firmware working again) :D
The first thing I did after that, was trying the commands from the "wanport workaround" again. (Yes, I know that
this is stupid, but I really had to know if these were the commands that had caused the problem:rolleyes: )
I can now confirm that these nvram settings should _not_ be changed!
Of course this time I already knew what had to be done to restore my wl500g.

Oleg
12-09-2004, 10:48
Well, this is mostly your victory. Please make a how-to on the matter. ;-)
I could probably rebuild clear-nvram firmware, I deleted most of the things from it, including libnvram. ;-)

My respect is going directly to you. ;-)

I've reuploaded 2Megs clear-nvram firmware (http://wl500g.dyndns.org/wl500g-clear-nvram.trx). It should work fine now.

tny
25-11-2004, 23:08
sveasoft seems to have jtag software and a jtag cable for the wrt54g.
maybe it will also work for the wl500g

Antiloop
26-11-2004, 08:47
sveasoft seems to have jtag software and a jtag cable for the wrt54g.
maybe it will also work for the wl500g
as they are sveasoft, they appearently will not share it

tny
30-11-2004, 18:42
as they are sveasoft, they appearently will not share it

can you use parallel port jtag cable here
jtag cable (http://www.lart.tudelft.nl/projects/jtag/jtag-lart_schematic.pdf)

and jtag software here
jtag (http://www.lart.tudelft.nl/projects/jtag/)

or the jkeys jtag software here
jkeys (http://dishnewbies.com/2700_fix.shtml)

here's a post where someone used jkeys to program a st m29w160 which is similar to the flashes in router's.
thread (http://www.edaboard.com/ftopic91032.html)

I think sveasoft connects the parallel port to 8pins on the wrt54g which is the same as it is here.

Oleg
30-11-2004, 18:57
http://www.openwrt.org/forum/viewtopic.php?t=647

tny, why are you looking for this? have you bricked your belkin device?

tny
30-11-2004, 19:31
http://www.openwrt.org/forum/viewtopic.php?t=647

tny, why are you looking for this? have you bricked your belkin device?


the belkin is still working but I've put it aside and will mess with it later. I just can't figure out why the wan port doesn't communicate correctly.
I'm trying to get chupa's working on it so that I have the option of turning it into a bridge.

I have another belkin that I bricked and would like to bring it back to life if possible. I tried shorting the pins but it just won't ping.

Also, I thought having a jtag programmer would be quite useful.

I would like to try other firmware's in my motorola wr850g but everytime I tftp something in, it will just restart with with the motorola firmware. the interesting thing is that it has 32mb ram.

Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.

Initializing Arena.
Initializing Devices.
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.50.21.0
CPU type 0x29007: 200MHz
Total memory: 0x2000000 bytes (32MB)

Total memory used by CFE: 0x8032BAD0 - 0x804313F0 (1071392)
Initialized Data: 0x8032BAD0 - 0x8032E040 (9584)
BSS Area: 0x8032E040 - 0x8032F3F0 (5040)
Local Heap: 0x8032F3F0 - 0x8042F3F0 (1048576)
Stack Area: 0x8042F3F0 - 0x804313F0 (8192)
Text (code) segment: 0x80300000 - 0x80309510 (38160)
Boot area (physical): 0x00432000 - 0x00472000
Relocation Factor: I:00000000 - D:00000000

Device eth0: hwaddr 00-0C-xx-xx-xx-xx, ipaddr 192.168.10.1, mask 255.255.255.0
gateway not set, nameserver not set

*CFE for Motorola WR850G v2.03, Release date: Jan. 13, 2004

Reading :: Failed.: Timeout occured
Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
Loading: ............ 1552384 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000
We got BCM4712 board...
Broadcom 3.51.21.0 version.

KillerOPS
16-08-2005, 00:38
Hello ppl. I bricked my asus wl-500g too. Only sometimes it entered recovery mode. And any firmware i gave it didn't work. However, there was one firmware that worked. And that's the one with clear_nvram. So my router is back alive.

Now some offtopic questions: would be possible to use the firmwares from dd-wrt.com on a asus 500g? That would be awesome. Maybe a merge of the two firmwares (oleg's and dd-wrt). Have a look guys. I particulary love the RFlowCollector program in dd-wrt. And that's how i bricked the asus - tried to write a wrt54g firmware on it - stupid me :(. Anyway, it works again :)

And thanks again for the clear_nvram firmware :D