For what it is worth, page the La Fonera is still one of the better deals on basic embedded systems on the internet. I have looked at it before and shelved it for quite some time until I needed it again for a prank (open wifi, side effects http redirection, malady etc). The available documentation, at the time of writing, is a bit spotty but one can gather enough information to build and test firmware based on the OpenWRT project. This guide will hopefully illustrate the complete process from the very start to actually running the custom firmware.
1. Setting up the build enviornment
Our build target is a Linux system, so naturally it would make sense to have a Linux system to build our firmware. If you have access to a system with ~4GB of free storage, then you are set, otherwise we will have to set one up. It was easiest for me to simply use VMware Server (free with registration) to install a Debian system (get the CD1 iso here). I installed just the most basic release and added what I needed using “apt-get install <package>” once the system came online. The packages that I added were: gcc, binutils, patch, bzip2, flex, bison, make, gettext, pkg-config, unzip, libz-dev, toolchain-source, autoconf, build-essential, wget, ssh, ncurses-dev, gawk. At this point, the system should be ready to build the firmware.
At this point, we are ready to decide if we want to build the standard OpenWRT Kamikaze (http://downloads.openwrt.org/kamikaze/7.09/kamikaze_7.09.tar.bz2) release or if we want to build the fonera version (http://download.fon.com/firmware/fonera/latest/fonera.tar.bz2) instead. The Fon release is based on OpenWRT so the directory structure is nearly identical. If participating in the Fon network is important, then the fonera release should probably be selected. Either of these is then downloaded and uncompressed.
Once the source code is unpacked, we can simply run “make menuconfig” (or “make config”) in the source directory to set some of the preferences. The most important preference is to make sure that the target system is set to “Atheros” to match our board. Once this is done, simply running “make” will build the default system in both cases. This will probably take at least an hour. With a default ext2 block size, the build directories can grow to several gigabytes and can cause the build to fail if the drive runs out of space. If we are successful, there should be a set of files with names like “openwrt-atheros-2.6-vmlinux.lzma” and “openwrt-atheros-2.6-root.squashfs” in the bin directory of the source code root. These are the compressed Linux kernel and the filesystem respectively. Once we have built everything using the “make” command, we can update the images only by issuing “make target/install” from the source code root. This simply builds images based on the filesystems in the build_mips/root directory. This would be a good time to look through the system directory structure to understand how everything is put together, perhaps it could be the subject of a later post. For the time being, quick and dirty modifications can be made to build_mips/root and the images rebuilt with “make target/install”. It should be noted that issuing “make” without any arguments will generate a clean build_mips/root directory and default images. The last step for this section is to run a tftp server on the same subnet that the fonera is plugged into. This can be run from the debian in VMware (making sure that iptables allows incoming tftp connections) or another machine, however, the images need to be in the tftp root. For convenience, I renamed the first image vmlinux.lzma and the second one root.fs.
2. Preparing the hardware
The complexity of this section depends on the availability of a TTL to rs232 line converter. If you follow my guide to making a dual-level line converter, you will have all of the tools necessary. The main point is that we need to interface RedBoot loader on the fonera which can easily be done by adding a serial port to the router and hitting Ctrl-C when the system is booting up. The pin schematic is below and the serial settings are 9600bps, 8N1, no flow control.
There are alternative ways to interface RedBoot which involve exploiting the fonera web interface to get root on the system via ssh or telnet and then patching the RedBoot configuration flash to start up with a specific IP address and to run a telnet server on a certain port. More on this can be found on the OpenWRT wiki.
3. Flasing the fonera
With the serial line plugged in and everything running, we can reboot the fonera and hit Ctrl-C as it is loading to enter the RedBoot monitor. We should be greeted with a “RedBoot>” prompt if successful. The first command we will issue here is “ip_address -l x.x.x.x/y -h z.z.z.z”. This will set the fonera’s IP address to x.x.x.x with a netmask dictated by prefix y (24 for 255.255.255.0) and will set the default tftp server to z.z.z.z. “ip_address -l 192.168.1.101/24 -h 192.168.1.47″ is what I used.
NB: Everything up to this point has not permanently modified the fonera, the following steps will modify the flash and should be attempted with the understanding that all information on the fonera will be erased.
The command “fis init” should be executed first to format the flash and make it ready to receive the Linux kernel (vmlinux.lzma) and the filesystem (root.fs). These are the renamed *-vmlinux.lzma and *-root.squashfs files from the bin directory in the source tree which should now be in the root directory of the tftp server. After “fis init” completes, we can verify that only the RedBoot related files remain by issuing the “fis list” command. We fist load the Linux kernel into RAM by running the “load -r -b 0×80041000 vmlinux.lzma” command. This loads vmlinux.lzma from the default tftp server starting at the bottom of memory (0×80041000). The next command, “fis create -e 0×80041000 -r 0×80041000 vmlinux.bin.l7″, copies that image to a flash file called “vmlinux.bin.l7″ (.l7 is L seven, not seventeen), a file that RedBoot tries to load by default when booting the system. This command can take a few minutes to complete so patience is a must.
Once the command completes, we can check how much free space we have left by issuing “fis free” and can expect an output such as “0xA80F000 .. 0xA87E0000″. We need to subtract the former from the latter to know the free segment length which can be done in your head or by issuing “0xA87E0000-0xA80F0000″ as a Google search query. In this example, the result is 0x6F0000. We can now load the root filesystem into RAM via tftp by issuing the “load -r -b 0×80041000 root.fs” command. Once this is loaded into RAM, we create another file in the flash called rootfs, something that the kernel expects, by issuing “fis create -l 0x006F0000 rootfs”. The argument folloing -l will be whatever the length of your free segment actually ends up being. Once the lengthy fis create operation is complete, the router can be rebooted by issuing the “reset” command. More information on this can be found at the OpenWRT wiki.
If everything went smoothly, and assuming you installed OpenWRT/Kamikaze, you should be greeted by the following screen on the serial console: