TLDR: U-BOOT RECOVERY MODE IS THE ONLY WAY TO FLASH RELIABLY. PUBLIC RELEASE BUILDS ARE TOO BIG FOR 4 MB
It feels like I'm following in the footsteps of @SaltwaterC, who figured out support for this router nearly 5 years ago !!!! As difficult as this was, most of the work was already done for me. Special thanks to him and also @pupie (another forum post from ages ago) for inspiration that Flash upgrades are possible. Also special thanks to @Jeff for the JEDEC ID solution
So long story short, I got a hold of this router and saw support for it, but I couldn't find directions and I ended up completely ruining the install and bricking the router. Its supposed to be easy right? I was actually using U-boot commands to bring it into RAM and then write directly to flash. I found out the hard way that this was a bad idea, and it ended up erasing ART in the process... U-boot is great for some things, not others....and this board doesnt do ANYTHING without ART.
I didnt have a backup so I ended up buying another one, they are super cheap anyway. After unbricking the original board, I soon realized that there was a...
HUGE PROBLEM WITH THE PUBLIC RELEASE OF AR71XX/TINY:
the current public builds for ar71xx/tiny are broken, causing kernel panic and boot loop. No one seems to notice though...it is likely the lowest demand branch. Everyone has given up on 4/32 boards.... If you don't believe me, you're welcome to start with todays public release. For U-boot on these boards, TFTP Recovery Mode is extremely safe. There is no way that you won't be able to flash again the same way if something goes wrong.
I realized that I had to make my own builds, the following is a summary of those exploits:
For a while, I gave up on 4 MB Flash size like everyone else...
In order to get the 8 MB versions working on a new 8 MB NOR chip, several things had to be done: In compiling, kernel command line hack to MTDparts, and adding support to the chip I was using. Recompiling U-boot from source using the GPL supplied by Netgear on an Ubuntu system with GCC 4.1 MIPS cross compiler (yikes). In real life, soldering and programming the flash chip (I used the Adafruit FT232H Breakout, a nice cheap option). I use a butane powered hand torch, they heat up much faster and stay hot
Here is the resulting U-boot image I;m currently using on both boards:
U-Boot for WNR1000v2 8 MB Chips
Note that if you use this U-boot image and you had the VC version the board will now act like it is the original retail version (because really, it is now). U-boot will require a little extra configuration and there will be new functions available to modify board ID and model ID stored in ART. If you got that far I'm sure you can figure that small detail out yourself...
Board ID needs to be blank
Model ID needs to be 'WNR1000V2'
The fate of 4 Flash / 32 RAM boards is a very hot topic right now, and the community is about to go one way or the other. But I didnt lose faith, I believed its possible to still run OpenWRT cleanly on 4 MB, and it is, but with special provisons
My 4 MB builds apply these major changes:
no IPv6 support
removed as many kernel mods as I could
included zram-swap (small and helps handle low ram)
I have been testing many images on this board. I recently compiled final versions of my own images for both 4 MB and 8 MB Flash sizes
Most people should just stick to the flash chip they already have, which is 4 MB... You have to really be prepared, its quite a challenge on its own to switch chips
Links to my builds
WNR1000v2 4 MB
WNR1000v2-VC 4 MB
WNR1000v2 8 MB
WNR1000v2-VC 8 MB
It is highly recommended that you have a USB to UART adapter to monitor all of this over a serial connection but for Recovery Mode flashing only its not necessary. If you do use UART, I also recommend you stay away from u-boot commands related to erasing or writing...
There is no reliable way to tell if you have the Retail version or the VC version, some say it is the revision of the Wifi Controller chip (AR9285) but I dont buy it. If you can open a serial console and view the boot log of your specific board. The first line of output clearly tells you. It's all in the software.
just try both files ending with '-factory' and see which one works. if its the wrong one, it will be safely rejected by U-boot
UART Recovery Mode Trick
If you are able to open a serial connection, forcing recovery mode is easily done with a quick trick. After interrupting the boot cycle and entering console with Ctrl + C... simply attempt to boot from a random empty place in ram, for example:
the response will be bad magic number and it will go to TFTP recovery mode.
Otherwise use the reset button:
WNR1000v2 U-boot TFTP reset button sequence:
while router is off begin holding the reset button. turn the router on while holding reset. Power LED starts out as amber. After about 10-12 seconds, Power LED goes from solid amber to blinking amber, KEEP HOLDING RESET
Releasing the reset button while its amber causes factory reset of original firmware. However if you do a factory reset from U-boot with OpenWRT flashed, it will brick the OpenWRT image (unless you update bootargs)
After about 6-8 more seconds, the Power LED goes from blinking amber to blinking green. now you are in TFTP recovery mode and you can release the reset button
Before continuing, read this if you havent already, https://wiki.openwrt.org/doc/howto/generic.flashing.tftp
The router has now started a TFTP Server and is listening for a TFTP Client, at 192.168.1.1 on port 69. The ethernet adapter/network device you are using on the client side (a computer/laptop) must be set to the same subnet but different address, for example: 192.168.1.50
You must connect your computer directly to the router with ethernet and run any TFTP client program you want. set IP address and port of the router's server, find the file you want and hit Put or Send. if it doesnt start right away, go through the TFTP sequence again, while the router is connected to the computer over ethernet
When the TFTP connection starts passing the file, Power LED turns off but the LAN LED remains on. If the file you passed is rejected, it returns to slow blinking and is listening again for a new file. When the transfer is successful, Power LED continues to be off while writing to the chip. When it finishes writing to flash chip, all LEDs go out and router reboots. Power LED becomes amber, the router rebooted and this is the beginning of the boot cycle.
On successful load of the kernel, Power LED goes from amber to off, then blinks green really fast for a few seconds, then slower. That indicates the interval when you can enter failsafe mode in openwrt
The router will continue blinking green until it has finished setting up the JFFS2 partition for the first time, and other first boot tasks...
It is not safe to lose power until the green light is solid again!!! after Power LED remains solid, it is now ready for configuration!!!
Wireless will be off by default and there is no LuCI or OPKG on my build, so you will have to SSH in and use the config files at /etc/config or UCI commands to configure
Using any SSH program you want, 192.168.1.1, port 22.
login as root without password,
then set the root password with
WOOSH, you're in
Feel free to message me if you need help
In the future
I will post how to build your own images as well
I would like to help start a small project, where U-boot images are compiled for those who are able to switch to larger Flash chips
I have not found the small RAM size to make a difference thus far...