The OLinuXino-MICRO has 256MB RAM and a 1GHz Neon-enabled Cortex A8 core. This makes it much more attractive than the iMX233-based boards, especially when CryptoSign signature verifications in Rhizome are considered.

The board has a real UART interface that we can use to talk to the RFD900 radio directly.

These have a single USB port which can be used to connect to a low-power 3.3v USB-based ATH9K Wi-Fi module to do AP+Ad-Hoc Wi-Fi, albiet @ only +13dB – +17dB (I forget the exact figure). We have found a cheap source of those modules on AliExpress for about US$6 in small quantities.

The biggest pain at the moment is building a kernel with atk9k support included. The given instructions for building the kernel don't work because some important patch hasn't made its way into the arm linux kernel source distributions.

(The OLinuXino A13 regular and Wi-Fi versions of the board don't have this problem with building kernels. But they are more expensive, larger, use more power, and the Wi-Fi version uses a realtec Wi-Fi, not the ath9k chipset that we know works so well.)

It seems that this can be remedied by following the information in

The important bit seems to be creating arch/arm/configs/a13om_defconfig with the right contents, and using that to configure the kernel build process. The right contents may be the content of

Of course, these things are based on particular versions of the linux kernel, so need to be matched.

More on this if and when I succeed.

Building a system with ath9k support

First, build a kernel with ath9k support:

  1. Make sure you have everything you need to build an ARM linux kernel: apt-get install gcc-4.6-arm-linux-gnueabi ncurses-dev uboot-mkimage build-essential git
  2. cd linux-sunxi
  3. make ARCH=arm a13om_defconfig
  4. vi .config and make sure the following are present, editing as required:


  1. replace #include <mach/gpio.h> with #include <linux/gpio.h> in drivers/spi/spi_sunxi.c
  2. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage (you might be asked to answer some config questions, just keep hitting enter until it builds).
  3. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=out modules_install

Then copy the kernel into the uboot partition on the microSD card for the OLinuXino board. This partition is partition 1, and is VFAT, even though the partition type is marked “Linux” (partition type 83). Just mount it manually, copy the file on, and unmount it again.

You will also need to copy the ath.ko & ath9k*.ko kernel modules into /lib/modules/3.0.76+/

Finally, copy the htc_9271.fw file into /lib/firmware in the main partition. You can download it with something like:

I have noticed some problems with the interface not being enabled if the ath9k module is plugged in when the board boots. Remove and re-insert it, and it gets detected fine.

Similarly, I have seen the firmware file get zeroed out on boot if the permissions are not read-only, so make sure to chmod 400 /lib/firmware/htc_9271.fw before rebooting for the first time.

Then make /etc/init.d/ath9k with the following contents:

<verbatim>cd /lib/modules/3.0.76+ insmod ath.ko insmod ath9k_hw.ko insmod ath9k_common.ko insmod ath9k_htc.ko </verbatim>

And don't forget to chmod it: chmod 755 /etc/init.d/ath9k

Then add /etc/init.d/ath9k to the end of /etc/rc.local

wlan0 will then be available on boot.

This is not the right way to do things, but it is sufficient for now for our prototyping activities.

Wireless functionality can be tested with command-line stuff, e.g., as described in

I used that to connect to my home Wi-Fi and install the debian package for iw and hostapd which were not included on the base debian distribution: apt-get install iw hostapd

Configuring AP+ad-hoc Wi-Fi

The ath9k_htc driver requires patching to support simultaneous AP+adhoc mode, and this combination is not officially supported. However, it does appear to work, with the caveat that it will only beacon the AP, not the ad-hoc cell. That's mostly a bonus, as we don't waste airtime on ad-hoc beacons.

First, you need to install hostapd: apt-get install hostapd (see previous discussion for getting Wi-Fi into client mode for easy downloading if required).

Then put something like the following in /etc/init.d/ath9k to get both simultaneous ap+adhoc (order of commands and order of raising interfaces seems to be important, but further exploration is required to confirm):

cd /lib/modules/3.0.76+
insmod ath.ko
insmod ath9k_hw.ko 
insmod ath9k_common.ko 
insmod ath9k_htc.ko 
# allow wifi module to get loaded.
sleep 3

# delete the default interface setup on load
iw dev wlan0 del
iw dev wlan1 del
iw dev wlan2 del
iw dev wlan3 del
ifconfig monitor0 down
ifconfig adhoc0 down
ifconfig public0 down
iw dev monitor0 del
iw dev adhoc0 del
iw dev public0 del

# setup ap vif for clients to connect to
iw dev public0 del
iw phy phy0 interface add public0 type __ap
hostapd -B /etc/hostapd/hostapd.conf
# must change mac address of either adhoc or ap to prevent "name not unique"
# order of commands seems important.
ifconfig public0 netmask up
ifconfig public0 down hw ether 10:48:7a:88:c0:11 up

# setup ad-hoc vif
# this requires a patched ath9k_htc that supports simultaneous AP+IBSS.
# see
# for details on the patch.
iw dev adhoc0 del
iw phy phy0 interface add adhoc0 type adhoc
ifconfig adhoc0 netmask up
# 2437 = ch6, must match /etc/hostapd/hostapd.conf
iw dev adhoc0 ibss join 2437 02:ca:ff:dd:ca:ce

Then create /etc/hostapd/hostapd.conf with the following:


Reboot, and viola!, you should have AP+ad-hoc mode. This was tested to be able to ssh into one of our existing Mesh Extender units, confirming that arp and unicast traffic is fine.

This will only work if you have applied the patch contained in:

before building your ath9k_htc.ko

Note that the ath9k driver MUST be a module, and not compiled into the kernel, else it will not be able to load the firmware, and you won't be able to use the device. It also makes the boot process pause for a minute if you try.

Useful Resources Documenting Problems With Kernel Builds

Rebooting without removing power supply causes kernel to get stuck, or uboot process to get stuck or something, after detecting the UART:

NULL pointer dereference in the kernel. This seems to be due to using OLinuXino A13 kernel config on an OLinuXino-MICRO A13 board: Suggests getting kernel source from instead of the official place, so that the MICRO board config is available. The official word from Olimex on building the kernel for the OLinuXino-MICRO A13 is in the following, confirming that you must use the above git repository instead of the “normal” one:

It is possible to get errors with undeclared gpio access functions when building the kernel, such as documented in: It might work to replace #include <mach/gpio.h> with #include <linux/gpio.h> in drivers/spi/spi_sunxi.c