Hello all;

I picked up a Netgear WNR1000v2 VC router at a garage sale recently ($5!) and I've been hacking at it.

The WNR1000v2 contains, according to https://wikidevi.com/wiki/Netgear_WNR1000v2

* Atheros AR7240 CPU (300MHz)
* 4MB Flash
* 32MB RAM (Woooh! I thought it'd only had 16MB at first)
* U-Boot accessible by serial console
* Atheros AR9285 B/G/N wifi chip with one connector
* AR7240 Ethernet Switch
* Runs a heavily modified OpenWRT 7.09 Kamikaze stock.

I've used these forum posts as a starting point:
https://forum.openwrt.org/viewtopic.php?id=18279
https://forum.openwrt.org/viewtopic.php?id=23387

So far, I've managed to compile OpenWRT Backfire and Attitude Adjustment ar71xx ramdisk images and, with a serial cable, have successfully booted into them. I did have to modify the magic number of the image to allow the modified u-Boot bootloader to boot it. I used the utility here http://aorlinsk2.free.fr/openwrt/wndr3700/ but modified to use the magic number 0x31303030 (ASCII 1000 in hex) instead of ASCII 3700.

However, once the router boots, I have no network interfaces in either Backfire or Attitude Adjustment.  For giggles, I tried appending board=WNR2000 to the bootargs, but that resulted in a freeze in Backfire and a kernel panic in Attitude Adjustment. There appears to be some board-specific initialization that needs to happen  to enable the network devices, and I'm not sure where to go from here.

mach-wnr2000.c (in arch/mips/ath79) looks interesting. What would I have to do to use this file as a base for the WNR1000v2?

Some other information:

In OpenWRT, I probed for GPIOs and came up with the following information:

There are 18 GPIOs registered.
The following GPIOs control LEDS:

0    WAN amber    active low
1    power amber    active low
11    power green    active low
12    LAN4 amber    active low

The rest of the GPIOs are unknown:

2    (value always 1)
3    (value always 0)
4    (value always 0)
5    (value always 0)
6    (value always 0)
7    (value always 0)
8    (value always 0)
9    (value always 1)
10    (value always 1)
13    (value always 0)
14    (value always 0)
15    (value always 0)
16    (value always 0)
17    (value always 0)

Given that there are three GPIOs with values stuck at 1 and three buttons, I'm assuming that three of these are, in fact, tied to the buttons. However, I couldn't get them to react when pressing the buttons while echoing the value in a shell loop. I also don't know what the GPIOs are for the wireless LED and the WPS LED, or for WAN green and the rest of the LAN LEDs.

I have not touched flash memory at all, although the flash layout is somewhat peculiar:

dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00350000 00010000 "rootfs"
mtd3: 00010000 00010000 "config"
mtd4: 00020000 00010000 "language_table"
mtd5: 00010000 00010000 "pot"
mtd6: 00010000 00010000 "traffic_meter"
mtd7: 00010000 00010000 "ART"
mtd8: 0034ffc0 00010000 "mount_fs"

The kernel and rootfs are lumped together in the same partition. It is booted by loading the file from the partition via the fsload command (which means that Netgear's U-Boot knows how to grok the filesystem?) and booting from that location in memory.

So, I'd appreciate a nudge in the right direction:

1) What do I need to do to start working on board-specific code for this device based off of the WNR2000's board file? Will creating another .c file and adding it to the Makefile be sufficient?

2) How can I track down the correct GPIOs for the missing buttons and LEDs?

For debug information, here's the boot log from the serial console:
http://jacksontech.net/wnr1000v2/serial_log_aa.txt (Attitude Adjustment)
http://jacksontech.net/wnr1000v2/serial_log_stock.txt (Stock firmware)

Note that the AA boot log is much shorter; it doesn't even try to init the network devices.

Edit: Fixed router name. WNR, not WRN. Gah!

(Last edited by supertanker on 8 Jul 2014, 02:11)

I thought I'd make an update, since I have successfully put OpenWRT onto this device.

