Microsoft MN700 hack project

[qaffle]

Under windows or linux my flash stops at just over 5% and hangs. If I kill the process and retry it I get an error that it cannot locate the AMD Flash chip. So I unplug it and try again and ...

It always stops at the same place, so what could this be? Did I kill the router when I decided to stop the flash?

Not sure what the problem was. But I just kept trying to flash it. Erased it a bunch of times, repeat. Eventually I just gave up, started it one last time and went to bed, then it worked...

Might have been the cable shorting or something, I double and triple checked and it didn't seem to be touching, but it was late and I couldn't really tell.

I should make a FAQ of all my problems...

[Soler]

Not sure if anyone is still reading this thread but thought I'd try anway.

I successfully flashed my MN-700 following the directions in this thread and was using Oleg's latest custom firmware 1.9.2.7-6b. I'm been very happy with the additional features and specifically the fact that I didn't have to reboot the router after heavy downloading periods as before with the MS firmware. However, I did notice the following problem where the wireless signal decreases over time and my laptop can't get an ip address. Here's the scenario:

1. after rebooting the router, all is fine. My laptop can pick up the ssid and the signal is good.
2. after a period of approx 12 hrs, sitting in the same spot as previously, the laptop can't pick up the ssid. It seems the wireless signal decreases over time.
3. only a reboot of the router will re-enable the wireless signal and allow my laptop to pick up the ssid.
4. i'm using wep, haven't tried with it wide open.
5. tried increasing the radio signal from 19 to 30 but still had the problem.
6. tried the official asus firmware but had problems with wired lan connections accessing the internet while using BT. Even the router config page was timing out.
7. currently have restored the MS firmware to see if it's a hardware problem with the router.

While using the MS firmware, I never had any of these issues. Just wondering if anyone is running into similar problems.

Thanks.

[jochen]

Hi,

i just installed OpenWRT on my MN-700 and now this beast is a really advanced DSL router including DynDNS, IPv6 and VPN support

Some hints to others:

Flashing the CFE seems to be the most tricky part. I had to retry several times until the read back CFE and the original one didn't differ. Maybe it's a side effect of using /noreset, as it looks like the CPU starts running after most of the CFE is flashed and this might cause the watchdog to interfer. No clue why the debrick tool hangs after resetting the CPU.

Directly installing OpenWRT after flashing CFE didn't work for me (OpenWRT simply hung). Probably, OpenWRT is confused by the empty NVRAM. So I installed Olegs firmware first, booted it once and than replaced it by OpenWRT.

The Broadcom ethernet driver et.ko runs unstable and causes reboots in WhiteRussian RC3 and RC4. Installing kmod-b44 and replacing et by b44 in /etc/modules fixes this problem. RC5 has fixed this problem.

Thanks to all to make this happen!

Jochen

[edfcmc]

Ok, I've:
(1)Built my passive JTAG.
(2) Ran Wrtmodified and backed up the firmware.


But I cannot run nvserial from kubuntu. It says command not recognized or something to that effect.

What am I doing wrong? Can somebody just email me a cfe.bin with the following mac:
00:0D:3A:23:FB:6A

edfcmc@(no spam)yahoo.(no spam).com

[ericj]

Ok, I've:
(1)Built my passive JTAG.
(2) Ran Wrtmodified and backed up the firmware.


But I cannot run nvserial from kubuntu. It says command not recognized or something to that effect.

Two things.

1: You have to be in the same directory as it and preface it with a period and a forward slash: ./nvserial

2: It has to be executable. It might not be. Try 'chmod +x nvserial' to make it executable.

[ericj]

I installed linux yesterday on an MN-700 that i bought used at a thrift store for $5.

It was essentially dead when i got it - the 1500uf cap right next to the jtag port was bulging and leaking, so i replaced it. 1500uf 6.3v isn't a size i keep around, so i replaced it with an old cap pulled from an old motherboard paralleled with a very new, low-esr 220uf and an 0.1uf ceramic disc.

