OpenWrt Forum Archive

Topic: Netgear WNR2000v4

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

You should try to restore all the U-BOOT environment variables. Do that now. model them after mine.. You are advised to use specialized U-BOOT commands over setenv for certain things.. like progmac and snset rnset.. see that they update the env, if not, also add env..

See if that helps you. Make sure to save them with saveenv, then try to boot. Good luck

You removed some part of the raw binary image? That doesn't sound safe AT ALL. lol.. and yeah, I couldn't install LUCI without the USB mod, but I didn't try that hard too...

I just did an experiment.... I flashed the non_usb image to my router, removed /etc/config/wireless, and reflashed, and /etc/config/wireless reappears as expected.. So your setup is f**** up.

I have only been on the scene for 5 days now. I've never encountered the problems you have, I cannot help you.

O wait you have backup versions.. well they are useless unless you can write them back to memory.. This is normally done with mtd. problem is that you're going to need to get your OS booting or else you'll need JTAG. Does U-BOOT provide facilities to let you flash the other non-firmware backups? That could be another potential option.

You should also google your error message for other help.

This is a long shot but it might be possible to use tftpboot to send an image to RAM, and then cp memory copy command to write it to the portions of memory where your backups belong.. But I don't know if cp is capable of flashing...

(Last edited by bazz on 15 Apr 2015, 17:51)

This should help:

Linux Memory Map [FLASH]
To flash from U-Boot. Add 0x1e000000 to the addresses below.

0x000000000000-0x000000030000 : "u-boot"
0x000000030000-0x000000040000 : "u-boot-env"
0x000000040000-0x0000003f0000 : "firmware"
0x000000040000-0x000000155d7b : "kernel"
0x000000155d7b-0x0000003f0000 : "rootfs" <--- yours would be different.. I'm removing it from below
0x000000340000-0x0000003f0000 : "rootfs_data"
0x0000003f0000-0x000000400000 : "art"
root@OpenWrt:/sys/devices/virtual/gpio/gpio13# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 003b0000 00010000 "firmware"
mtd3: 00115d7b 00010000 "kernel"

mtd5: 000b0000 00010000 "rootfs_data"
mtd6: 00010000 00010000 "art"

U-BOOT Memory Map [FLASH]

0x1e000000-0x1e030000 : "u-boot"
0x1e030000-0x1e040000 : "u-boot-env"
0x1e040000-0x1e3f0000 : "firmware"
0x1e040000-0x1e155d7b : "kernel"

0x1e340000-0x1e3f0000 : "rootfs_data"
0x1e3f0000-0x1e400000 : "art"

Update #2
You can use 'bdinfo' to get the proper addresses to use!! in my case:

ar7240> bdinfo
boot_params = 0x81F77FB0
memstart    = 0x80000000
memsize     = 0x02000000
flashstart  = 0x9F000000
flashsize   = 0x00400000
flashoffset = 0x0002E310
ethaddr     = 00:AA:BB:CC:DD:EE
ip_addr     =
baudrate    = 115200 bps

Side-note: The ethaddr seems to be junk address// not sure what it's for..

So my map most trustworthy is :

0x9f000000-0x9f030000 : "u-boot"
0x9f030000-0x9f040000 : "u-boot-env"
0x9f040000-0x9f3f0000 : "firmware"
0x9f040000-0x9f155d7b : "kernel"
0x9f340000-0x9f3f0000 : "rootfs_data"
0x9f3f0000-0x9f400000 : "art"

Restore Art from U-Boot Tutorial

In your case, You should NOT restore U-Boot from U-Boot.. makes no sense.. You only need to restore U-Boot frpm JTAG if you can't even boot into U-BOOT. I think you'll back up and running shortly.

(Last edited by bazz on 17 Apr 2015, 05:43)


