Airlink101 AR725W - leitec/openwrt-leitec GitHub Wiki

The Airlink101 AR725W is a 802.11n router from about 2008. It notably supports the 5.8GHz band on channels that do not require DFS.

OpenWrt status

Note: As of r40549 the AR725W is supported by mainline OpenWrt. Barrier Breaker includes binaries for this model.

This fork is stable and fully functional on the AR725W. The hardware components are well-supported in Attitude Adjustment.

Tech Specs

CPU: Ralink RT2880 SoC (MIPS 4KEc) at 266MHz
RAM: 32MB
Flash: 4MB
Ethernet: 100Mbit on a 5-port IP175E switch
Wireless: Ralink RT2872, supports 2.4GHz and 5.8GHz
Expansion: None
JTAG: No idea
Serial: 57600bps, Linux sees as ttyS1

The Asante SmartHub AWRT-600N looks to be the exact same router. Asante's firmware has some additional features that the AR725W's doesn't, but the underlying hardware is based on (or just is) the same Gemtek WRTR-241N board. The factory firmwares seem to share a Gemtek ancestry as well, and have some of the same quirks and problems.

Factory firmware flash map

The flash is mapped at 0xBC400000.

0x000000 - 0x050000 uBoot
    0x30000 uBoot environment variables
    0x40000 RT2872 EEPROM data
    0x40004 MAC address

0x050000 - 0x130000 Linux Kernel
0x130000 - 0x390000 RootFS
0x390000 - 0x3e0000 LANGUAGE_PACK
0x3e0000 - 0x3f0000 NVRAM
0x3f0000 - 0x400000 NVRAM_FACTORY

Firmware info

The bootloader expects a uImage kernel at 0xBC450000. Alternatively, it can load an image via its TFTP client (i.e. a PC is the server). It understands both gzip and LZMA compressed kernels. Anything beyond that is specific to the firmware installed.

Factory firmware: The Linux 2.4 kernel loads a squashfs v3 filesystem. Settings are kept via the NVRAM partition. Some settings are always overwritten at boot. Notably, even with the setting committed, the router re-enables WPS after a reboot. The same is true of the country code: it always stays at "TW."

The NVRAM_FACTORY partition is a bit of a mystery. There is little there and it is seemingly not related to the factory defaults. I have erased both the NVRAM and NVRAM_FACTORY partitions without problems. The firmware recreates NVRAM at boot time or with nvram restore. The LANGUAGE_PACK partition is a bit of a mystery as well. It is erased when flashing a new image via the firmware's web or TFTP interfaces. I have so far not seen any data in there. This is thus an upper limit on size when flashing new images via the web or TFTP interfaces.

Both the web and TFTP interfaces require an image with a 32-byte Gemtek header.

OpenWrt: The OpenWrt port uses only the kernel and rootfs partitions to allow for more room. The kernel fits into the same sized partition (896k), although this should be easily changed. The system automatically creates a subpartition rootfs_data as is standard with OpenWrt. This contains the JFFS2 read-write overlay. This stretches from the first aligned block after the squashfs v4 rootfs to the end of the flash. There is an additional defined partition firmware that is the entire space from kernel to the end, for easy firmware upgrades via sysupgrade.

The current trunk version does away with the distinction between kernel and rootfs entirely and uses a single firmware partition. The system automatically find the squashfs root.

Serial port connection

The serial port is connected at J6 on the board.

    (   ) (RXD) (   ) (   ) (TXD) <
          (   ) (GND) (   ) (VCC)

System-specific u-Boot Notes

The bootloader protects the flash on startup. This is a good thing, and when you do need to flash something it is easily disabled. Note that this only applies to the bootloader! Once the OS takes over, it has full control of the flash chip.

The one critical thing is to NEVER, EVER unprotect the u-Boot partition 0xBC400000-0xBC450000. Without a functioning boot loader, your device is useless, even with a serial console hooked up. Since there doesn't seem to be a JTAG connection available, losing the bootloader spells doom for your router.

The "safe" flash area is 0xBC450000-0xBC7FFFFF. This is the kernel, rootfs and the two NVRAM partitions. This is the area that you can effectively screw up and recover, provided you have the serial console working. Without the console, though, a broken firmware means a broken router. The bootloader doesn't have any way to recover without the console. There's a TFTP client but not a TFTP server, and the client doesn't try to do anything on its own when it finds an unbootable flash. There doesn't seem to be any sort of procedure with the reset button or whatnot to bring it into recovery mode, either.

Here's an example of how to load a file firmware.bin via TFTP onto flash. In this example, the TFTP server is a PC at 192.168.1.100 (defaults to 192.168.3.79) and the client takes 192.168.1.1 (defaults to 192.168.3.244). You can use saveenv to store these values after using setenv. 0x8a800000 is a safe RAM address to load things into. Images flashed this way must begin with a uImage header and not the 32-byte Gemtek header.

setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.100
tftp 8a800000 firmware.bin
erase bc450000 bc7fffff
cp.b 8a800000 bc450000 $(filesize)
bootm

The last line boots into the newly flashed image. If this is the factory firmware, it'll recreate the NVRAM partition. If this is OpenWrt, it'll format the JFFS2 space.