An EE friend of mine suggested the old cap may have failed in part due to high frequency ripple that a small ceramic or film cap would take care of. I'll buy a nice Nichicon UPW 1500uf 6.3v the next time i order from Mouser, but for now this mess of caps seems to be working just fine.

While people are in there, they should check to make sure this capacitor is flat across the top, and is not leaking. It's the reservoir capacitor at the end of the switchmode dc-dc converter that turns the unregulated 12vdc power input into regulated 3.3vdc, and the whole board relies on it. If it looks like it's bulging on the top, you should replace it. Mouser part number 647-UPW0J152MPH is superior to the original capacitor. Please remember to observe polarity when replacing electrolytic caps.

A tip for people having trouble installing the header: It's nearly impossible to suck the solder out of the ground holes, since they're connected to ground plane on both sides of the board. I have a very good Weller WTCPn soldering iron and I'm reasonably well experienced with my solder sucker and i couldn't get it done.

It's much easier just to drill out the solder. You will need a fairly tiny bit - Harbor Freight Tools sells a selection of eensy carbide bits for use in rotary tools for a few bucks. They're essentially pcb drill bits - and they have a color-coded plastic ring on the shank. All you have to do is hold it between thumb and forefinger and twist - solder comes out like it's cheese.

As for the passive jtag interface: Using one of these things is just begging for trouble. Since you only have to get the CFE loaded once, I guess it's reasonable to go cheap & easy with the jtag interface.

If you have to do more than one, it might be worth your while to build a buffered jtag. All you need is a 74hc244 (or 74ls244 in a pinch), a 3v power supply (batteries work fine - even a single 3v lithium coin), and a few standard resistor networks. I can post a schematic & instructions if someone wants it.

In any case, it's unfortunate that the instructions floating around the 'net don't stress that the user should certainly read back the CFE after flashing it and diff it against the one they tried to load. There is a relatively high probability of corruption with a passive jtag like this. It may take a few tries.

It would help if people actually grounded the ground lines on the ribbon cable, too.

Also, iirc it wasn't clear in the instructions that /noreset may actually be required on this hardware. Which means that we're jtagging dangerously.

Here's the skinny: the JTAG debugger interface is a method of giving the cpu commands without having to modify memory. When you program a flash chip through jtag, you're very slowly giving the cpu commands that modify memory. If there's already a program running, it may shoot you in the foot.

Usually, in these situations, there's a jumper or pads somewhere on the board that you can short at power-on time to trap the bootloader, so that the board powers up but no programs are loaded - it doesn't actually boot up. If we have that on the mn-700 board, I don't know where it is.

That being the case, I'd recommend that people first erase the CFE (./wrt54g -erase:cfe /noreset) and then power cycle the board before attempting to program the new CFE. I'm certain you can get away without doing that, but I prefer to improve my odds of success rather than live dangerously.

While you're in there, you should probably -erase:nvram as well.

As for the rest of the process:

I started out trying to follow the recommended instructions, and have come to the conclusion that this was a waste of time. Maybe it's just because I'm a big geek, but as i started trying some different images, i found it to be much more convenient to stay in linux and use tftp per the openwrt instructions for the wl500g than to reboot into windows and use the asus utility.

Note that in linux, if your network is not already 192.168.1.x, you'll need to become root and "ifconfig eth0:0 192.168.1.2 netmask 255.255.255.0 up" to access the box until you change the address.

Note that unless the nvram has been erased, the bootloader will boot up with the last ip address the box was configured to use. If that wasn't 192.168.1.1, tftp won't find it there. if you erase the nvram, it'll default back to 192.168.1.1.

I also didn't find a way to erase the nvram from within windows - maybe I just didn't have all the right asus goo? doesn't matter at this point.

The modified version of 1.9.2.7-7b for the WL500g was horribly unstable on my mn-700. It seemed like it didn't always boot up, and then I'd go try to configure it to use the correct network, and it'd work as an access point but i could never get back into the administration interface until i reloaded the flash again.

The 1.7.5.9-5 version didn't have that problem, but it sure wasn't happy with the nvram left over from 1.9.