Thanks for your link! I have successfully recovered my ART as well as U-boot and U-boot-env, but my mac addr is still unrecognizable (Therefore the factory image cannot work and neither yours nor growell's image.).

Now I flashed factory img using a 3rd party u-boot (which made it possible to redefine the mac addr), this time it SEEMS to be working based on the output message from TTL except I cannot enter netgear's web administration page and neither wired nor wireless is working. (Only the OS is working and the hardware address is a mess in my guess.)

And your image and Growell's image are both acting as what they did yesterday. LED/LAN/WAN are working and wireless is missing.

It seems that the wireless "chip" (if there're one) is completely ignored during flashing thus its driver isn't installed at all.

Do you have any idea on how to recover it using JTAG? I have a mini-JTAG programmer and I've read the article about how to make JTAG available. What sort of software should I use and what image should I flash? My JTAG programmer is designed for Freescale MCU and will it work?

(Last edited by lcy92 on 16 Apr 2015, 06:22)

Let's try a RAM Disk image!! big_smile Then, when you are running the Ram disk image, Tell me, while OS is running, can you use the root shell from the serial? [by pressing enter when it tells you to] // It might be like me, I can't access terminal from serial due to garbage characters.. I'll link the RAMFS image with brief message at the bottom, but I ask you to read thru the rest of this message.

There is no wireless chip, everything is on one SoC. I guess it's possible that your memory could have become non-writable, but that sounds far-fetched...

Consider the possible importance of the 'protect' command in U-Boot...

I don't see how JTAG would help.. I mean you can already flash from U-Boot, what's the point..

Try using wmacset U-Boot command to set WLAN mac address..

A stock image should operate successfully.. Now would be a good time for you to try to assess what have you done in the first place to cause all of this?? You are the only user who has reported these issues. What did you do?

I think if you cannot get a stock firmware to work correctly that's bad, but we can try something for kicks. I can give you a RamFS image which you can use from U-Boot.. You are on a 3rd party U-Boot now.. but why?? I recommend you get back on stock U-Boot, try to make the system back to original form, not more modified..

I understand that your system is borked, but I don't know what to tell you, you're going to have to put a lot of effort into getting back online. Consider the possibility of flopping back and forth between stock / modified U-Boot's during this whole process..

Your network devices don't work for whatever reason, and you've seemed to narrow it down to the fact that your Mac address cannot be set.. but why can't it be set? Can we get an expert? I can't imagine what could have gone wrong that you can't re-instantiate a MAC address.. Are you stupid? We don't know.. big_smile just kidding.

Don't forget to saveenv

Anyways, try a RamFS image to help get you going. It can be uploaded at U-Boot stage without failing a checksum. You can use this image to hopefully gain shell access, and figure out what the heck is wrong. I really suggest you take a hard look at what the heck you did to blow up your router lol. Maybe then you'll know what to fix.. I also want you to confirm that you used the U-Boot command 'macset' to set the MAC address.. You might have to try a couple times to get this to work... For me it sometimes breaks, stopping at a message /dev/tty0 disabled, This image is probably fine it's probably one of my other images [been doing a lot of experimentation on the LEDs, and I have a breakthru too smile ]

Boot a Ram Disk Image

serial terminal.

On your Host PC, setup TFTPD and put my RAMFS image into the upload dir, usually /tftpboot. plug into router and set PC IP to, and check router serial environment UBOOT to make sure the serverip variable is also the same. in U-BOOT. Warning, I've only done this in Stock U-Boot, YMMV. Now, In U-Boot

tftpboot 81000000 openwrt-ar71xx-generic-wnr2000v4-initramfs-uImage.bin

Note: using 80060000 for the address will not work..

More info: … ain_memory And no, the img does not have to be modified in any way.

Warning -- All of the LEDS will be on ON all the time -- this image comes from LED experiment tongue

Booting from a RAM Disk is useful for 2 reasons only, IMHO.
1. It lets you quickly upload an test image, without flashing over regular firmware.
2. It can act as a quick intermediary step to flashing new firmware when you have stock firmware installed.. Because you can do it immediately at boot -- instead of having to use telnetenable and using the rather long tftp command to fetch the firmware from your TFTP server. With this method, you flash the ramdisk, and then when it boots you can telnet in with no problems.. To send a new firmware, you'll have to set a SSH passwd, and then SCP it to the router.. Install as before with MTD..

(Last edited by bazz on 16 Apr 2015, 21:50)


News: Everything get back to work after I followed your advice and manually set the mac address (Lan/Wan/WLAN) now WLan shares the same mac addr with wan, because I don't know exactly which mac is whose....I have no idea if it is correct...

My iPad now can connect the wLAN although the default ssid and key seems to be strange. I'll test it later.

Under Official U-boot and Official

I'll then test the RAMDISK image. Thanks a lot!!

Looks good. smile

I took a look at my own interfaces to see if I can help.
I have many more interfaces now, I'm on my dream setup.

root@OpenWrt:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr 28:C6:8E:26:DA:82  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::2ac6:8eff:fe26:da82/64 Scope:Link
          inet6 addr: fd99:7b39:4939::1/60 Scope:Global
          RX packets:7189 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7394 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1393451 (1.3 MiB)  TX bytes:2415699 (2.3 MiB)

eth0      Link encap:Ethernet  HWaddr 28:C6:8E:26:DA:83  
          inet addr:  Bcast:  Mask:
          inet6 addr: 2601:6:7100:b02f:2ac6:8eff:fe26:da83/64 Scope:Global
          inet6 addr: fe80::2ac6:8eff:fe26:da83/64 Scope:Link
          inet6 addr: 2601:6:7100:b02f::b976/128 Scope:Global
          RX packets:3767 errors:0 dropped:2 overruns:0 frame:0
          TX packets:3034 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1001419 (977.9 KiB)  TX bytes:820330 (801.1 KiB)

eth1      Link encap:Ethernet  HWaddr 28:C6:8E:26:DA:82  
          RX packets:7692 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7747 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1698905 (1.6 MiB)  TX bytes:2462757 (2.3 MiB)

eth1.1    Link encap:Ethernet  HWaddr 28:C6:8E:26:DA:82  
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:497 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:40743 (39.7 KiB)

eth1.2    Link encap:Ethernet  HWaddr 28:C6:8E:26:DA:82  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::2ac6:8eff:fe26:da82/64 Scope:Link
          RX packets:1410 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1156 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:290706 (283.8 KiB)  TX bytes:298778 (291.7 KiB)

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:339 errors:0 dropped:0 overruns:0 frame:0
          TX packets:339 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:36152 (35.3 KiB)  TX bytes:36152 (35.3 KiB)

wlan0     Link encap:Ethernet  HWaddr 28:C6:8E:26:DA:83  
          inet6 addr: fe80::2ac6:8eff:fe26:da83/64 Scope:Link
          RX packets:1150 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1762 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:147464 (144.0 KiB)  TX bytes:430399 (420.3 KiB)

Like you, my WLAN0 MAC matches the WAN Mac.. the Ethernet switch is WAN/WLAN - 1

(Last edited by bazz on 16 Apr 2015, 10:46)

Well, it seems to be unstable. After flashing the non-usb image (not using the ramdisk version, my network condition is terrible so I cannot access google services right now...), mac address got lost again...

At this point you should start posting detailed error messages you are receiving. Don't hold back. Without us seeing what you're doing, we can't tell why it's breaking. It's either going to be something we can fix, or something I don't even know how to fix lol. But by posting your error messages, you can let other people see it, and you can also google for the error messages see if someone solved the same problem.

Is it possible my image does not work with other people? I doubt it... but I dont know since I am n00b.

The more details you provide the better off you are to get help. Consider making a video. What you really want to do is ask yourself -- Can I reproduce the error myself?? If you can reproduce the error easily, you should make a video or make a detailed post with log messages or pictures. So that someone can see, and go "I know what's wrong" -- or once again, google for your error messages too..

BTW, it made sense that your default SSID and password were strange.. You must have lost it when you lost everything else.. But I don't know enough about how to ensure you've fully restored your memory properly. but it sounds like there's a portion of memory you may have not restored correctly.. Maybe if someone taught me how to make the fullest backup possible from my router, we could have you restore everything that way.. I'm not sure if that's a bad idea, because of data duplication on 2 routers.

(Last edited by bazz on 16 Apr 2015, 22:00)

Also, a good CONCEPTUAL link on how to properly flash contents from TFTP, specifically the code block showing to remove memory protection, erase the block, and flash it from RAM.. You should use 0x81000000 for the upload RAM address and wnr2000v4's flash memory map. … _for_Exeda

(Last edited by bazz on 16 Apr 2015, 22:23)

Green LEDs Status Update

As I had mentioned in my big post with the picture, there are issues in the current trunk firmware that causes lack of control of GREEN LEDs. I have figured out the solution. I'd like to encompass the solution not only, but also the experience I took to get there. I will be discussing the GPIO characteristics of the WNR2000v4 SoC - Atheros AR9341.

First, I had to find its datasheet. I admit it was initially hard. At first I could only find AR9331, but through perserverance I found it. here's a link: AR9341 Datasheet . Is it OK to share datasheet links? I can take it down if it's against legal good status.

I learned that the GPIO is not typical, but a MUX of signals can be specified to come out of the GPIO. Amongst the MUX signals are several LED signals for the 5 port Ethernet switch. These could show Link(always on), or activity, and other behavior on the LEDS. Respectively, 5 signals purposed for LEDs to reflect the ethernet switch activity. These signals are individually applied to GPIO slots.

The mach file for wnr2000v4 does not specify directly to use these signals on their GPIO lines.. And even if we take Green LEDS out of the led_gpio structure, they still work.. Thus, we make the following 2 possibilities:

1. The default setting of SoC uses these signals on Green Led GPIO..
2. Another file in OpenWrt is making the setting, even though we did not provide GPIO numbers. [unlikely, right?]

Take note that the datasheet specifies no default setting for our green LED GPIO numbers.

But we can view memory in U-BOOT to confirm the status of the GPIO... But since U-Boot is in a virtual memory environment (no?), I cannot guarantee I am looking at the physical memory -- so I did an experiment, and proved that I have access to the physical registers smile

U-Boot proof of physical access to hardware registers
When I enter U-Boot, I had the amber power light on, and some other ones. I made an experiment to test if I could see the proper values for GPIO enable, and see if I could set and clear the LED on/off. I can smile

0x18040000 is the start of the GPIO registers.. I insert coments in the U-Boot interaction below.

Hit any key to stop autoboot:  0 

# Inspect for proper GPIO enable
ar7240> md 0x18040000 4
18040000: 00000318 007cfa3d 007c1005 00000000    .....|.=.|......
ar7240> mm
mm      - memory modify (auto-incrementing)

# try to set amber LED (turn off)
ar7240> mm 0x1804000C
1804000c: 00000000 ? 2
18040010: 00000000 ? .
ar7240> md 0x18040008 1
18040008: 007c1007    .|..
# it works - My LED turned off, and the GPIO output value register (0x18040008) reflects the new value :)

# try clearing (turn on) green power LED
ar7240> mm 0x18040010
18040010: 00000000 ? 1
18040014: 00000000 ? .

# it works!
ar7240> md 0x18040008 1
18040008: 007c1006    .|..

Since we have proof now we can continue. I want to see the default GPIO function setting... Maybe it's either SoC default, or the bootloader specifies this value itself to the GPIO registers.. (doesn't know)..

Green LAN leds ascend from GPIO #13. We need to see the GPIO function register corresponding:
[8:31] of 0x18040038 -- GPIO_OUT_FUNCTION3

ar7240> md 0x18040038 2
18040038: 2b2a2900 00002d2c    +*)...-,