The WNR1000v2 is similar enough to the WNR2000v3 to where the board init code can be used. Since I really wanted to get this working, I did nasty hacky things; I commented out all of the GPIO code in mach-wnr2000v3.c and changed the WNR2000v3's magic number in not one but two files; replacing 0x32303033 (2003) with 0x31303030 (1000) to keep the WNR1000v2's bootloader happy and (I think) to keep the kernel happy as well when it tries finding the rootfs. I spent most of the time trying to get the device to find the rootfs; it seemed to magically work when I found and replaced the second magic number...or maybe that was from removing GPIO LED support, which I disabled in the kernel build options after reading a bug report that claimed that the GPIO could interfere with reading from the flash chip. Sadly, I can't find that bug report now. This may or may not have made the device suddenly find its rootfs because I made this change at the same time I changed the magic numbers.

I compiled the "WNR2000v3" subtarget and flashed the image using the u-boot console, loading the image via TFTP. Bam.

Observations: the device works very well. I have it set up in client (routed) mode. Using 40MHz channels, in an area with little wireless interference, I can send TO the host behind the router at about 5.5-6.5MB/s from a TP-Link WR1043ND running stock firmware. I can send FROM the host behind the router to a machine on the main LAN at 9-10MB/s. I'm not sure how to account for the speed difference. It may be that the TP-Link, with its 3 antennas, is better at receiving than the single antenna WNR1000v2. It could also be that the TP-Link has lousy txpower (I haven't done much surveying to find out), or a wireless-G router near the TP-Link is interfering with things. Either way, even 5.5MB/s is a massive improvement from the 2MB/s I had with the previous wireless bridge between two wireless-G routers.

