FreeBSD on the Ubiquiti Routerstation Pro
Webpages
Hardware
- AR7161 - 680MHz
- 128MB SDRAM
- 16MB serial flash
- RTC
- 1 x USB 2.0 socket
- 1 x SD card slot
- 7 x GPIO
- RS232
- JTAG
- Atheros AR8316 Gigabit switch PHY
- 3 + 1 1000baseTX ports, via AR8316 PHY
- 3 x MiniPCI slots
Datasheets
Stuff that's weird/broken
RedBoot caches the flags passed to exec -c. I'm not sure where it does this currently.
The RTC support is there but not yet functioning. It is on the SPI bus; the device datasheet is here - http://www.nxp.com/acrobat_download/datasheets/PCF2123_1.pdf The problem is that it shares the CS line with flash and thus requires some hackery in order to correctly function.
The USB code in -head needs some alignment fixes to work properly. A symptom is "AutoSense failed" when trying to probe the on-board SD slot which is a USB mass device. Kan has written a patch - http://people.freebsd.org/~kan/usb_rspro.diff .
- The SD slot can't easily be used as a root device - it doesn't probe successfully until -after- single user mode startup begins.
- Reading/writing data from /dev/redboot/XXX character devices must be done using an alignment and blocksize of 64k. It is slow and ties up the kernel!
Device/Platform Weirdnesses
Playing with MDROOT
- I'm using FFS version 1 and "makefs" to build an MDROOT. Note that the endian-ness needs to be forced to match the MIPS endian-ness (I'm using big endian) and the kernel vfs mount output when this is incorrect is very unhelpful.
Flash images
- OpenWRT has some code from Ubquity which builds the images:
- The above tool needs to be modified to generate different load and entry points - the Linux images use the same load/entry points but FreeBSD's elf image doesn't
The version string must start with RSPRO or the RedBoot loader will refuse to run it!
The RedBoot loader understands GZIP - so the kernel image can simply be gzip -9'ed to fit in the available space. The RedBoot loader will ungzip it into memory for you before executing.
RedBoot will refuse to write a kernel image that isn't a multiple of 64k (flash sector size?) Thus the kernel image must be padded before being fed to the firmware image program.
The image generated by the above program will overwrite the non-system FIS partitions - so it's in effect a "fresh" start. It also avoids having to manually fiddle with fis commands at the RedBoot prompt and potentially bricking the unit.
Building Software
- I'm building binary packages on the units themselves via an NFS root. That works fine - the ports system however needs a bit of hand holding to tell it to use the right endian-ness. Add TARGET_BIG_ENDIAN=true to /etc/make.conf before building any ports.
Stuff that's been fixed
- PCI didn't work unless you boot verbose. You can do this by passing a -v flag to the kernel by using the -c flag to exec. Ie, exec -c "-v". gonzo fixed this in -HEAD by adding a longer delay into the PCI bus probing logic