Olimex TERES-I Review

May. 9, 2024 [technology] [hardware] [libre]

An outfit in Bulgaria design and produce single board computers, microcontrollers and DIY laptop kits sold as TERES-I. I’d found so much success with other open source hardware that this kit was a must try. I really wanted to like it but there are some glaring issues.

Olimex’s TERES I is an AllWinner A64 ARM (Cortex-A53) device with non-socketed 2GB DDR3L memory and 16GB eMMC internal storage. It drives a low resoltion display at 1366x768. That places it just at the threshold of what I would consider to be a performant computer for a traveling laptop and Navit navigation solution.

Before diving into the problems with TERES-I, there are qualities to appreciate. These are some of few open source hardware computers to be manufactured outside of China, for those who care about such a thing. Final assembly is on the end user since these are sold only as kits. The keyboard is void of any Windows key, instead opting for a generic “Tux” emblem. The whole laptop is incredibly simple and lightweight, measuring at 14" corner to corner, placing it into the netbook form factor that I miss so dearly.

Being ARM based, it is not subject to many of the speculative execution exploits plaguing the x86 family. TERES-I is also quite affordable. Especially when the landscape of open source hardware often sees devices which command price tags far above what their proprietary competition are asking. And, unlike LibreBoot Thinkpads, it is not some reverse engineered device long since EOL’d by the original manufacturer sporting chips designed and fabricated almost two decades ago. Relatively modern components yield it a small, fanless device with decent battery life. Lastly, it is possible to use without installing non-free firmware or drivers. At least according to check-dfsg-status.

However, there are some show stopping usability issues which prevent me from treating Olimex’s device as anything other than a curiosity. First and foremost is the storage and bootstrapping situation. I could have gotten by on the 16GB internal storage but, in order to boot from any OS installed on the eMMC storage, one must follow a convoluted procedure in which you power on the laptop with a bootable microSD card installed. After reaching the U-Boot splash, one must physically remove the microSD at just the right moment, causing the laptop to boot properly into the internal storage instead. Failing this, one will only be met with a blank display.

Additionaly, full disk encryption is impractical unless one builds their own image and, even then, AllWinner chips’ weak cryptographic performance translates to a slow system. The encrypted LUKS LVM provisioning in Debian fails to boot once installed, even when using the above workaround.

Speaking of the Debian installer, it is possible to provision and install debian using the usual whiptail installer, but it must be built in a special way. For those who would like to try this for themselves;

Obtain the images:

wget --https-only https://deb.debian.org/debian/dists/stable/main/installer-arm64/current/images/netboot/SD-card-images/firmware.teres_i.img.gz
wget --https-only https://deb.debian.org/debian/dists/stable/main/installer-arm64/current/images/netboot/SD-card-images/partition.img.gz

Combine the two into a single image:

zcat firmware.teres_i.img.gz partition.img.gz > complete_image.img

Then write the image to microSD card:

sudo dd bs=4M status=progress oflag=sync if=/path/to/complete_image.img of=/dev/sdX

This will create a bootable microSD card that loads the conventional Debian installer from which to install directly to eMMC storage. In my testing, even without using full disk encryption, one is still required to use the above workaround to boot without hanging at a blank display.

It is also possible to transfer an already working image, such as the one supplied by Armbian, from a microSD card to internal eMMC through the use of a script supplied by Olimex. I had a devil of a time locating the script, so here it is along with my copy in case Microsoft ShitHub fahrenheits’ it. Simply boot into the working image you desire to install to internal storage and run the script from within that session. It worked some of the time during my testing.

All of this, plus the limited 16GB capacity, kills any desire to install to internal storage. So that left me with considering a microSD card solution which at least could afford more storage capacity. But the issue remains of how easily an adversary could just detach the card thus gaining access to all your data unencrypted. One could opt to encrypt the home directory or individual files but this is incomplete and cumbersome. I am simply not comfortable with anything other than internally installed, LUKS encrypted storage.