Obviously, with no GPIO init code and no GPIO LED support, the LEDs are wonky. The LAN switch controls its own port LEDs and the blue wifi LED works, but the green WPS LED and the power light do not; the WPS LED does not enable at all (then again, I don't use WPS...) and the power light stays amber instead of switching to green after boot. The buttons do not work either, but who needs buttons, right?

If anyone wants to formally add support for this old router, use the WNR2000v3 code as a base. The router works very well with OpenWRT.

If you have one of these, try putting OpenWRT on it before you bin it. The stock firmware is so, so bad. The "Advanced" Wireless Settings page won't work in Firefox; it only seems to work in IE because of some strange JavaScript specific thing they did. I had to use IE11 to disable WPS!

Footnote: There are two versions of the WNR1000v2; Netgear's stock version and a Comcast version, which has "VC" at the end of its model number. Comcast apparently gave out a bunch of these routers with their Internet service awhile back. The Comcast branded version appears to have identical hardware to the stock version and the firmware appears to be identical (in functionality and appearance) as well, although you can only flash Comcast firmware onto a WNR1000v2 VC, not stock firmware. (This limitation appears to be enforced by the web UI, not the bootloader). My router is a WNR1000v2 VC, but I suspect the above works with the stock WNR1000v2 as well.

Thanks to fuhry's work on the WNR2000; it inspired me to get a serial cable and start hacking on this device.

(Last edited by supertanker on 29 Jul 2014, 23:26)

Would you be able to provide this image of yours? I also have the same model and would love to use openwrt on that. I understand that only I am responsible for putting openwrt on my router and it "may" turn into a brick.
TIA

I (unknowingly) replicated some of the supertanker's work. However, I've a WNR1000v2 and the magic number is 0x31303031 which I found by comparing known magic numbers against factory firmwares, and then looking into the WNR1000v2 factory firmware and the 1.0.0.5 GPL firmware which I built from the sources which were made available by Netgear.

I've a working build and I also made a patch against the Barrier Breaker tree. I didn't have to solder an UART header onto the board as most of the information is already available from various sources. In fact, all that I needed was the pesky magic number.

I used the WNR612v2 as template, since on WikiDevi it is stated that it has identical hardware as WNR1000v2, but WNR612v2 has only two LAN ports. I used that board as template for adding WNR1000v2 support. It worked on the first try, but the power LED was in the wrong state.

It has four states (off, amber, green, amber+green) and it is controlled via GPIO 1 and 11 as supertanker mentioned. It was booting in amber+green, when it should have been green. Flashing the latest factory firmware (1.1.2.58) before flashing OpenWrt fixed this issue.

The only things that don't work are the WPS and rfkill buttons. It is a non-issue for me.

I made available all the information in a gist, including the images if you don't have the patience for building your own: https://gist.github.com/SaltwaterC/ef49c8a4df81c8896153

Thank you very much to SaltwaterC.  I was able to get my old wnr1000v2-VC (free Comcast model) loaded with Openwrt.  I tried your pre-builds but it would not take them.  A little digging around showed me that the VC model had a different 'Magic Number', 1001 for the stock unit and 1000 for the VC model.  I downloaded the source and the very simple to follow instructions from SaltwaterC's site.  Changed the two Magic Number entries in his patch file (before applying it) and did a make.  A hour or so later I was able to tftp openwrt onto my router.

To save anyone else the trouble (actually is was kind of fun) of building a VC version I have placed my files on my site.

https://sites.google.com/site/dorkdogpr … e-examples

Grab the wnr1000v2-VC.zip

Thanks again

You're welcome. I think that with the help of a hex editor you can even flash a 612v2 firmware on any of these, but the device name would be wrong on the status page. Your work confirms supertanker's findings, that 1000v2-VC has a different magic number. I'll update the patches with both versions, getting Chaos Calmer to match properly in the process as the patch was made from the Barrier Breaker patch.

I am curious about 1000v2h2 though. It looks to be the same as 1000v2, but it has two internal antennas instead of that external antenna that 1000v2 has. I couldn't find a different support page on Netgear's website, hence I assume that it uses the same firmware files. If somebody has this model, it would be helpful to give it a try.

FYI, this is the ticket on the issue tracker: https://dev.openwrt.org/ticket/18633

Edit:

I need to amend my previous statement. You don't have to solder an UART header as it's already there. I didn't have to use it, but I opened the unit to see if there's room for improvement.

(Last edited by SaltwaterC on 22 Jan 2015, 16:35)

How do you get to be able to TFTP to these? I tried to unlock the telnet interface on the WN604 (same hardware apparently) but was unable to do so.

You have to place it in failsafe mode. Explained in the gist which I posted above: https://gist.github.com/SaltwaterC/ef49 … 53#install

Thanks!

BTW, WN604 looks like it uses different kind of firmware. I see that the official firmware is packaged as a tar which contains a kernel file and a rootfs file (squashfs), with some md5 checksums. Even though the hardware is the same, I think the flashing procedure is different.

Interesting, thanks. Presumable the TFTP method of booting would though work?

@J1mbo: don't know. I don't have access to an unit and it retails for an obscene price (aka it costs pretty much the same as my TL-WR1043ND V2).

@WNR1000v2-VC owners: I've upgraded the patch and created new builds, including builds for WNR1000v2-VC against the latest Barrier Breaker branch. Can someone please test them? The magic number is correct for each model. I want to update the ticket on the issue tracker and this would be helpful. In the mean time, I'll update the Chaos Calmer patch as it fails to merge cleanly against the latest trunk.

Here's what's returned with the latest builds:

(Last edited by SaltwaterC on 23 Jan 2015, 16:12)

I tried both of the new builds for the VC model (bin & img) and I'm sorry I could not get them to work.  Since I had a modified build of your wnr1000v2 I first tried the sysupgrade.bin.  It seemed to load OK from the web page, the power led went black for 30 or so seconds then came back on for a few seconds and then went black again.  I could not ping the router.  I next tried tftp and the factory.img file.  It responded the same way as the sysupgrade.

I reinstalled the img file I had made and the router came back to life... perhaps something failing in the boot sequence??

I have never seen a v2h2 model of the wnr1000 but I did find a third magic number in the last netgear open source files.  There are listed as wnr1000v2 - 0x31030331, wnr1000v2-VC - 0x31030330 and wnr1000v2-VM - 0x31303032 (whatever that one is).

I also tried rebuilding the firmware from your new code and patches, there is no target for making the wnr1000v2-VC, should it build with the wnr1000v2?

I look forward to trying a trunk build.

Thanks for all your work on this router.

Based on what's happening for WNR612v2 / N150R (same devices), I tried to use another profile instead of another target, but I didn't call the multi profile. I was wrong about two things:

1. It doesn't work without call MultiProfile. I though it would.
2. It doesn't work with images built for other devices, even though it's the same hardware and the built images are almost the same. Checked them by doing a diff on the hex dump. I hex edited my images, and yours, and it wouldn't flash on WNR1000v2, even though the magic number is changed to the correct value. I could try using a sysupgrade image with changed magic number and see what fails by attaching a serial console just to have all the information. The sysupgrade is written, but it boots in failsafe mode.

The part from 1 can be fixed easily as, again, I'm using WNR612v2 as template. Thanks for the help. I'll try with a new set of images after fixing the "call MultiProfile" mess which I did. For the moment, I'm taking down the -vc images.

BTW, this is WNR1000v2h2. It has two internal antennas instead of one U.FL connector, which makes me think of the possibility of adding a secondary antenna.

I updated the patch and rebuilt the BB images (r44095). dsfraser, can you give them another try, please? This time I used the MultiProfile. The WNR1000v2 images (factory & sysupgrade) work on my device. Hopefully, the WNR1000v2-VC images work as well.

Sorry for the double post, but the forum doesn't provide any PM support.

I'm glad to report that both the new builds of the Sysupgrade bin and Factory imb files install and work on the VC model.

After looking at the pictures of the wnr1000v2h2 board in the link you sent, I decided to open mine up.  The board looks almost exactly the same.  There are pads for more then one antenna lead and it appears it would be very easy to add one.

Thank-you

Update on the WN604 - the TFTP server failsafe mode works OK.

• openwrt-ar71xx-generic-wnr1000v2-squashfs-factory-barrier-breaker-r44095.img - image accepted, device restarts but only into failsafe mode

• openwrt-ar71xx-generic-wnr1000v2-vc-squashfs-factory-barrier-breaker-r44095.img - image not accepted; device doesn't restart and just flashes green immediately.

Any ideas would be greatly appreciated. The factory firmware file is a tar containing:

• kernel.md5 (36 bytes)

• rootfs.squashfs (2,625,536 bytes)

• root_fs.md5 (36 bytes)

• vmlinux.lzma.uImage (655,424 bytes)

However, sending that via TFTP isn't accepted (it transfers so much, then times-out). I'm not bothered about getting back to the factory firmware but thought it might help work out what is going on.

(Last edited by J1mbo on 25 Jan 2015, 09:36)

Re WN604; here is the serial port output:

U-Boot 1.1.4-g12193fce-dirty (Dec 14 2009 - 13:39:19)

WN604 (ar7240) U-boot dni7 V0.8
...
## Booting image at 9f050000 ...
   Image Name:   MIPS OpenWrt Linux-3.10.49
   Created:      2015-01-24  22:37:25 UTC
   Image Type:   MIPS Linux Unknown Image (uncompressed)
   Data Size:    1123328 Bytes =  1.1 MB
   Load Address: bf070000
   Entry Point:  bf070000
   Verifying Checksum ... OK
Wrong Image Type for bootm command
Trying eth1
eth1 link down
FAIL
Trying eth0
eth0 link down
FAIL

The Router is in TFTP Server Firmware Recovery mode NOW!
Listening on Port : 69, IP Address: 192.168.1.1...

Here is the boot from the factory firmware:

## Booting image at 9f050000 ...
   Image Name:   Linux Kernel
   Created:      2012-02-16  11:08:50 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    655360 Bytes = 640 kB
   Load Address: 80002000
   Entry Point:  801b8000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 801b8000) ...