These values are actually Ethernet LINK values, so that the LED stays ON when the ethernet is plugged in... It's not the setting we are after.. We are after the Activity setting, which is later set... But who sets it!!?? The bootloader or the firmware.... Since answering that question becomes difficult for me, I elected not to find the answer, instead, in the wnr2000v4 mach file, I clear all LED GPIO OUT FUNC settings to 0, which is not a MUX value. I learned to do this from mach-wndr4300.c -- so I assume it's a safe way of specifying no signal to the GPIO. Then we can control the signal ourselves, like in uci and /etc/config/system!! More control to the user!! Yay!!

(Last edited by bazz on 17 Apr 2015, 01:09)

Trunk Buttons Issues

There are 2 problems concerning buttons that are in the current trunk. I fixed.

1. Buttons not listed as Active Low
This issue caused pressing the button to be registered as a button release, and vice versa.

2. WLAN button doesn't fire in hotplug.d
I was using the hotplug.d test for the button but it wouldn't register because KEY_WLAN is not registered with hotplug.d.. But the button may be otherwise working.. Nonetheless, I've moved the button to use KEY_RFKILL in order to gain the inherent rfkill script functionality to toggle WIFI. Better than having to write your own scripts. Now back to the outdated post...

This is a very similar issue to the GREEN LEDs issue I experienced. Let me tell you why.. With the green LED issue, I could view the change in GPIO value from 'cat /sys/kernel/debug/gpio' -- but could not set the values directly - even if the LED wasn't registered as led and thru the /sys/class/gpio subsystem.. This WLAN BUTTON acts the same way... you can watch the GPIO work by doing the following as you press and release it:

while true; do
cat /sys/kernel/debug/gpio
sleep 1

The problem with the LED (and might be related to this button),  was that the GPIO had a MUX signal set to pass thru it. This took priority over gpio set/clear operations, apparently.

So I wondered to myself, maybe there is an Input "signal" set on this WLAN button.. and it seemed that was true, get ready for example.

The GPIO for WLAN_BUTTON is 11

# We must look at 0x18040044 - 0x18040054 : 5 
ar7240> md 0x18040044 5
18040044: 00000908 00000000 00000000 00000c0b    ................
18040054: 00000000    ....

It turns out the problem has nothing to do with the GPIO.. but the button's code member in the struct. There is no KEY_WLAN as written.. I've figured out we want KEY_RFKILL -- this will use /etc/rc.button/rfkill switch to automatically toggle wireless ON/OFF. And it will also register the key press in hotplug, incase we are using it to test smile

(Last edited by bazz on 17 Apr 2015, 02:26)

Summary of my Uncommited Improvements

Based on latest snapshot [as of yesterday at least]..
Be sure to see my Questions/Concerns at the end of posting.

Fixed Amber LEDS
they were previously ALL mismatched. ie LAN4 LED would light on when LAN1 was connected.

Fixed All button's inverse logic
originally, pressing a button would trigger a release state, and releasing would trigger a press. (Can be observed from hotplug.d)

Made Green LEDS configurable
previously they were hard-preset by unknown source to only reflect Ethernet activity. This Openwrt forum posting details everything. Now they are last-configured in the mach file to be configured like the other LEDS, under /etc/config/system. This provides more flexible LEDs.

WAN Led was tracking the wrong ethernet interface
It was tracking eth1 (ethernet switch). Needs to track eth0 (WAN).

Enabled WLAN Button as RFKILL  
now the button actually does its job in fresh firmware because it now references /etc/rc.button/rfkill which toggles the wifi, and it registers with hotplug.d incase a n00b is using it like me, and it wouldn't register before because KEY_WLAN is not part of hotplug button definitions, and its name was not rfkill (in order to reference /etc/rc.button/rfkill script).