I have no stability problems with OpenWRT WhiteRussian RC4. As noted above, the et driver should be replaced with the b44 driver. In future OpenWRT releases, this is rumored to be the default.

The switch ports don't seem to work in OpenWRT - I think the bridge stuff just isn't set up properly, and I'll look at that later. There's a kmod-switch package for OpenWRT that's supposed to do a better job of this, but it isn't available for RC4. I may track it down anyway.

I recommend the jffs2 version of OpenWRT. you need the regular 'brcm' trx file.

I have had no stability issues whatsoever with OpenWRT. I never ran into the problems people have had witht he et driver, but i wonder if this is what was really causing the problems with the latest wl500g firmware. Maybe it's using the same driver, and when it starts up it's got a ton of daemons running and it's very chatty on the ethernet - maybe that's enough traffic to cause the instability. When OpenWRT boots up, it's not doing anything fancy, and the web administration interface isn't enough to give it fits.

Note that it's normal for the jffs2 version of openwrt to boot up with a read-only filesystem the first time around. But you can just reboot it. Or telnet in and 'mount -o remount,rw /', probably.

I haven't grokked what incantation i need to use to turn on the power LED when it's finished booting, but I'll figure it out. I'm aware of the gpio stuff that needs to be done, but my shell scripting mojo is very rusty.

[edfcmc]

Thanks Eric for the comments. Oleg was kind enough to send me a modified cfe.bin with the appropriate MAC, but I still want to figure out how to get nvserial to work. (I will try later on tonight when I have some time to devote to this project.).

Electrolytic Cap
Yeah, I noticed that my electrolytic cap was bulging just a tad. I guess even Microsoft was inflicted by the bad cap disaster that started in Taiwan. (See www.badcaps.net for pictures, story etc.) I plan on replacing it once I get a large enough order for Mouser.

Solder
Luckily my hardware skills are better than my software skills, but I picked up this tip either from Nuts & Volts forums or from badcaps.net forums, but a great way to clear holes from printed circuit boards is to use a stainless steel dental pick (or needle) while heating the hole and pushing through the hole since the solder cannot stick to stainless steel. Another option is to use a long piece of solid gauge coper wire like from a cat 5 cable or coax such as rg6 and use it like above (push trough the hole while heating it with the soldering iron). Obviously the solder is going to stick to the copper wire so once it is used it is useless afterwords. I've been able to clean holes using the dental pick technique with a 5 dollar soldering iron. ALthough I've been itching to get a Metcal pretty soon. SOlder wick might work in general if we are not talking about a multilayered through hole board also but it is more of an art to get used to desoldering stuff with it without pad lifting etc. THe drill technique works great too as i've had to use that trick also; the only downside to the drill technique is the loss of burning smell of flux and solder and the finger burns from mistakenly touching the wrong of the soldering iron when trying to clean the holes.

Jtag Cable
Can you please post your schematic for the buffered jtag? I've seen a couple on the 'net and I would just like to compare for reference. The one's I have seen make a big stink about the use of a 74HCT for TTL levels from the parrallel port. I plan I building a universal buffered jtag pretty soon since my passive one is pretty MN700/WRT54G specific due to the header and pinout of the device. I've come across some post somewhere ( I will edit this post once I find the reference) where the guy added some schmitt trigger buffers for noise before the the 74HC buffer because he claimed there was tons of noise spikes messing with the input of the buffers and he claimed everythign was hunky dory once he added the schmitt triggers. I did "purchase" a bufferd jtag from ebay, but the thing was so shoddily put together that I am afraid of buring up my parrallel port although the builder did take the effort of removing the flux from the solder connections; that design incorporated two SIP style resistors devices and a quad buffer chip but everything was sloppily put together....


EDITED FOR LINK TO JTAG CABLE DISCUSSION
http://neil.franklin.ch/Usenet/comp...._cable_problem


Here is the link where people discussed cable length., schmitt triggers etc.

[ericj]