## Giving linux memsize in bytes, 33554432

Starting kernel ...

Booting AR7240(Python)...
Linux version 2.6.15--LSDK-7.3.0.387-WN604_V3.0.2 (root@build) (gcc version 3.4.4) #199 Thu Feb 16 16:35:45 IST 2012
flash_size passed from bootloader = 4

So the issue is the 'Wrong Image Type for bootm command'. Here is the bdinfo:

ar7240> bdinfo
boot_params = 0x81F67FA4
memstart    = 0x80000000
memsize     = 0x02000000
flashstart  = 0x9F000000
flashsize   = 0x00400000
flashoffset = 0x0003BE38

And, printenv:

ar7240> printenv
bootdelay=4
baudrate=115200
ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee
filesize=a0040
fileaddr=80800000
memtmp_addr=0x80800000
download=tftp
serverip=192.168.1.12 [your tftpservers IP]
ipaddr=192.168.1.11 [ Ip of the board]
uboot_size=+0x40000
uboot_addr=0x9f000000
erase_uimage=erase ${uboot_addr} ${uboot_size}
uimage=${download} ${memtmp_addr} u-boot.bin;run erase_uimage;cp.b ${memtmp_addr} ${uboot_addr} ${filesize}
kimagename=vmlinux.lzma.uImage
kernel_addr=0x9f050000
kernel_size=+0xB0000
erase_kimage=erase ${kernel_addr} ${kernel_size}
kimage=${download} ${memtmp_addr} ${kimagename};run erase_kimage;cp.b ${memtmp_addr} ${kernel_addr} ${filesize}
rimagename=rootfs.squashfs
rootfs_addr=0x9f100000
rootfs_size=+0x290000
erase_rimage=erase ${rootfs_addr} ${rootfs_size}
rimage=${download} ${memtmp_addr}  ${rimagename};run erase_rimage;cp.b ${memtmp_addr} ${rootfs_addr} ${filesize}
clear_var=era 0x9f390000 +0x50000
bootargs=console=ttyS0,115200 rootfstype=squashfs root=31:03 init=/sbin/init mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),704k(kernel),2624k(rootfs),320k(var),64k(manufacturing-data),64k(ART)
flash_rootfs=run rimage
flash_kernel=run kimage
flash_all=run flash_kernel flash_rootfs clear_var
bootcmd=bootm 0x9f050000
stdin=serial
stdout=serial
stderr=serial
ethact=eth1