Fixed Networking
Ethernet was broken for at least 3 users including me; [see … #p260861].
It works now because of Franz Flasch's wnr_common_setup() *thumbs up* -- I literally used the one from his original patch file, linked in Growell's tutorial in this thread Page1.

An expert should take a look at these 2 and determine why the first one works and the second doesn't.. However, the 2nd one may feature improvements that we should throw into the first (but properly so it works tongue)

Working (Franz's)
Note: I added in the USB registration... it works with or without a physical USB mod

static void __init wnr_common_setup(void)
 u8 *art = (u8 *) KSEG1ADDR(0x1fff0000);
 u8 *ee  = (u8 *) KSEG1ADDR(0x1fff1000);
 ath79_register_mdio(1, 0x0);
 // register USB early (I'm not sure if it matters), incase we are using CHROOT 


 ath79_init_mac(ath79_eth0_data.mac_addr, art+WNR2000V4_MAC0_OFFSET, 0);
 ath79_init_mac(ath79_eth1_data.mac_addr, art+WNR2000V4_MAC1_OFFSET, 0);

 /* GMAC0 is connected to the PHY0 of the internal switch, GE0 */
 ath79_switch_data.phy4_mii_en = 1;
 ath79_switch_data.phy_poll_mask = BIT(4);
 ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;
 ath79_eth0_data.phy_mask = BIT(4);
 ath79_eth0_data.mii_bus_dev = &;

 /* GMAC1 is connected to the internal switch, GE1 */
 ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;

 ath79_register_wmac(ee, art);

Non-working (bukington's??)

static void __init wnr_common_setup(void)
    u8 *art = (u8 *) KSEG1ADDR(0x1fff0000);
    u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);


    ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_ONLY_MODE |

    ath79_register_mdio(1, 0x0);

    /* LAN */
    ath79_init_mac(ath79_eth1_data.mac_addr, art+WNR2000V4_MAC0_OFFSET, 0);

    /* GMAC1 is connected to the internal switch */
    ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;

    /* WAN */
    ath79_init_mac(ath79_eth0_data.mac_addr, art+WNR2000V4_MAC1_OFFSET, 0);

    /* GMAC0 is connected to the PHY0 of the internal switch */
    ath79_switch_data.phy4_mii_en = 1;
    ath79_switch_data.phy_poll_mask = BIT(4);
    ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;
    ath79_eth0_data.phy_mask = BIT(4);
    ath79_eth0_data.mii_bus_dev = &;

    ath79_eth0_data.speed = SPEED_100;
    ath79_eth0_data.duplex = DUPLEX_FULL;


    /* WLAN */
    ath79_register_wmac(ee, art+WNR2000V4_MAC0_OFFSET);

    /* USB */


switch LED prefix from wnr2000-v4 to netgear
keep in sync with other BSPs

Questions / Concerns

Modules unselected in MenuConfig.. Somehow installed

root@OpenWrt:~# opkg list-installed | grep kmod
kmod-ath - 3.18.11+2015-03-09-3
kmod-ath9k - 3.18.11+2015-03-09-3
kmod-ath9k-common - 3.18.11+2015-03-09-3
kmod-cfg80211 - 3.18.11+2015-03-09-3
kmod-crypto-aes - 3.18.11-1
kmod-crypto-arc4 - 3.18.11-1
kmod-crypto-core - 3.18.11-1
kmod-crypto-hash - 3.18.11-1
kmod-fs-ext4 - 3.18.11-1
kmod-gpio-button-hotplug - 3.18.11-1
kmod-ip6tables - 3.18.11-1
kmod-ipt-conntrack - 3.18.11-1
kmod-ipt-core - 3.18.11-1
kmod-ipt-nat - 3.18.11-1
kmod-ipv6 - 3.18.11-1
kmod-ledtrig-usbdev - 3.18.11-1
kmod-lib-crc-ccitt - 3.18.11-1
kmod-lib-crc16 - 3.18.11-1
kmod-mac80211 - 3.18.11+2015-03-09-3
kmod-nf-conntrack - 3.18.11-1
kmod-nf-conntrack6 - 3.18.11-1
kmod-nf-ipt - 3.18.11-1
kmod-nf-ipt6 - 3.18.11-1
kmod-nf-nat - 3.18.11-1
kmod-nf-nathelper - 3.18.11-1
kmod-nls-base - 3.18.11-1
kmod-ppp - 3.18.11-1
kmod-pppoe - 3.18.11-1
kmod-pppox - 3.18.11-1
kmod-scsi-core - 3.18.11-1
kmod-slhc - 3.18.11-1
kmod-usb-core - 3.18.11-1
kmod-usb-ohci - 3.18.11-1
kmod-usb-storage - 3.18.11-1
kmod-usb2 - 3.18.11-1
root@OpenWrt:~# cat /sys/class/leds/netgear:amber:lan4/trigger
none [switch0] timer default-on netdev usbdev phy0rx phy0tx phy0assoc phy0radio phy0tpt 

Although I did not in menuconfig ask to compile the LED kernel modules such as netdev, I have the support. And it works. Why?
Is it because of Kconfig?

config ATH79_MACH_WNR2000_V4
    bool "NETGEAR WNR2000 V4"
    select SOC_AR934X
    select ATH79_DEV_ETH
    select ATH79_DEV_LEDS_GPIO
    select ATH79_DEV_M25P80
    select ATH79_DEV_USB
    select ATH79_DEV_WMAC

I add further note that I was screwing around with both menuconfig and kernel_menuconfig, at one point I specified in both menuconfig's to compile the LED modules, and that seemed to break stuff (sorry no error messages available) -- but at startup the log would say something like "kernel module already installed" and the trigger wouldn't work...

After those problems, I decided to start from scratch. So I started a fresh clone of the github repo. I made sure not to invoke kernel_menuconfig this time. and In regular menuconfig, I did not ask to install these modules. And I still get the functionality.

I want to know why, and I'd like a bigger picture of how menuconfig and kernel_menuconfig work together. For example, since the same kernel modules are available for selection in both menuconfigs, what happens when:

  • you specify the module * in regular menuconfig and not kernel_menuconfig.

  • you specify the module * in kernel_menuconfig and not menuconfig.

  • you specify module to be installed for both

Also, since the modules can be installed either <M> or <*> -- how does this further affect your forecast.. Furthermore, does Kconfig further affect the configuration as I have guessed?

Can someone Guide me on Submitting a Patch

This will be my first large open source project submission, I want to make sure it's done right..

I will look at the first patch made at the beginning of this thread.

I have some questions about The Guidelines . Also if you have any random advice, please give.

Here are my questions:

What are "Logical Changes" -- you see all of the improvements I've made above.. Are those each a logical change?? But, this consists of many changes to the same file.. Does this mean I must segment the changes?? Create a number of patches..? Please educate me what are logical patches and how that affects what I've done here.. And how to organize my patch submission. Thank you!

Code should be in Tabs. not spaces, yeah?

(Last edited by bazz on 17 Apr 2015, 02:27)

Well, I think I've found my problem.

My ART partition was broken and my back up file seems to be wrong (I did not find any valuable information in my backup file of ART using HEX editor.)

Or WNR2000v4 isn't using ART to save information?

Info that are lost include: MAC/Default SSID/Password/WPS PIN/Device ID/Board ID

I think the structure of ART now is still not that right so every time I flash my router, these info will get lost again even if I've set it in U-boot.

I fortunately also backed up my ART. I am scanning it in hexdump for valuable information such as SSID .. It is there.. I don't want to share my ART partition. I am concerned. Eh I'll get over it. EDIT: Got over it .. here's a modified ART with different MAC addresses than my own. I've tested the unit with a modified ART. It appears to function properly. I could surf the web at least. … sp=sharing

Initial Analysis - ART
Using artmtd on
0x0000: WLAN/WAN Mac Address
0x0006: Ethernet switch MAC address
0x000C-0x0013: WPS PIN
0x0014-0x0021: Serial Number -- appears to be zero-padded (0 @ 0x0021)
0x0022: Region Number? 1 == North America
0x0023-0x002F: Board Hardware ID (NOT null terminated)
0x0030-0x003B: Board Model ID (null padded it appears)
0x003C-0x005B: SSID (null padded) LCBW
0x005C-0x009B: wifi password (null padded) LCBW
0x1002: Ethernet switch MAC address (duplicate)

LCBW: Length Could Be Wrong

I am researching if there's checksumming involved. Here's a reference concept:

Try flashing to the proper U-Boot addresses [see UBOOT-Version in the link] if you haven't already figured this out (I updated the post) : … 71#p272671

Let's Restore ART

Note: The checksum bad messages are only because I failed to connect my ethernet until after initiating the command. It usually doesn't say that if you initiate the command with ethernet already connected.. Either way, even tho it complains, it works successfully.

ar7240> tftpboot 81000000 art.backup
Trying eth1
Using eth1 device
TFTP from server; our IP address is
Filename 'art.backup'.
Load address: 0x81000000
Loading: checksum bad
checksum bad
T #############
Bytes transferred = 65536 (10000 hex)
ar7240> erase 0x9f3f0000 +0x10000
Erase Flash from 0x9f3f0000 to 0xffffffff in Bank # 1
First 0x3f last 0x3f sector size 0x10000                                      63
Erased 1 sectors
ar7240> cp.b 0x81000000 0x9f3f0000 0x10000
Copy to Flash... write addr: 9f3f0000
ar7240> md 9f3f0000
# you can verify it's correct..

I can say I just did all of this myself and it worked.. There's no checksumming I presume..
I also wondered what if the duplicate Ethernet is actually a differentiation between WLAN0 and WAN... but I wasn't itching to try it out (what if something bad happens?? .... ) I'm going to try it big_smile

So I tried changing the duplicated MAC addresses, the one at 0x1002 seems to have no effect... so I'd keep it duplicated for good measure. but it was working either way..I didn't test extensively in either case.. But I was able to browse the web over ethernet on port 4, and wireless too.. (in both duplicated and non-duplicated forms)..

(Last edited by bazz on 22 Apr 2015, 05:04)

I submitted a patch series upstream to fix all of the wnr2000-v4 bugs we have all mentioned collectively in this thread. I also added functionality. Details can be found at … 32665.html

There's a possibility that there are two different versions of the wnr2000-v4, one which uses the portmasks I patched and one that likes them the original way.. However, everybody that has reported to this thread has said the original LED portmasks and ethernet did not work for them. But it makes you wonder what the original committer was thinking.. Completely broken ethernet and bad leds?? Cmon man.. [or did he actually have his unit working?]

Latest Images

Please feel free to test these images. Specifically tell me that your ethernet/wifi works [remember to enable the wifi in /etc/config/wireless, or you can now simply press the WLAN button], and that the LEDS are displaying correctly [WAN should be green, LAN amber. Please ensure the correctly numbered LAN LEDS are lit up].

SysUpgrade img: … sp=sharing
RamDisk: … sp=sharing

Patch Set … sp=sharing

Put the patch files into your openwrt.git repo, consider git-stash'ing any current changes and making a new branch.

git am *.patch

to apply all of the patches.

(Last edited by bazz on 21 Apr 2015, 15:32)

For those WITHOUT Serial Access

EDIT: I've figured out several ways to do it.. Find my post for details..

Growell wrote:

To my knowledge the only way to get this to work is by using a serial cable (Somebody feel free to prove me wrong).

I think there's another way. I haven't tried it. We can use MTD. Unless the partition is read-only!!

BEWARE -- u-boot-env actually mirrors the ART -- hexdump -C /dev/mtd1 == /dev/mtd9 -- advised not to follow rest of this tutorial

Incase you are brave you can try using my u-boot-env partition, which only is modified to not use the CRC check. I'm not sure if there could be any other conflicts between my settings and your router's. That's your risk. I don't think it will be a problem, but I'M NOT liable. It's your decision to take this risk.


Using the code snippets below, connect the dots with a TFTP server and your router's tftp and mtd commands.

I say this later in this post, but I'd like to re-iterate -- it could be more effective to flash the u-boot-env partition after flashing the firmware, IF it's possible to do so. Otherwise this may or may not work until proven further.

Technical Explanation
You might be able to modify your own u-boot-env instead of using mine by following these still risky instructions [untested].

root@OpenWrt:~# hexdump -C /dev/mtdblock1
00000000  49 14 c7 3c 62 6f 6f 74  61 72 67 73 3d 63 6f 6e  |I..<bootargs=con|
00000010  73 6f 6c 65 3d 74 74 79  53 30 2c 31 31 35 32 30  |sole=ttyS0,11520|
00000020  30 20 72 6f 6f 74 3d 33  31 3a 30 32 20 72 6f 6f  |0 root=31:02 roo|
00000030  74 66 73 74 79 70 65 3d  6a 66 66 73 32 20 69 6e  |tfstype=jffs2 in|
00000040  69 74 3d 2f 73 62 69 6e  2f 69 6e 69 74 20 6d 74  |it=/sbin/init mt|
00000050  64 70 61 72 74 73 3d 61  74 68 2d 6e 6f 72 30 3a  |dparts=ath-nor0:|
00000060  32 35 36 6b 28 75 2d 62  6f 6f 74 29 2c 36 34 6b  |256k(u-boot),64k|
00000070  28 75 2d 62 6f 6f 74 2d  65 6e 76 29 2c 36 33 33  |(u-boot-env),633|
00000080  36 6b 28 72 6f 6f 74 66  73 29 2c 31 34 30 38 6b  |6k(rootfs),1408k|
00000090  28 75 49 6d 61 67 65 29  2c 36 34 6b 28 6d 69 62  |(uImage),64k(mib|
000000a0  30 29 2c 36 34 6b 28 41  52 54 29 00 62 6f 6f 74  |0),64k(ART).boot|
000000b0  64 65 6c 61 79 3d 31 00  62 61 75 64 72 61 74 65  |delay=1.baudrate|
000000c0  3d 31 31 35 32 30 30 00  65 74 68 61 64 64 72 3d  |=115200.ethaddr=|
000000d0  30 78 30 30 3a 30 78 61  61 3a 30 78 62 62 3a 30  |0x00:0xaa:0xbb:0|
000000e0  78 63 63 3a 30 78 64 64  3a 30 78 65 65 00 69 70  |xcc:0xdd:0xee.ip|
000000f0  61 64 64 72 3d 31 39 32  2e 31 36 38 2e 31 2e 31  |addr=|
00000100  00 73 65 72 76 65 72 69  70 3d 31 39 32 2e 31 36  |.serverip=192.16|
00000110  38 2e 31 2e 31 30 00 64  69 72 3d 00 6c 75 3d 74  ||
00000120  66 74 70 20 30 78 38 30  30 36 30 30 30 30 20 24  |ftp 0x80060000 $|
00000130  7b 64 69 72 7d 75 2d 62  6f 6f 74 2e 62 69 6e 26  |{dir}u-boot.bin&|
00000140  26 65 72 61 73 65 20 30  78 39 66 30 30 30 30 30  |&erase 0x9f00000|
00000150  30 20 2b 24 66 69 6c 65  73 69 7a 65 3b 63 70 2e  |0 +$filesize;cp.|
00000160  62 20 24 66 69 6c 65 61  64 64 72 20 30 78 39 66  |b $fileaddr 0x9f|
00000170  30 30 30 30 30 30 20 24  66 69 6c 65 73 69 7a 65  |000000 $filesize|
00000180  00 6c 66 3d 74 66 74 70  20 30 78 38 30 30 36 30  |.lf=tftp 0x80060|
00000190  30 30 30 20 24 7b 64 69  72 7d 64 62 31 32 78 24  |000 ${dir}db12x$|
000001a0  7b 62 63 7d 2d 6a 66 66  73 32 26 26 65 72 61 73  |{bc}-jffs2&&eras|
000001b0  65 20 30 78 39 66 30 35  30 30 30 30 20 2b 30 78  |e 0x9f050000 +0x|
000001c0  36 33 30 30 30 30 3b 63  70 2e 62 20 24 66 69 6c  |630000;cp.b $fil|
000001d0  65 61 64 64 72 20 30 78  39 66 30 35 30 30 30 30  |eaddr 0x9f050000|
000001e0  20 24 66 69 6c 65 73 69  7a 65 00 6c 6b 3d 74 66  | $|
000001f0  74 70 20 30 78 38 30 30  36 30 30 30 30 20 24 7b  |tp 0x80060000 ${|
00000200  64 69 72 7d 76 6d 6c 69  6e 75 78 24 7b 62 63 7d  |dir}vmlinux${bc}|
00000210  2e 6c 7a 6d 61 2e 75 49  6d 61 67 65 26 26 65 72  |.lzma.uImage&&er|
00000220  61 73 65 20 30 78 39 66  36 38 30 30 30 30 20 2b  |ase 0x9f680000 +|
00000230  24 66 69 6c 65 73 69 7a  65 3b 63 70 2e 62 20 24  |$filesize;cp.b $|
00000240  66 69 6c 65 61 64 64 72  20 30 78 39 66 36 38 30  |fileaddr 0x9f680|
00000250  30 30 30 20 24 66 69 6c  65 73 69 7a 65 00 73 74  |000 $|
00000260  64 69 6e 3d 73 65 72 69  61 6c 00 73 74 64 6f 75  |din=serial.stdou|
00000270  74 3d 73 65 72 69 61 6c  00 73 74 64 65 72 72 3d  |t=serial.stderr=|
00000280  73 65 72 69 61 6c 00 65  74 68 61 63 74 3d 65 74  |serial.ethact=et|
00000290  68 30 00 62 6f 6f 74 63  6d 64 3d 62 6f 6f 74 6d  |h0.bootcmd=bootm|
000002a0  20 30 78 39 66 30 34 30  30 30 30 00 00 73 69 7a  | 0x9f040000..siz|
000002b0  65 00 73 74 64 69 6e 3d  73 65 72 69 61 6c 00 73  |e.stdin=serial.s|
000002c0  74 64 6f 75 74 3d 73 65  72 69 61 6c 00 73 74 64  |tdout=serial.std|
000002d0  65 72 72 3d 73 65 72 69  61 6c 00 65 74 68 61 63  |err=serial.ethac|
000002e0  74 3d 65 74 68 30 00 00  00 00 00 00 00 00 00 00  |t=eth0..........|
000002f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

We see that, aside from the first 4 bytes whose purpose is unknown to me (haven't studied UBOOT), most of the UBOOT variables are simply separated by a zero byte. I take note that one of them is separated by 2 zero bytes (bootcmd).

It's should be possible to modify an mtd1 image and restore it, thereby bypassing the need to do so from U-BOOT serial terminal. Exactly what format is acceptable I'm not sure, but I was thinking that since the original bootcmd is longer than the final, perhaps we can rewrite the bootcmd and then pad with NULL bytes until the next env variable. smile It's worth a shot for those without access to the serial console, and also, you will probably need to host a TFTP server in order to send the file to your host computer for editing, and also to retrieve it after editing.

On Ubuntu, I recommend tftp-hpa

After you've telnet-enable'd your stock netgear wnr2000-v4 [explained earlier in this thread and on openwrt wiki], from the root shell:
I assume your computers ip address from the router's perspective is and your tftp server is setup on port 69. You must enable file creation in tftpd.

dd if=/dev/mtd1 of=/tmp/uboot_env.backup
cd /tmp
tftp -p -r uboot_env.backup 69
# I'm guessing those are the proper tftp flags, check yourself.

# after editing
tftp -g -r new_uboot_env.img 69
mtd [-f] write new_uboot_env.img u-boot-env
# -f in brackets cause I'm not sure you'll need it

# Now proceed flashing the openwrt firmware sysupgrade image.
# Warning: You might have to flash u-boot-env AFTER flashing the firmware, on account from personal experience, the bootcmd would be fixed up to do the CRC again. I'm not sure if you can flash the firmware without the -r flag in mtd, but if you can, try doing that and uploading the u-boot-env after the firmware. then reboot.

(Last edited by bazz on 22 Apr 2015, 21:33)

Continuing my research with serial-less flashing.. Some notes of my current happenings:

It is possible to use the NETGEAR - Open Source Code for Programmers SDK to produce an image with a rewrite-able U-Boot partition. The partition can be downloaded via tftp to the Host PC, hex-edited by editing the bootcmd=bootm 0x9f040000 and then NULL padding the difference, and re-uploaded to the u-boot partition.. I've actually done this process to upload an OpenWRT image. I then realized it may not have to be that complex..

I initially believed that the u-boot-env partition was a duplicate of the ART partition.. and the official netgear firmware does in fact use the u-boot-env partition as a duplicate redundant backup of the ART.. but it still functions as a uboot-environment! I think!! So now I'm trying that out to see if that works!! The great thing is that IF this works, it requires no modification / new images whatsoever!! because the u-boot-env is completely writeable from the stock firmware big_smile

Allow custom firmware to be flashed from Firmware Recovery (Factory Reset) Mode
Firmware Recovery mode will only flash DNI images. We can learn to make them here. This is just good to know but nobody will likely need to use this. Also, just cause it flashes the image does not mean it will boot it!! There are other checksums involved for that! [Linux kernel size limitation? 832K] And since I don't know how to bypass them we are going to later modify Uboot-Env as usual....
In the SDK is a tool that can be applied directly to the sysupgrade image. here's an example

from wnr2000v4-V1.0.0.58_gpl_src:
./staging_dir/host/bin/mkdniimg -B wnr2000v4 -v V1.0.0.58 -r "" -H "29763904+4+32" -i /home/bazz/Desktop/netgear_official/wnr2000v4-V1.0.0.58_gpl_src/bin/openwrt-wnr2000v4-wnr2000v4-squashfs-sysupgrade.bin -o /home/bazz/Desktop/netgear_official/wnr2000v4-V1.0.0.58_gpl_src/bin/wnr2000v4-V1.0.0.58"".img

I don't know what's up with the double quotes there, it was the way the official script compiled the command.. must be an empty argument..

Notes on Compiling w/ Netgear WNR2000v4 SDK
follow instructions in

During make, will crash.. here's how to fix:

vi build_dir/host/mklibs/src/mklibs-readelf/elf.cpp
#include <unistd.h>

quilt complained about my /usr/bin/patch because it uses a faulty version check.. I manually confirmed my patch was a good version, then hacked an override:
add ! to line 5913 if ! test -z "$patch_version" ; then

need dos2unix..
sudo apt-get install dos2unix

can make uboot r/w here:
./target/linux/wnr2000v4/image/Makefile: find the line like


(Last edited by bazz on 22 Apr 2015, 09:07)

Guide: Flashing Without Serial Access

Anything not explained here is probably well explained in other parts of this thread / the net.

I wrote this guide over the past 24 hours as I went along. I discovered 3 methods. I think if you want to "chew'n'screw" you should go for Option 1b.. My favorite is 1a but it's a splat of development rather than a tool.

The 2 main options are:

  1. Modify u-boot-env

  2. Modify u-boot

Let's learn a little about U-Boot's environment on WNR2000v4. There are 2 environments. Only one can be loaded at a time. The unit first looks for a valid crc32'd environment in the u-boot-env partition. I might call this "preferences." If that's corrupted, or missing, it goes into u-boot partition's internal "default" environment. The thing that's nice about modifying the default is that if you find yourself installing the stock firmware again in the future, which could happen sooner than you think, the default will be on your side to save you smile.. Otherwise you'll have to repeat one of the other processes if that's what you go with... This all stems from the fact that WNR2000v4 stock firmware ( at least) overwrites the preferences with a copy of ART data.

Anyways, let's begin, shall we?

Option 1

Warning (option 1 only): If you reboot back into stock firmware after applying the changes below, your work will be undone. This is part of the "stock" wireless boot-up check. Don't let this happen. You can always redo the work if necessary.


  1. Make your own image -- difficult, tailored to your environment

  2. Use a pre-made u-boot-env image == easy, might be risky

Make your own image
This way is probably the most guaranteed safe secure way. Follow my lead conceptually:
* on host PC

python 28C68E26DA82 admin password
telnet router
# from router root telnet session: 
dd if=/dev/mtd0 of=/tmp/u-boot.backup
# it's good to make this backup anyways.. Keep it for your records
hexdump -C /tmp/u-boot.backup # verify you dumped the right thing.. Look for the environment variables. See Appendix A for an example.

cd tmp; tftp -p -r u-boot.backup 69

Now Open up the file in a hex editor on host PC, and find the environment variables... I found mine @ 0x2c7c0. Copy from the first letter of the first variable right down to the last letter of the last variable, but also include the null char after.. Because these variables all have to be NULL-padded. Anyways It's 1 big chunk of information.
Create a new file in your hex editor and paste what you copied. I called my file "u-boot-env-variables.bin"
you can manually adjust the bootcmd or do it the pretty way. Let's try the pretty way.

sed 's/\x0/\xa/g' u-boot-env-variables.bin > u-boot-env-vars.txt
vi u-boot-env-vars.txt

bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),64k(mib0),64k(ART)
bootcmd=sleep 1; nmrp; nor_two_part_fw_integrity_check 0x9f040000; bootm 0x9f040000
lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize;cp.b $fileaddr 0x9f000000 $filesize
lf=tftp 0x80060000 ${dir}db12x${bc}-jffs2&&erase 0x9f050000 +0x630000;cp.b $fileaddr 0x9f050000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize;cp.b $fileaddr 0x9f680000 $filesize

That makes it nice and easy to work with as regular text.. Now edit the bootcmd line to be like the following:

bootcmd=bootm 0x9f040000

Save the file.

 tr -s '\n' '\000' < u-boot-env-vars.txt > u-boot-env-vars-hacked.bin 

Use this C program:

#include <zlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>

#define min(x,y) ((x < y) ? x:y)
#define BUFSIZE 1000

int main(int argc, char **argv)
    // too lazy for error checking :D
    char fbuf[BUFSIZE];
    int r;
    int fd;
    uLong crc = crc32(0L, Z_NULL, 0);

    fd = open(argv[1],O_RDONLY);
    if (!fd) exit(1);

    struct stat buf;
    fstat(fd, &buf);

    while ( (r = read (fd, fbuf, BUFSIZE)) > 0)
        crc = crc32(crc, fbuf, r);
        //write(1, fbuf, r);

    //printf("%04lX", crc);
    putchar( (crc >> 24) & 0xff);    
    putchar( (crc >> 16) & 0xff);
    putchar( (crc >> 8) & 0xff);
    putchar( (crc) & 0xff);
    return 0;

compile with gcc crc32.c -lz -o crc32

# pad the file
dd if=/dev/zero bs=1 count=65532 of=padded.bin
dd if=u-boot-env-vars-hacked.bin of=padded.bin conv=notrunc
./crc32 padded.bin > final_env.bin; cat padded.bin >> final_env.bin

Back in router telnet root shell, in /tmp

tftp -g -r final_env.bin 69
mtd -f write final_env.bin u-boot-env

Now, we have to verify we did this right. And the best way is to use a clean application rather than reboot. I've hacked together a fw_printenv/setenv that works on stock firmware (tested on It works by disabling the lock file (broken on stock firmware), and hard-coding the MTD configuration. Relative files are located in my openwrt build at openwrt/build_dir/target-mips_34kc_uClibc-

We can use this as follows:
Lines starting with # are my own comments.

root@WNR2000v4:/tmp# tftp -g -r fw_printenv 69
root@WNR2000v4:/tmp# chmod +x ./fw_printenv 
root@WNR2000v4:/tmp# ./fw_printenv
Warning: Bad CRC, using default environment

# this means the u-boot-env is not programmed correctly. This is what we will fix now.
root@WNR2000v4:/tmp# tftp -g -r fe.bin 69      
root@WNR2000v4:/tmp# mtd -f write fe.bin u-boot-env
Unlocking u-boot-env ...
Writing from fe.bin to u-boot-env ...  [w]
root@WNR2000v4:/tmp# ./fw_printenv
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),64k(mib0),64k(ART)
bootcmd=bootm 0x9f040000
lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize;cp.b $fileaddr 0x9f000000 $filesize
lf=tftp 0x80060000 ${dir}db12x${bc}-jffs2&&erase 0x9f050000 +0x630000;cp.b $fileaddr 0x9f050000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize;cp.b $fileaddr 0x9f680000 $filesize

# We got an environment. that means we did it ! :D otherwise there was something wrong (??)

# just for fun, I will go over how to use setenv program a variable directly. 
# It will work even if your preferences environment does not have a correct CRC32 / hasn't been initialized yet. 
# if it complains about bad CRC, it means it's your first entry, which will create the new environment :)
root@WNR2000v4:/tmp# ln -s ./fw_printenv fw_setenv
root@WNR2000v4:/tmp# ./fw_setenv boot_delay 2
root@WNR2000v4:/tmp# ./fw_printenv boot_delay
root@WNR2000v4:/tmp# hexdump -C /dev/mtd1 

At this point you should transfer your sysupgrade img to the router via TFTP and then flash it.

tftp -g -r sysfsupgrade.bin 69
mtd -f -r write sysfsupgrade.bin firmware

Then your router will reboot with the new firmware hopefully, and you can telnet in without needing a telnet-enable. At that point, you customize your router. Have fun : )