Electrolytic Cap
Yeah, I noticed that my electrolytic cap was bulging just a tad. I guess even Microsoft was inflicted by the bad cap disaster that started in Taiwan. (See www.badcaps.net for pictures, story etc.) I plan on replacing it once I get a large enough order for Mouser.

Yeah, I'm not sure how much of this is really the bad electrolyte issue.

Electrolytic caps have come a very long way in the last 15 years, and the new electrolyte chemistries may have specific implementation consdierations that are not well understood by the people who use them. Some capacitor manufacturers have insisted that failed caps in the field are the result of inappropriate implementation.

Higher voltage caps can sometimes be more durable. It might be reasonable to get something like a 25v version of that Nichicon UPW and lay it on it's side on the board (it'll be too tall to stand up in the case). Theoretically, the 6.3v cap should be fine since it's only 'seeing' 3.3 volts. Be certain you get the high temperature (105c) version, whatever cap you get.

Also, switching power supplies have gotten much, much faster. It's not uncommon to see switchers running at mhz speeds, and that's certainly going to put a different kind of strain on the cap.

Jtag Cable
Can you please post your schematic for the buffered jtag? I've seen a couple on the 'net and I would just like to compare for reference. The one's I have seen make a big stink about the use of a 74HCT for TTL levels from the parrallel port. I plan I building a universal buffered jtag pretty soon since my passive one is pretty MN700/WRT54G specific due to the header and pinout of the device. I've come across some post somewhere ( I will edit this post once I find the reference) where the guy added some schmitt trigger buffers for noise before the the 74HC buffer because he claimed there was tons of noise spikes messing with the input of the buffers and he claimed everythign was hunky dory once he added the schmitt triggers. I did "purchase" a bufferd jtag from ebay, but the thing was so shoddily put together that I am afraid of buring up my parrallel port although the builder did take the effort of removing the flux from the solder connections; that design incorporated two SIP style resistors devices and a quad buffer chip but everything was sloppily put together....

From your description, the schematic i have is identical to what you bought on ebay.

He probably followed the instructions to the letter, which results in a chip with two resistor networks soldered directly to the legs on one side, another on the other side, and two loose 100ohm resistors as well.

These cables are designed for use on STMicro (*cough*) systems.

It may look like hell, but it probably works just fine as long as he doesn't have wires shorting out or something.

It may be preferable to use HCT chips, or, heck, use the AHCT just to spend a few more cents. I built one with a Motorola 74ls244 that worked just as well as a later one i built with a Ti 74hct244. I never had a corrupt bit written with either one of them - keep in mind that i was always careful to trap the bootloader before programming. I've also used them on StrongARM based systems.

An increasing number of parallel ports signal at 3.3 volts. This doesn't seem to cause problems with printers, but makes some passive parallel port interfaces more problematic than they were on older parallel ports. In this case, the HCT version of the chip doesn't necessarily get you anything. The jtag port for sure is 3.3 volt, but parallel ports vary, so anybody screaming that i NEED the ttl version just isn't paying attention.

fwiw, the low-power schottky (LS) version of the chip actually switches faster than the HC and HCT versions, but the HC(T) are a tiny bit faster to notice that they're being signalled. The AHC(T) versions are an attempt to make the cmos chips as fast as the schottky chips. The HC versions were a failed attempt at making cmos chips as fast as schottky chips.

Inspite of having two of those things, I haven't used them in a while and couldn't find them, so i went with 4 resistors this time around, and i had to write twice before it read back properly.

However, the jtag side of the cable itself has two considerations that people always seem to ignore.

1: keep its short. Like 8 inches. If you want it to be further from your computer than that, feel free to buy a 6 foot IEEE1284 (high speed parallel) rated db25 cable. That's what i used. The distance between buffer and jtag interface should be short.

2: You really should use ribbon cable, and every other line really should be grounded, at both ends. Those ground pins are there for a reason.

However, different jtag programs twiddle different bits on the parallel port. The document i have may need to be interpreted vs. what the de-brick utility expects.

Gimme a few days and I'll look it over. I don't think it needs to be any more complex than it already is, with regard to the schmidt triggers.

