main

The RouterStation Pro is an Atheros AR7161 MIPS.v2-based board. Geared towards networking applications, it has all of the usual features as well as three type IIIA mini-PCI slots and an on-board 3-port 10/100/1000 Ethernet switch, in addition to the 10/100/1000 Ethernet WAN port which supports Power-over-Ethernet.

Boot Process

The RouterStation uses RedBoot as its boot loader. In the default configuration (shipping as of December 2008), a basic Linux kernel and BusyBox userspace is loaded from flash. The RedBoot boot sequence can be interrupted and a kernel loaded via TFTP instead.

RedBoot uses the WAN port for its network interface.

Once the system is booted, login with username/password ubnt to access the shell.

redboot

Just a quick note

more to myself than anyone else, but I wasn't able to easily find this information online, trolling through the OpenWRT and Ubiquiti forums.

I wanted to try booting different kernels on the device before committing to flashing, so that all I had to do was reboot the board and everything would come back up as normal. It seems obvious that this should be possible, and with a bit of digging around in RedBoot docs, trial and error, and a few lucky guesses I was able to figure out the incantation to make RedBoot load an uncompressed linux kernel (ELF) and boot it:

Note that this does not change the root filesystem, so if your modules aren't compatible, this won't work, but I suspect if you use an embedded initrd you can run the system entirely out of RAM without touching flash.

kernel

expected lzma compressed kernel ( -d means decompress )

RedBoot> cache off
RedBoot> fis load -d -e kernel
RedBoot> go

i am integrating 2.6.32.27 to mips-v2 ar71xx, a lot of patches to be committed

the PCI driver for ar71xx currently (1) doesn't support I/O allocations, only memory allocations

therefore any card requiring I/O won't work for now on ar71xx.

I/O can only be accessed indirectly on ar71xx, so the driver needs special handling for I/O accesses.

(1) currently The PCI controller in ar71xx SoCs only provides access to PCI memory space and PCI configuration space, but not to PCI IO space, it is an hardware limitation of ar71xx SoC, missing hardware able to handle PCI IO space, hardware hack is required with special handling for IO space accesses. Which, in case it is enough to fix the problem, nobody hasn't done yet, and it seems impossible to be fixed.

0010 I/O Read - performs a read from I/O space. All 32 bits of the read address are provided, so that a device can (for compatibility reasons) implement less than 4 bytes worth of I/O registers. If the byte enables request data not within the address range supported by the PCI device (e.g. a 4-byte read from a device which only supports 2 bytes of I/O address space), it must be terminated with a target abort. Multiple data cycles are permitted, using linear (simple incrementing) burst ordering.The PCI standard is discouraging the use of I/O space in new devices, preferring that as much as possible be done through main memory mapping.

0011 I/O Write - performs a write to I/O space.

0110 Memory Read - performs a read cycle from memory space. Because the smallest memory space a PCI device is permitted to implement is 16 bits, the two least significant bits of the address are not needed; equivalent information will arrive in the form of byte select signals. They instead specify the order in which burst data must be returned. If a device does not support the requested order, it must provide the first word and then disconnect. If a memory space is marked as "prefetchable", then the target device must ignore the byte select signals on a memory read and always return 32 valid bits.

0111 Memory Write - operates similarly to a memory read. The byte select signals are more important in a write, as unselected bytes must not be written to memory.Generally, PCI writes are faster than PCI reads, because a device can buffer the incoming write data and release the bus faster. For a read, it must delay the data phase until the data has been fetched.

currently working mini pci board

the PCI controller in ar71xx SoCs only provides access to PCI memory space and PCI configuration space, but not to PCI IO space.
you need to write special handling for IO space accesses, which handle the pci io request mapping it into a memory request: this piece of code is missing.

currently not working mini pci board

if you ever thought to build your own miniPCI card

From this bad experience i also understand that the PCI bus specifiction requires appropriate electrical signals for interface logic, so if you want to interface some chip to PCI bus you must use only PCI compliance chips!!!

