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 https://www.olimex.com/forum/index.php?topic=790.0
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 https://github.com/iso9660/olinuxino-A13-micro/blob/master/a13_olimex_micro_defconfig
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.
First, build a kernel with ath9k support:
apt-get install gcc-4.6-arm-linux-gnueabi ncurses-dev uboot-mkimage build-essential git
make ARCH=arm a13om_defconfig
vi .configand make sure the following are present, editing as required:
<verbatim>CONFIG_ATH9K_HW=m CONFIG_ATH9K_COMMON=m CONFIG_ATH9K=m CONFIG_ATH9K_AHB=m CONFIG_ATH9K_RATE_CONTROL=m CONFIG_ATH9K_HTC=m</verbatim>
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).
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
ath9k*.ko kernel modules into
Finally, copy the
htc_9271.fw file into
/lib/firmware in the main partition. You can download it with something like:
wget -O htc_9271.fw http://wireless.kernel.org/download/htc_fw/1.3/htc_9271.fw
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.
/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
/etc/init.d/ath9k to the end of
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 http://linux.icydog.net/wpa.php
I used that to connect to my home Wi-Fi and install the debian package for
hostapd which were not included on the base debian distribution:
apt-get install iw hostapd
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):
#!/bin/sh 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 192.168.100.1 netmask 255.255.255.0 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 http://comments.gmane.org/gmane.linux.kernel.wireless.general/96547 # for details on the patch. iw dev adhoc0 del iw phy phy0 interface add adhoc0 type adhoc ifconfig adhoc0 126.96.36.199 netmask 254.0.0.0 up # 2437 = ch6, must match /etc/hostapd/hostapd.conf iw dev adhoc0 ibss join mesh.servalproject.org 2437 02:ca:ff:dd:ca:ce
/etc/hostapd/hostapd.conf with the following:
driver=nl80211 interface=public0 max_num_sta=255 ssid=public.servalproject.org hw_mode=g channel=6 ieee80211n=1 ht_capab=[HT40-][SHORT-GI-40][DSSS_CCK-40]
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.
Rebooting without removing power supply causes kernel to get stuck, or uboot process to get stuck or something, after detecting the UART: https://github.com/linux-sunxi/linux-sunxi/issues/118
NULL pointer dereference in the kernel. This seems to be due to using OLinuXino A13 kernel config on an OLinuXino-MICRO A13 board: https://www.olimex.com/forum/index.php?topic=617.0 Suggests getting kernel source from https://github.com/hehopmajieh/linux-sunxi 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: https://www.olimex.com/forum/index.php?topic=707.0
It is possible to get errors with undeclared gpio access functions when building the kernel, such as documented in: https://github.com/linux-sunxi/linux-sunxi/issues/136 It might work to replace #include <mach/gpio.h> with #include <linux/gpio.h> in drivers/spi/spi_sunxi.c