Use a pre-made u-boot-env image
This is the easiest method, no work on your part. But since nobody has tried my environment in their router, I can't guarantee you this will work, and it's 100% your own decision to try this method. I am not liable and you agree to that if you try this. You might get bricked (probably not).

We are going to overwrite the u-boot-env partition via the netgear telnet-enable root shell.

you must already be running a TFTP server on the host PC that the router can reach, typically via ethernet. in my example I gave my Host PC a static IP (host setting) of because it's also the pre-programmed IP for the TFTP functions in u-boot.

We will be using my u-boot-env partition to do this. My u-boot-env partition may make the process simple for you, but there is a possibility for error. consider any possible differences that you should account for by comparing the env inside of your u-boot (for my unit it's in mtd0:0x2c7bc) with my u-boot-env. See Appendix A for notes on the analysis process.

If you notice drastic differences, be careful not to brick your unit, especially if you don't have access to JTAG. Report here. Otherwise, should be good to go.

On the Host PC, Download my u-boot-env partition into your TFTP downloads directory (ie. /tftpboot):

Now, from WNR2000V4 root shell, assuming TFTP server at 

cd /tmp
tftp -g -r uboot_env_bootcmd_nocrc.backup 69
mtd -f write uboot_env_bootcmd_nocrc.backup u-boot-env

Now upload your new sysupgrade bin file and reboot. Should be golden!

Option 2

Manually modify your u-boot's default environment.

This is like a backup environment when your u-boot-env partition gets messed up. I'm not a big fan of this option, but I did figure out how to do it along the way. So I'll leave this guide here for those wanting to do it.

Note: I don't think there is a checksum on this environment.

Download this modified Netgear WNR2000V4 img to your home computer, and then into the router via the router web interface or tftp Firmware Recovery mode. This image has the u-boot partition writable.

You're likely going to need TFTP server for the rest.. Here's how I did it.

on router root shell [telnet-enable],

dd if=/dev/mtd0 of=/tmp/uboot.backup
tftp -p -r uboot.backup 69

On your Host computer

#in the tftp downloads directory (/tftpboot for me)
cp uboot.backup uboot.bootcmd.mod
ghex uboot.bootcmd.mod
# I'm opening the file in a hex editor
# Look for the bootcmd= and then in overlay mode, rewrite the command to be 
bootcmd=bootm 0x9f040000
pad the rest of the former command to zero's all the way until the next variable.

You maybe don't have to pad all of the zero's, maybe you could delete them and pull back the environment data, leaving the rest of the image precisely at the addresses they originated from. But that's a hassle and I didn't test it. Use your own judgement.

on the router root shell

tftp -g -r uboot.bootcmd.mod 69
mtd -f write uboot.bootcmd.mod u-boot

You may now continue with flashing your firmware.. as per other detailed posts in this thread, but for brevity's sake:

tftp -g -r sysfsupgrade.bin 69
mtd -f -r write sysfsupgrade.bin firmware

Appendix A

u-boot analysis
It doesn't matter if your u-boot environment is located at a different address from mine. What we're concerned about is whether you have different variables or variables with different values.
To perform this analysis:

hexdump -C /dev/mtd0

Here's a sample; the forum may have mangled the output, copy paste into fixed-width editor for best results.

0002c7b0  00 02 00 00 00 02 00 00  ff ff ff ff 00 00 00 00  |................|
0002c7c0  62 6f 6f 74 61 72 67 73  3d 63 6f 6e 73 6f 6c 65  |bootargs=console|
0002c7d0  3d 74 74 79 53 30 2c 31  31 35 32 30 30 20 72 6f  |=ttyS0,115200 ro|
0002c7e0  6f 74 3d 33 31 3a 30 32  20 72 6f 6f 74 66 73 74  |ot=31:02 rootfst|
0002c7f0  79 70 65 3d 6a 66 66 73  32 20 69 6e 69 74 3d 2f  |ype=jffs2 init=/|
0002c800  73 62 69 6e 2f 69 6e 69  74 20 6d 74 64 70 61 72  |sbin/init mtdpar|
0002c810  74 73 3d 61 74 68 2d 6e  6f 72 30 3a 32 35 36 6b  |ts=ath-nor0:256k|
0002c820  28 75 2d 62 6f 6f 74 29  2c 36 34 6b 28 75 2d 62  |(u-boot),64k(u-b|
0002c830  6f 6f 74 2d 65 6e 76 29  2c 36 33 33 36 6b 28 72  |oot-env),6336k(r|
0002c840  6f 6f 74 66 73 29 2c 31  34 30 38 6b 28 75 49 6d  |ootfs),1408k(uIm|
0002c850  61 67 65 29 2c 36 34 6b  28 6d 69 62 30 29 2c 36  |age),64k(mib0),6|
0002c860  34 6b 28 41 52 54 29 00  62 6f 6f 74 63 6d 64 3d  |4k(ART).bootcmd=|
0002c870  73 6c 65 65 70 20 31 3b  20 6e 6d 72 70 3b 20 6e  |sleep 1; nmrp; n|
0002c880  6f 72 5f 74 77 6f 5f 70  61 72 74 5f 66 77 5f 69  |or_two_part_fw_i|
0002c890  6e 74 65 67 72 69 74 79  5f 63 68 65 63 6b 20 30  |ntegrity_check 0|
0002c8a0  78 39 66 30 34 30 30 30  30 3b 20 62 6f 6f 74 6d  |x9f040000; bootm|
0002c8b0  20 30 78 39 66 30 34 30  30 30 30 00 62 6f 6f 74  | 0x9f040000.boot|
0002c8c0  64 65 6c 61 79 3d 31 00  62 61 75 64 72 61 74 65  |delay=1.baudrate|
0002c8d0  3d 31 31 35 32 30 30 00  65 74 68 61 64 64 72 3d  |=115200.ethaddr=|
0002c8e0  30 78 30 30 3a 30 78 61  61 3a 30 78 62 62 3a 30  |0x00:0xaa:0xbb:0|
0002c8f0  78 63 63 3a 30 78 64 64  3a 30 78 65 65 00 69 70  |xcc:0xdd:0xee.ip|
0002c900  61 64 64 72 3d 31 39 32  2e 31 36 38 2e 31 2e 31  |addr=|
0002c910  00 73 65 72 76 65 72 69  70 3d 31 39 32 2e 31 36  |.serverip=192.16|
0002c920  38 2e 31 2e 31 30 00 64  69 72 3d 00 6c 75 3d 74  ||
0002c930  66 74 70 20 30 78 38 30  30 36 30 30 30 30 20 24  |ftp 0x80060000 $|
0002c940  7b 64 69 72 7d 75 2d 62  6f 6f 74 2e 62 69 6e 26  |{dir}u-boot.bin&|
0002c950  26 65 72 61 73 65 20 30  78 39 66 30 30 30 30 30  |&erase 0x9f00000|
0002c960  30 20 2b 24 66 69 6c 65  73 69 7a 65 3b 63 70 2e  |0 +$filesize;cp.|
0002c970  62 20 24 66 69 6c 65 61  64 64 72 20 30 78 39 66  |b $fileaddr 0x9f|
0002c980  30 30 30 30 30 30 20 24  66 69 6c 65 73 69 7a 65  |000000 $filesize|
0002c990  00 6c 66 3d 74 66 74 70  20 30 78 38 30 30 36 30  |.lf=tftp 0x80060|
0002c9a0  30 30 30 20 24 7b 64 69  72 7d 64 62 31 32 78 24  |000 ${dir}db12x$|
0002c9b0  7b 62 63 7d 2d 6a 66 66  73 32 26 26 65 72 61 73  |{bc}-jffs2&&eras|
0002c9c0  65 20 30 78 39 66 30 35  30 30 30 30 20 2b 30 78  |e 0x9f050000 +0x|
0002c9d0  36 33 30 30 30 30 3b 63  70 2e 62 20 24 66 69 6c  |630000;cp.b $fil|
0002c9e0  65 61 64 64 72 20 30 78  39 66 30 35 30 30 30 30  |eaddr 0x9f050000|
0002c9f0  20 24 66 69 6c 65 73 69  7a 65 00 6c 6b 3d 74 66  | $|
0002ca00  74 70 20 30 78 38 30 30  36 30 30 30 30 20 24 7b  |tp 0x80060000 ${|
0002ca10  64 69 72 7d 76 6d 6c 69  6e 75 78 24 7b 62 63 7d  |dir}vmlinux${bc}|
0002ca20  2e 6c 7a 6d 61 2e 75 49  6d 61 67 65 26 26 65 72  |.lzma.uImage&&er|
0002ca30  61 73 65 20 30 78 39 66  36 38 30 30 30 30 20 2b  |ase 0x9f680000 +|
0002ca40  24 66 69 6c 65 73 69 7a  65 3b 63 70 2e 62 20 24  |$filesize;cp.b $|
0002ca50  66 69 6c 65 61 64 64 72  20 30 78 39 66 36 38 30  |fileaddr 0x9f680|
0002ca60  30 30 30 20 24 66 69 6c  65 73 69 7a 65 00 00 00  |000 $filesize...|
0002ca70  9f 03 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002ca80  00 00 00 01 00 00 00 00  00 00 00 01 00 00 00 00  |................|
0002ca90  00 00 00 00 00 00 00 01  00 00 00 01 00 00 00 00  |................|
0002caa0  00 00 00 01 00 00 00 00  00 00 00 01 00 00 00 01  |................|
0002cab0  00 00 00 01 00 00 00 00  00 00 00 01 00 00 00 00  |................|
0002cac0  00 00 00 02 00 00 00 01  00 00 00 01 00 00 00 00  |................|
0002cad0  00 00 00 01 00 00 00 00  00 00 00 03 00 00 00 01  |................|
0002cae0  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002caf0  00 00 00 04 00 00 00 01  00 00 00 00 00 00 00 01  |................|
0002cb00  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 01  |................|
0002cb10  ff ff ff ff ff ff ff ff  ff ff 00 00 c0 a8 01 01  |................|
0002cb20  c0 a8 00 00 00 00 00 01  00 00 00 01 00 00 00 00  |................|
0002cb30  00 00 00 3c 66 69 72 6d  77 61 72 65 00 00 00 00  |...<firmware....|

(Last edited by bazz on 22 Apr 2015, 21:39)

Good news, my patch series has been merged.

Thanks everyone for all the hard work on this!

Now that we have a viable image, what would it take to create a factory image from this?  I've been trying to investigate what is required to build the factory image but haven't been able to scrape together all the necessary pieces of the information puzzle yet.  It seems like the only real difference is some header information for the stock boot loader, and that must already be known for the WNR2000v3 as it has a factory image available.  I've built the sysupgrade image but I am not familiar enough with the build chain to know what controls the model specific factory image generation.  Anyone have any pointers?

skysurfer -- When you say "factory image" I assume you mean one that can be uploaded thru netgear's web interface. I have created such an image and documented the process in this page. search for "Allow custom firmware to be flashed from Firmware Recovery" -- but the bootloader bootparams must still need to be modified otherwise the image won't boot although it was effectively installed (suspected to be because linux kernel size > 832K we believe). This limitation is removed by modifying the U-boot bootparams CRC check function, there are extremely detailed how-to's in this thread how to do this both with & without serial access to the router. I trust you can seek it out.

It may be possible to create an OpenWrt image whose Linux Kernel is < 832K, but it must continue to be a useful kernel or it is pointless. If this was made, there would be no need for U-Boot env mod, making it a much friendlier installation. Users would have to ensure they compile as many things as modules to keep kernel size down.

Irregardless, I advocate everyone to back up their MTD partitions incase of brickage (documented somewhere on openwrt wiki).

bazz - I apologize I am quite new with the OpenWRT world.   

Yes, it appears what I termed "factory image" would be considered the DNI image. 

I was able to modify the ar71xx/image/Makefile to include the code to for generating the the DNI "factory" image

define Image/Build/NetgearLzma
        $(eval fwsize=$(call mtdpartsize,firmware,$(4)))
        $(call CatFiles,$(KDIR_TMP)/vmlinux-$(2).uImage,0,$(KDIR)/root.$(1),$(fwsize),$(call sysupname,$(1),$(2)),64)
        if [ -e $(call sysupname,$(1),$(2)) ]; then \
                for r in $(7) ; do \
                        [ -n "$$$$r" ] && dashr="-$$$$r" || dashr= ; \
                        $(STAGING_DIR_HOST)/bin/mkdniimg \
                                -B $(6) -v OpenWrt.$(REVISION) -r "$$$$r" $(8) \
                                -i $(call sysupname,$(1),$(2)) \
                                -o $(call imgname,$(1),$(2))-factory$$$$dashr.img; \
                done; \


and added the board hardware IDs you found in the official Netgear SDK. 

$(eval $(call SingleProfile,NetgearLzma,64kraw,WNR2000V4,wnr2000v4,WNR2000V4,ttyS0,115200,$$(wnr2000v4_mtdlayout),0x32303034,WNR2000V4,"" NA,-H 29763904+4+32))

This successfully generated the DNI image using the OpenWRT build system.  Thank you for pointing me to that post.

Digging into the kernel size limit, the default MTD layout has the kernel partition sized to 832Kb.  From what I have found so far, it seems that layout is specified in the image, so it should be a simple case of increasing the kernel partition and taking some away from the rootfs in the build scripts...  Unless I am missing some vital part of the process.

I will try to flash the image from the web interface this weekend and see if I have any success after trying to tweak the MTD layout.

Sweet. Good luck!

(Last edited by bazz on 23 May 2015, 18:21)

@skysurfer Can you create a patch against whatever files you modified and please upload the patch file for us all. You may use pastebin, please set 'expire' to never.

(Last edited by bazz on 24 May 2015, 13:00)

i just wanted to know if there are some news regarding the kernel size limit for booting?

And which is the most current image that can be used for testing, or will i have to build one on my own as described in bazzs post?