One solution is to use commercial ASIC PCI bridge. Another is to implement PCI interface with PCI compliance programmable logic chip. For additional information about PCI interfaces look at PLD vendors site.

So the conclusion is: if you don't need high transfer data rate use serial or parallel port, or USB bus.

an idea to install openWrt

Setup instructions

USB flash drive or hard disk that is able to be powered from the board's USB port.

tftp server installed on your workstation.

Preparation

The following instructions assume that /dev/sdb corresponds to the USB disk when it is plugged into your workstation. If this is not the case in your setup, please be careful to substitute the correct device name in all commands where appropriate.

Build an image using "routerstationpro" as the MACHINE. For example, you can build core-image-minimal.
Partition the USB drive so that primary partition 1 is type Linux (83). Minimum size depends on your root image size - core-image-minimal probably only needs 8-16MB, while other images will need more.# fdisk /dev/sdb
Command (m for help): pDisk /dev/sdb: 4011 MB, 4011491328 bytes
124 heads, 62 sectors/track, 1019 cylinders, total 7834944 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009e87dDevice Boot Start End Blocks Id System
/dev/sdb1 62 1952751 976345 83 Linux
Format partition 1 on the USB as ext3# mke2fs -j /dev/sdb1
Mount partition 1 and then extract the contents of tmp/deploy/images/core-image-XXXX.tar.bz2 into it (preserving permissions).# mount /dev/sdb1 /media/sdb1
# cd /media/sdb1
# tar -xvjpf tmp/deploy/images/core-image-XXXX.tar.bz2
Unmount the USB drive and then plug it into the board's USB port
Connect the board's serial port to your workstation and then start up your favourite serial terminal so that you will be able to interact with the serial console. If you don't have a favourite, picocom is suggested:$ picocom /dev/ttyUSB0 -b 115200
Connect the network into eth0 (the one that is NOT the 3 port switch). If you are using power-over-ethernet then the board will power up at this point.
Start up the board, watch the serial console. Hit Ctrl+C to abort the autostart if the board is configured that way (it is by default). The bootloader's fconfig command can be used to disable autostart and configure the IP settings if you need to change them (default IP is 192.168.1.20).
Make the kernel (tmp/deploy/images/vmlinux-routerstationpro.bin) available on the tftp server.
If you are going to write the kernel to flash, remove the current kernel and rootfs flash partitions. You can list the partitions using the following bootloader command:RedBoot> fis list
You can delete the existing kernel and rootfs with these commands:RedBoot> fis delete kernel
RedBoot> fis delete rootfs

NOTE: Specifying the command line with -c is important as linux-yocto does not provide a default command line.

NOTE:
you MUST declare board=UBNT-RSPRO, case the kernel needs this information to enable specific hw initialization, if you do not provide board=UBNT-RSPRO the kernel will consider "generic" profile (no usb, no ethernet, etc)

Writing a Kernel to Flash

Go to your tftp server and gzip the kernel you want in flash. It should halve the size.

Load the kernel using the following bootloader command:

RedBoot> load -r -b 0x80600000 -m tftp -h kernel-ubiquiti.bin.gz

This command should output something similar to the following:Raw file loaded 0x80600000-0x8087c537, assumed entry at 0x80600000

Calculate the length by subtracting the first number from the second number and then rounding the result up to the nearest 0x1000.

Using the length calculated above, create a flash partition for the kernel

RedBoot> fis create -b 0x80600000 -l 0x240000 kernel

NOTE: Change 0x240000 to your rounded length and change "kernel" to whatever you want to name your kernel

Booting a Kernel from Flash

To boot the flashed kernel perform the following steps.

At the bootloader prompt, load the kernel

RedBoot> fis load -d -e kernel

NOTE: Change the name "kernel" above if you chose something different earlier. Also, -e means 'elf' and -d means 'decompress'.

Execute the kernel using the exec command as above.

Automating the Boot Process

After writing the kernel to flash and testing the load and exec commands manually, you can automate the boot process with a boot script.

RedBoot> fconfig

NOTE: Answer the questions not specified here as they pertain to your environment.