Environment size: 1293/65532 bytes
ar7240> printenv
Unknown command 'printenv' - try 'help'
ar7240> printenv
bootdelay=4
baudrate=115200
ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee
filesize=a0040
fileaddr=80800000
memtmp_addr=0x80800000
download=tftp
serverip=192.168.1.12 [your tftpservers IP]
ipaddr=192.168.1.11 [ Ip of the board]
uboot_size=+0x40000
uboot_addr=0x9f000000
erase_uimage=erase ${uboot_addr} ${uboot_size}
uimage=${download} ${memtmp_addr} u-boot.bin;run erase_uimage;cp.b ${memtmp_addr} ${uboot_addr} ${filesize}
kimagename=vmlinux.lzma.uImage
kernel_addr=0x9f050000
kernel_size=+0xB0000
erase_kimage=erase ${kernel_addr} ${kernel_size}
kimage=${download} ${memtmp_addr} ${kimagename};run erase_kimage;cp.b ${memtmp_addr} ${kernel_addr} ${filesize}
rimagename=rootfs.squashfs
rootfs_addr=0x9f100000
rootfs_size=+0x290000
erase_rimage=erase ${rootfs_addr} ${rootfs_size}
rimage=${download} ${memtmp_addr}  ${rimagename};run erase_rimage;cp.b ${memtmp_addr} ${rootfs_addr} ${filesize}
clear_var=era 0x9f390000 +0x50000
bootargs=console=ttyS0,115200 rootfstype=squashfs root=31:03 init=/sbin/init mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),704k(kernel),2624k(rootfs),320k(var),64k(manufacturing-data),64k(ART)
flash_rootfs=run rimage
flash_kernel=run kimage
flash_all=run flash_kernel flash_rootfs clear_var
bootcmd=bootm 0x9f050000
stdin=serial
stdout=serial
stderr=serial
ethact=eth1

Environment size: 1293/65532 bytes

Any ideas?

(Last edited by J1mbo on 26 Jan 2015, 22:57)

@dsfraser: thank you for testing the images. I completed the work on the CC patch as well, but I need to see why I can't get proper images from the build (aka it doesn't apply the appropriate driver profile and the device won't boot properly). Unlike the release, the trunk is a little bit fussy about the config and it fails in weird ways. I should start from scratch as incremental builds may be the issue. In the mean time, also figured out how to send patches. We're getting there.

@J1mbo: I think that probably we should discuss this into another thread, dedicated to WN604.

To answer your question, my educated guess is that you should place your firmware files (vmlinux.lzma.uImage and rootfs.squashfs) on the root directory of a tftp server running on your computer. From the printenv output, I see that, for example, rimage roughly translates to these steps, which are common for flashing via tftp and attached serial console:

