Linksys WRT160Nv2 - leitec/openwrt-leitec GitHub Wiki

The Linksys WRT160Nv2 is a previously-unsupported RT2880-based router sandwiched between the Broadcom-based (and well-supported) v1 and v3 editions. It was apparently the subject of much heartache a few years ago, when it was newer, as none of the alternative firmwares supported it. The factory firmware is about as bad as that of other RT2880 routers, and has known security problems.

OpenWrt status

Fortunately, all of the hardware on the WRT160Nv2 is supported by OpenWrt 12.09. This fork supports the router, with the usual limitations for boards with only 16MB RAM. After some initial problems, it is now possible to flash OpenWrt-leitec from the factory firmware web interface.

IMPORTANT: Occasionally, the switch will stop functioning if certain gigabit Ethernet devices are hooked up. I've found this to be the case with Realtek NICs (ironic, given the switch is a Realtek). This could mean you will not be able to access the router after flashing, since the initial steps have to be done via telnet and SSH while plugged in to the router.

If this is the case, there are two options: 1. find/borrow a compatible computer/NIC for the initial setup steps, and use WiFi from then on, or 2. hook up up a 100Mbit switch between the computer and the router.

This does not happen on the factory firmware (with its binary-only driver for the switch), it seems, but does happen in u-Boot, suggesting it's not a problem with OpenWrt's driver but perhaps a hardware bug. I spent a few hours trying to fix it to no avail.

Tech Specs

CPU: Ralink RT2880 SoC at 266MHz
RAM: 16MB
Flash: 4MB
Ethernet: 100Mbit on a 5-port RTL8306 switch
Wireless: Ralink RT2872, 802.11n 2.4GHz
Expansion: None
JTAG: Possible but unknown
Serial: 115200bps (unlike most RT2880 boards), Linux sees as ttyS1

Factory firmware flash map

The flash is apparently mapped at 0xBF000000. It is mapped at other addresses, but u-Boot won't do erase or write unless the 0xBF000000 base is used. As with the other routers, make sure to not unprotect, erase or otherwise touch the u-Boot partition from 0xBF000000-0xBF040000 to avoid bricking the device.

0x000000 - 0x040000 Bootloader
    0x33990 u-Boot default environment
    0x3EA00 ASCII defaults (WPS PIN, MAC address)
    0x3FE00 RT2872 EEPROM data

0x040000 - 0x3f0000 Kernel
    0xE2464 Rootfs
0x3f0000 - 0x400000 nvram

Firmware notes

Compared with the Gemtek-based routers supported by this fork, the WRT160Nv2 has a smaller u-Boot partition but makes up for it with the 64k nvram partition at the end. u-Boot actually seems to reference it and verifies the checksum, so we can't erase it like on the WRT100/110 and AR725W. But again, since the u-Boot partition is 64k smaller, the total amount of usable space is the same.

The system uses a wacky combination of an uImage and TRX image. u-Boot is actually modified to start looking for the actual data in the uImage after the TRX header ends. I'm not sure what the goal was, but I do know the web firmware flash does read the TRX header to find the length of the image. Thus, it is necessary to accurately put both headers in place for the image to work with the factory firmware, and both must indicate the full length including the rootfs data.

This causes a problem after the JFFS2 partition is formatted in OpenWrt, since the last few bytes that were in the uImage get overwritten. I had to add a function to mtd that runs on firstboot that modifies the header and recalculates the uImage CRC using only the kernel partition data.

This is not necessary for sysupgrade images, since there both the uImage and TRX just include the kernel. The TRX is made first, and then the uImage is made from that. As with the other boards supported here, sysupgrade is the only way to flash larger images.

Serial console

Unlike some other boards, u-Boot on the WRT160Nv2 doesn't show you an option to drop to a command line prompt. Fortunately, if you hit "4" while it is prompting you, Press Ctrl-C or ESC key to stop boot run, it will drop to a prompt.