OpenWrt Forum Archive

Sad but true:

I had a WR850G running perfectly with openwrt rc3 (openwrt-motorola-squashfs.bin flashed onto a virgin wr850g straight out of the box). I named him thomas; sorry if anyone is confused when I refer to him by name, but our relationship is strong despite only knowing each other for a short time. I added the nas binary and it was working perfectly with wpa-psk. I added a cell phone data cable usb serial port. The only issue was the wireless LED which never did anything. Life was pretty good, but now it's gone... all gone *sob.*

I suppose I should have left well enough alone, but I thought I'd try overclocking to see if I could squeeze out a little more performance since I was running encryption. I didn't have any benchmarks for comparison, but it seemed like fun and I was on a roll. boot_wait is set (and remains so through power cycles although I have heard of thomas' wrt850g siblings not retaining this setting). It all started innocently enough:

# nvram set clkfreq=264
# nvram commit
# reboot

With the serial connection, I watched the entire process and it was all fine. The processor reported 264MHz. However, after about 1 minute thomas abended, spewed a register dump to the console and rebooted himself. No big deal, it'll be alright buddy. He came back up just the same, but again rebooted after a minute; better try something else. According to the wiki overclocking some routers (200 to 216) helps stability, so I'll try to apply that by overclocking my overclocking:

# nvram set clkfreq=300
# nvram commit
# reboot

Looking good: processor running at 300MHz, but this time we don't even get to busybox before self-booting, not even close. Dang, but not a problem because I can crtl^c through the serial console when thomas waits for me to flash a new firmware if I'd like. This jumps into the CFE where I can still set nvram variables:

CFE> nvram set clkfreq=200
CFE> nvram commit
CFE> reboot

Right as rain and stable for over 15 minutes until I decide that the overclocking experiment must continue. I tried using the SBClock as well:

# nvram set clkfreq=264,132
# nvram commit
# reboot

Same problem, reboot after 1 minute. Now I'm tired of waiting for busy box, so I ctrl^c into CFE and figure I can just set what I want there to seee what happens since thus far I've never had any problems getting into the serial console. This is where my story develops a point because I tried:

CFE> nvram set clkfreq=288
CFE> nvram commit
CFE> reboot

I didn't mention this before, but the reboot command in CFE never did seem to work. The nvram settings were committed, but reboot would just sit there until I power cycled or reset via the button. Apparently, 288 was not a good setting to attempt because now I got nuthin' but apparently useless LEDs.

No serial console output. I use WindowsXP hyperterminal, and it was fine up until now.

When thomas fires up, the LEDs (except wireless which I don't think has ever done anything) light orange for about 1/2 second, then all green. If I connect an ethernet cable to my laptop, that light (LAN 1-4 or WAN) is orange, and blinks irregularly with LAN activity. These symptoms have been described in another post which on second thought I should have added to instead of starting a new one, sorry. If I hit reset, the LEDs (except wireless...) behave basiacally as I would expect. Power: solid green, LAN and WAN green when connected while occasionally blinking with activity.

I can't ping or tftp. I tried 192.168.10.1 since this seems to be hard-wired into thomas' genetic code. I tried 192.168.1.1 since OpenWrt and most firmwares use this defautl. I tried 192.168.192.169 (subnet 255.255.255.248) since this was lan_ipaddr before the fall. nothing, zip, zero, nada.

I am not a linux or harware guru, but I don't think it is even getting to the point where I could flash the firmware through tftp. From my experience with the serial console I am pretty sure I'd know when the tftp window opened with the boot loader messages. I don't think it's even trying to wait.

JTAG time. But, I don't have the parts lying around, so I'll have to get out shopping. Patience is not one of my strong suits, so I start the short pins method, but it has not gotten anywhere yet.

Still JTAG time, so that's what I will attempt when I can get parts. does the CFE nvram do the same thing as the "normal" nvram, or does it overwrite the CFE defaults? Is that even possible? I thought the first 256k of flash was basically untouchable without modifying the kernel. Have I trashed the bootloader? I think (hope) I can repair that if so.

Anyway, this last bit is pretty much beyond my knowledge, so I'm just guessing. However I think I will need (at the least) a good cfe.bin from a wr850gv2 intel flash. If I need to fix the bootloader can I do that through jtag or not?

I think this is a brick--my first time
I wish I had a brick that would show me the openwrt banner--that I could fix; it's not a brick; it's just misconfigured.

Any suggestions?

p.s. I was thinking I'd rather buy a jtag cable than build one, but I can't seem to find where to do so. ebay seemed promising, but I'd like some better idea of what I was getting. I know the board has no pin block and I'll have to solder anyway, but I think adding a pin block and keeping the cable separate is within my capability.