I say roughly because it states ${filesize}, but it should match the ${rootfs_size} value from the erase command, therefore it may be recommended to use the above commands instead of running rimage. The same idea may be applied for flashing the kernel image, but you would need to use:

After that, you may boot the kernel with bootm by passing the kernel address to it (0x9f050000).

Please triple check everything that I've just said before typing anything in the u-boot console. I may be wrong about, well, everything.

And whatever you do, stay away from uimage and anything related. If you mess the bootloader, you're going to be in a world of trouble (read #3).

As a separate note, my calculations say that the kernel and the rootfs are next to each other: 0x9f050000 + 0xB0000 = 0x9f100000. I guess this information could be used for eventually flashing a potential OpenWrt build in one go instead of having separated files for kernel and squashfs.

(Last edited by SaltwaterC on 27 Jan 2015, 01:11)

Thank you so much for the help - and, I will move the content now.

Could you post printenv output from the WNR1000v2?

@J1mbo: quite short ...

ar7240> printenv
bootdelay=4
baudrate=115200
ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee
serverip=192.168.1.101
ipaddr=192.168.1.1
bootcmd=fsload 80800000 image/uImage;bootm 80800000
bootargs=console=ttyS0,115200 root=31:08 rootfstype=squashfs init=/etc/preinit mtdparts=ar7240-nor0:256k(u-boot),64k(u-boot-env),3392k(rootfs),64k(config),128k(language_table),64k(pot),64k(traffic_meter),64k(ART),3473344@327744(mount_fs)
stdin=serial
stdout=serial
stderr=serial
ethact=eth1

Environment size: 451/65532 bytes

@dsfraser: I completed the work on Chaos Calmer and successfully flashed my device with it. However, it required a power cycle after flashing the factory image via tftp.

It booted into failsafe after the flash ("Bad magic number" error shown in serial console), but the failsafe mode after the flash was unusable as it denied flash write access. After a power cycle, it booted Chaos Calmer without any fuss.

I don't see why it shouldn't work for WNR1000v2-VC as the patch itself is just the Barrier Breaker patch changed to match the CC offsets and kernel version, but it would be helpful to have a confirmation before sending it to openwrt-devel. Also, if you don't mind, the patch may also be tagged with Tested-by, but I need your name and email. While your name appears on the website you posted, I can only guess the rest. If you're OK with it, please drop me a line on Gmail (I've the same username as the one I'm using here). Thank you.

PS: the build issues were indeed due to having incremental builds, an issue I don't have with BB. Starting from scratch with a clean tree and a new config, I got the images from the first try.

BusyBox v1.22.1 (2015-01-27 04:58:41 EST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 CHAOS CALMER (Bleeding Edge, r44154)
 -----------------------------------------------------
  * 1 1/2 oz Gin            Shake with a glassful
  * 1/4 oz Triple Sec       of broken ice and pour
  * 3/4 oz Lime Juice       unstrained into a goblet.
  * 1 1/2 oz Orange Juice
  * 1 tsp. Grenadine Syrup
 -----------------------------------------------------
root@OpenWrt:/# uname -a
Linux OpenWrt 3.14.29 #1 Tue Jan 27 05:02:37 EST 2015 mips GNU/Linux
root@OpenWrt:/# cat /proc/cpuinfo
system type             : Atheros AR7240 rev 2
machine                 : NETGEAR WNR1000 V2
processor               : 0
cpu model               : MIPS 24Kc V7.4
BogoMIPS                : 226.09
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : mips16
shadow register sets    : 1
kscratch registers      : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

Now working on WN604 too - see this thread

Thank's SaltwaterC, using the info from you and Jimbo I've managed to get a stack of WN604's working perfectly. Much appreciated.

Any tips for getting around a tftp "transfer timeout" message when using the Mac OS X Terminal (10.9)?

I've followed Saltwater's instructions (https://gist.github.com/SaltwaterC/ef49c8a4df81c8896153) to the letter for flashing a 1000v2-vc but I can't upload the new .img to the router. It seems to boot into failsafe mode properly (ping is OK, green light flashing), but it won't accept a transfer.  I've configured the network on the Mac to a static IP (192.168.1.2) with the router as 192.168.1.1. Binary and trace enabled.

I'd love any help with this, thanks!