I suppose that one could make use of this design failure as plausible deniability, wherein your TERES-I boots by default to a dummy operating system that is innocent looking and unencrypted (to satisfy border checkpoints, airport “security”, etc) while the obscure boot-to-eMMC workaround procecure is used to access your real OS and data. That would be nice were it not for all the other issues.

TERES-I cannot comfortably be used as a Navit GPS since it currently does not have working audio under any distro that I’ve tried. It is still awaiting a patch. Armbian even mention this in their errata as a known issue with no known workaround. I’d attempted the pavucontrol configuration documented at Debian’s wiki but pipewire with pipewire-pulse refuses to recognize the audio device. One could maybe live with an external USB sound device consuming one of the two USB ports.

Speaking of consuming USB ports, TERES-I does not have any ethernet ports. So during your operating system installation, you’re either going to need to settle for wifi (if it works) or to have a USB to RJ-45 adapter handy. My house is a wireless-free home (my area doesn’t even have cellular signal which is awesome and I hope they never build a tower) so everything is connected physically. An adapter works well enough, although it is just another thing to tote around.

The AC power adapter is made for European style outlets, since this is a product of Bulgaria after all, so those of us living with type A outlets need an adapter head. The head supplied with the power adapter adds another inch to an already tall wall wart and makes it unwieldy for travel. I suppose with some effort, one could make a DIY cord that hangs out of the other end of the power brick but that’s a lot of effort for an already very needy laptop.

And can the power brick be replaced with one of the correct voltage and amperage? Maybe, although the OEM power adapter has a LED integrated which indicates whether the device is charging or fully charged. I’m not sure if there is some interplay that would prevent a generic AC adapter from stopping once it “knows” that the battery is charged.

Even though Olimex bill this laptop as upgradeable, there have been no upgrades produced in the six or so years that TERES-I has been available. This normally wouldn’t be an issue, but with the hardware specifications teetering on the edge of usability, I find it difficult to throw in for the long haul on a device that can just about run a full desktop environment and web browser. This is not to say anything about my intentions for it to run Navit which can be memory intensive.

And there are the miscellaneous things. It is still ARM. One must contend with the presence of an unmitigated ARM Trustzone. I am not among those who would consider Trustzone any less of a black box than Intel’s ME. It boots to the microSD card slot by default. There is no option for selecting boot order within U-Boot (unless one wants to build and flash their own U-Boot). Documentation is sparse. It took me embarrasingly long to discover that the power button works more like those found on mobile devices than on conventional laptops, needing to be held for a few seconds to power on or off.

Only so many distributions support the device. A list can be found at linux-sunxi, most of which seem to be treated as an afterthought, harboring their own issues and varying states of being unmaintained. Even the official image supplied by Olimex is basically abandoned. Just have a glance;

Debian: Rarely works due to trying to be “one image for all arm64 devices”
Redpill: Seems to be an abandonware, doesn’t work anymore
ArchLinux: Image developed during porting for parabola linux, abandoned due to upstream incompetence
GNU Guix: Patch for an official support, never merged, Patch submitted, but ignored by distro
NixOS: In development..
Alpine: Was fully supported, but maintainer was inactive, now awaits linux kernel optimizations
Ubuntu: Fully supported through the armbian framework (i.e. just kick the can down to Armbian)

Abysmal. And I gather that this is a problem plaguing many ARM family and single board computer systems. Many need to have their own custom images built.

I want to like the TERES-I, I really do. But it is very much in a development state. Maybe a TERES-II or an upgrade to the existing framework could elevate Olimex’s kit to a status of general usability. My intuition also tells me that if they sold them pre-assembled that there would be more buyers. The landscape for open hardware laptops is already slim pickings and I hope that they can move forward on this design.

The netbook that I’m currently using is getting long in the tooth. It cannot be upgraded beyond Debian Stretch, so it is living in a state of limbo as an offline-only airgapped car GPS and portable audio player with no prospects to return to running SIP telephony, web or email. And so my hunt for a suitable replacement continues.