[edfcmc]

THanks Oleg:
Here are a couple of pointers:

1. There is a "step by step" in this thread on page 6.
2. If you can't get nvserial to work, you need to PM OLEG for the CFE.BIN as stated on page 6 of this thread.
3.Keep your passive jtag cable short.
4. If you gotta use windows (like i did), you can use the wrtjtag-modified program that is linked in this thread. (You use this program with your jtag cable to backup cfe.bin and flash the modified cfe.bin). THis program also allows you to erase the nvram.
5. When disasemling the router, you need to remove the clear plastic cover from the front LED's to crack it open after you have unscrewed the four holding screws.

MN700 linux hack is on two other sites (Liamm and techimo--so google it) but this thread is has all the info that you need.

[jochen]

I haven't grokked what incantation i need to use to turn on the power LED when it's finished booting, but I'll figure it out. I'm aware of the gpio stuff that needs to be done, but my shell scripting mojo is very rusty.

This isn't hard either. There is a gpio tool at http://downloads.openwrt.org/utils/ or a precompiled package at http://www.ethernal.org/openwrt/ wich can be installed using ipkg. Then you can control the power LED with is connected to GPIO 6:

gpio disable 6
gpio enable 6

[ericj]

Ah, thanks for the link. I figured it would make sense for such an app to exist, but was not aware that it did.

[Soler]

Noticed some new attempts at this mod... For the new guys, have you experienced any wireless signal issues? See my post a bit further up on this page.

What firmware are you guys running? OpenWRT? I may give it another shot since RC5 is out. I had White Russian RC4 running on it and it was unstable. Ran fine for a while but then would stop running during the night. Sometimes had to reboot a few times before it was back.

I've since reverted back to the MS firmware but may give it another shot.

[ericj]

RC5 isn't out. I'm using RC4. You can get pre-RC5 images, though, and i plan to try one.

RC4 is guaranteed to have some stability issues if you don't install kmod-b44 and stop using the et driver. You will have to ssh in and edit a file to do this. It's not required in pre-RC5 images.

I don't use my wireless heavily and haven't touched the mn700 in a few days, but it's been up. I'll see if it's still up and running well tonight.

I am using RC4 and have not had major problems. The switch ports don't work but this could be a configuration issue. Or a driver issue which would be probably resolved by RC5.

It doesn't always reboot, like you said. It's possible that boot_wait should be set to 'off' in the nvram. The wrt54g hardware list states that some boxes should have it turned on and some should have it turned off, and lists "n/a" for the mn700. Doesn't make sense. In any case, it's only there to give you a chance to tftp an image before it boots, and you can always tftp a new image by holding down that button during power-on.

I'll disable boot-wait and see if it reboots more happily tonight, after i see if the wireless is still running reasonably well after ~3 days uptime.

So far openwrt whiterussian rc4 is much, much, much more stable than the modified asus firmware. What was infuriating about the asus firmware was the way that i could only get into the admin interface maybe once out of every 10 times i rebooted it but it always worked as an access point anyway, so it had obviously booted in some sense.

[Soler]

Ericj,

I'd be interested if your wireless is still working. Interestingly, I never had any issues getting into the Admin screens while using the custom asus firmware. It was only wireless signal issues, everything else was solid.

What do you mean, "the switch ports don't work with RC4"? I did have to manually set the interfaces initially but did have wired connections working well.

[ericj]

Maybe the switch ports work just fine and i just need to remap the ports. Troubling that there's no vlan0 device, though.

Wireless is working fine. Pulled a cd image off my NFS server at a measured rate of about 24mbps, and some of the wired ethernet between the AP and the nfs server is pretty questionable so i think this is entirely reasonable.

I'm not set up to do raw network socket performance tests right at the moment, but i really don't think it's necessary to go that far.

While it was transfering, it the link fell back to 34mbps a few times but never stopped plugging away and kept retraining back up to 54mbps.

I forgot that i'd rebooted it (soft) a few days ago - uptime is 2 days and 9 hours.