OpenWrt Forum Archive

Topic: WNR1000v2: some success! (need advice on board-specific init)

The content of this topic has been archived between 16 Apr 2018 and 18 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

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, 04: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 30 Jul 2014, 01: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 didn't have to solder an UART header onto the board

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, 17: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.

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:

~/P/openwrt-wnr1000v2 (master) head -c 192 openwrt-ar71xx-generic-wnr1000v2-squashfs-factory-barrier-breaker-r44065.img | xxd
0000000: 6465 7669 6365 3a57 4e52 3130 3030 5632  device:WNR1000V2
0000010: 0a76 6572 7369 6f6e 3a56 4f70 656e 5772  .version:VOpenWr
0000020: 742e 7234 3430 3635 0a72 6567 696f 6e3a  t.r44065.region:
0000030: 0a00 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000080: 3130 3031 a288 c4fa 54c2 53ff 0011 2400  1001....T.S...$.
0000090: bf07 0000 bf07 0000 07d5 6094 0505 0700  ..........`.....
00000a0: 4d49 5053 204f 7065 6e57 7274 204c 696e  MIPS OpenWrt Lin
00000b0: 7578 2d33 2e31 302e 3439 0000 0000 0000  ux-3.10.49......
~/P/openwrt-wnr1000v2 (master) head -c 192 openwrt-ar71xx-generic-wnr1000v2-vc-squashfs-factory-barrier-breaker-r44065.img | xxd
0000000: 6465 7669 6365 3a57 4e52 3130 3030 5632  device:WNR1000V2
0000010: 2d56 430a 7665 7273 696f 6e3a 564f 7065  -VC.version:VOpe
0000020: 6e57 7274 2e72 3434 3036 350a 7265 6769  nWrt.r44065.regi
0000030: 6f6e 3a0a 0000 0000 0000 0000 0000 0000  on:.............
0000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000080: 3130 3030 a6a0 e377 54c2 5402 0011 2400  1000...wT.T...$.
0000090: bf07 0000 bf07 0000 21a5 6e9d 0505 0700  ........!.n.....
00000a0: 4d49 5053 204f 7065 6e57 7274 204c 696e  MIPS OpenWrt Lin
00000b0: 7578 2d33 2e31 302e 3439 0000 0000 0000  ux-3.10.49......

(Last edited by SaltwaterC on 23 Jan 2015, 17: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, 10: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, 23: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:

tftp 0x80800000 rootfs.squashfs
erase 0x9f100000 +0x290000
cp.b 0x80800000 0x9f100000 0x290000

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:

tftp 0x80800000 vmlinux.lzma.uImage
erase 0x9f050000 +0xB0000
cp.b 0x80800000 0x9f050000 0xB0000

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, 02: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 smile

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!