About the Olimex A64-Olinuxino

Back in June 2019, I bought three Olimex A64-Olinuxino boards, which I'm using for testing and demos of networking protocols.

Summary

Features:

Caveats:

Buying the boards

The boards can be bought on Olimex' website. There are multiple variants, you'll probably want one with embedded eMMC (faster and more robust than booting off a micro-SD card).

The boards are sold with no bundled accessories. In addition to the boards, you will need at least some of the following:

The USB to serial adapter is not optional: if something goes wrong, you won't be able to debug the issue without it.

Installation

Olimex provide fairly functional Debian images, with an almost stock kernel.

Earlier kernels used to crash when the board would overheat. This is no longer the case with 5.10, which has working thermal management: the kernel will throttle the CPU when it overheats. It is therefore no longer necessary to limit the CPU's clock rate manually.

Usage

CPU

The CPU is a quad-core Cortex-A53; it implements ARMv8.0-A, and Debian runs in 64-bit mode. It is fast enough to do native compiles, but I prefer to cross-compile from a Debian desktop. For C, I use

apt install gcc-aarch64-linux-gnu
make CC=gcc-aarch64-linux-gnu
and for Go,
GOARCH=arm64 go build

This particular build of the Cortex-A53 implements the ARMv8 crypto extensions (everything is an option in the ARM world). This makes the board useful for HTTPS servers and VPNs.

Storage

The on-board eMMC has reasonable performance, and at any rate the board has enough RAM to keep my working set in cache. A reasonable Debian installation takes 800MB of the available 4GB. If for some reason that is not enough, the board has a micro-SD slot that can be used together with the eMMC.

Ethernet

The Ethernet works out of the box, it successfully autonegotiates both Gigabit and 100 Mbit/s (I no longer have access to a 10Mbit/s hub to test against). I get 920 Mbit/s over TCP (iperf between two boards connected to the same switch).

The cards all have the same MAC address. If you have multiple cards, you will need to manually override the MAC address to give each a unique one. If you're using an image dated 29 May 2021 or later, add a line such as the following to /boot/uEnv.text:

ethaddr=02:ba:7b:d5:c6:6f

If you're running an earlier version, you'll need to override the MAC address after boot by adding a hwaddress statement to /etc/interfaces.d/eth0. Or just upgrade your uBoot, apt update, apt upgrade, u-boot-install.)

WiFi

The chip is a RTL8723BS connected over SDIO, with a PCB antenna (there's no external antenna connector). It's a 1×1 2.4GHz-only chip. Either the chip or the Linux driver has some limitations:

Earlier kernels used to have a problem with AP mode. AP mode works fine with 5.10.

BlueTooth

BlueTooth 4.0 (with BLE). It works. I'm getting roughly 2Mbit/s over BNEP, with 20ms latency.

The BlueTooth interface disappears after a reboot (this is still the case with kernel 5.10). You need to physically power-cycle the board in order to recover.

Running on battery

The board runs fine on a 1400mAh toy battery. The PMIC indicates that it's using 800mA when idle; if that's accurate, then the small battery should be enough for a few hours continuous use, which is enough for most demos.

Suprisingly enough, there is an upstep converter on board, so the USB ports work even when on battery.

I/O

Only one UART port is populated, and it is used for the console.

The board has space for three extra headers: one UEXT connector (UART + I²C + SPI + power), HSIC, and one undocumented 40-pin header (but you have the board schematics). Unfortunately, none of these are populated, so using them will require soldering.

(A second populated UART would be handy at times, but not often enough to justify the hassle of soldering a header myself.)

Conclusion

A very useful board if you don't need documentation.