Olimex Teres A64 Review

It's not very often you get to build your own laptop. Doubly-so for a laptop built on open hardware designs, which is exactly the selling point for the Teres A64 from Olimex. However, almost all information available on-line is regarding the actual build process, with nary a hardware review to be found of what you will end up with. This post aims to fill that void.

Teres (Open) Teres (Closed) Teres (Bottom)

Physical Characteristics

I won't spend any specific time discussing the hardware build process itself. There are lots of materials on-line you can find that discuss that particular topic. Instead, let's discuss what you end up with. Obviously there is no metal case to be found at this price-point, but the plastic case provided is rather sturdy, with no obvious flex. The laptop is very lightweight at a mere 1.024 kg, with dimensions of 291 x 197 x 18 mm. It is also completely passively cooled, with not a single fan in sight.

Left-side view Right-side view

The IO complement is pretty standard, with two USB 2.0 ports on either side, a microSD card slot, mini HDMI port, charging plug and a headphone jack. Ethernet and USB 3.x support would be nice, but the former probably wouldn't fit, and the overall performance probably wouldn't benefit from a faster USB bus. We'll get to that later. Not all USB devices work fully with this machine. Bus-powered external hard drives won't be able to draw enough power, and some devices (e.g. XInput controllers) appear to be missing from the Kernel.

If you wish to open the machine back up after assembling it, you will have to deal with 15 screws and four rubber feet, which does not make this a quick-access update. That said, although the hardware board designs are freely available, there's very little you can do with the boards themselves. There is no exposed IO for additional expansion, or any option to add internal storage. Short of building replacement boards for what is inside, the only real customization is to update the keyboard firmware, which can be performed without opening the device at all.

Connectivity-wise, this machine supports the usual Bluetooth and Wifi, though only Bluetooth 4.0 and 802.11n, 2.4 GHz bands, respectively. Unfortunately, in any modern Condo or Apartment building, 2.4 GHz Wifi is quite poor due to the large amount of interference. To confirm exactly how bad the interference situation is, I used iperf between my desktop and the Teres to capture transfer speeds in a couple locations around my Condo. I captured a minimum of three samples in each location, with more samples in the Kitchen, Top of Desk and Under Desk regions. The results are as follows:

Wifi performance

The only strange part of these results is that the kitchen consistently outperformed the "Under Desk" statistic, since the wireless router is also under the desk. I guess the kitchen is in a more ideal location due to the signal characteristics, but this is outside my area of knowledge. Regardless, the performance at my home is quite poor and can be expected in any similar environment.

Display

The LCD display on this laptop operates at a 1366x768 resolution, and is a twisted nematic (TN) display. As typical with this display type, the colors reproduction is reasonable, though very poor when viewed at an angle. This is as expected for a laptop in this price range, though slightly disappointing regardless. For general, direct use, however, it's fine and probably won't be noticed in most circumstances.

The external display use on this machine is a bit quirky, however. The first, most obvious complaint is that xrandr support is nowhere to be found. This means that all typical desktop environment multi-monitor controls will not work. Instead, at least with the latest (16.04-based) image, the external monitor is simply enabled by default, even if not connected. This means you can drag a cursor/window off-screen and not necessarily know where to find it. Once an HDMI screen is hooked up (1080p only!), it will show up as expected.

If you wish to disable the "phantom" external HDMI display, you will need to download a script from the github page. It's unclear why this is not part of the image, but it allows switching whether the external HDMI display is enabled or not (e.g. to only use the LCD panel). However, it will not allow disabling the LCD panel to only use the external display. Without xrandr support, there is also no means to specify the external display is "primary", so games/videos/etc will usually default to using the LCD panel.

Keyboard/Touchpad

Keyboard profile view Keycap removed to show mechanism

The keyboard is a fairly typical laptop layout, with average, low-profile keys like just about any other laptop out there. Pulling off a key-cap reveals that it uses a plastic scissoring mechanism over a rubber dome. I don't recommend actually removing key-caps, however, as it's quite easy to screw up the scissor mechanism. It required quite a bit of fiddling before I was able to properly fit my test key back onto the board.

Because this is a 11" laptop, and there is an additional gap on each side of the keyboard, it uses a reduced key spacing. Standard spacing is about 18.5 mm between keys. This laptop uses 16.5mm (\~90%), which is noticeably cramped. This is entirely down to personal preference how much it will affect you; I really don't like it. Additionally, I did notice the occasional dropped key when typing quickly, though it may be possible to fix this with better keyboard firmware. The firmware source code is freely available, and the controller is an Atmega 32U4, so you can build and load your own updates.

Having a Tux key is pretty cool too.

The touch-pad is a little small at 74 x 43 mm, but is otherwise fairly standard. It is responsive and does not accidentally trigger when typing. Dual-finger motions activate scrolling as expected. The buttons do provide a satisfying click, though I found them a bit too stiff for my preference.

Sound

Initial speaker impressions are decent. The laptop speakers are fairly clear, though of course limited by their size. There are some odd noises now and again, but research shows that is due to the serial port turning on or off.

The first time you attempt to use the headphone jack, however, may be a bit of an unwelcome surprise. I noticed some serious background noise when I was on the initial image. After a re-install I did not hear any output at all. Although the serial port is supposed to be able to share the headphone jack and only become active when needed, I found it was causing problems in all circumstances. Thankfully, it can be disabled by using the following command:

$ sudo debug_switch.sh off

Finding this was a bit of a challenge, however. It appears in the github page for the debug cable, but not for the Laptop itself.

With that fixed, I did some audio recordings of the same audio file on the Sound Blaster AWE64 on my retro-PC, the onboard audio on my main PC, and the Teres A64. I recorded with a line cable connected to a Zoom H1 Handy Recorder. I performed a spectrum analysis of both the recorded portion, as well as any noise recorded prior to the sound itself. I attempted to set to a similar volume on each machine, though there are some variations in the resulting output. See below for the results:

Sound response comparison

The first point is that my recording setup is obviously not as good as it could be. I recorded at 96 kHz, but most details above 10 kHz appeared lost, as well as some visible differences in the \~2000 to \~7000 kHz ranges between the original and any recordings. I'm no audio engineer, so this may very well be expected, or I might just need a better recording device.

Disregarding that, the recordings do show a very similar spectrum for the playback signals of all three sources, so the Teres does not appear do anything abnormal for standard audio playback. The noise levels are also quite well captured, with the Teres falling in reasonably close to my desktop PC, and well below the Retro PC. The AWE64 may have been great in '96; not so much now. In all, the Teres will provide a good listening experience, once you disable that pesky serial debug capability.

Camera

The laptop also has a camera. That's about the best I can say about it. It's a 640x480 VGA camera that may as well have come out of the mid-2000s. If you need to be capable of video chat: congrats, you are! If you wanted more than that, look elsewhere. Here are a pair of sample photos:

Yarn Yoshi, a Koopa Paratroopa and a Cheese Grater The view from my balcony

I felt a bit silly while holding up a laptop on my balcony to get a photo.

Battery

I'm going to be completely honest: I didn't do any real battery testing. It's 9500 mAh, running an ARM processor, so it will probably last for as long as you need it. I can't imagine the exact battery life is going to be a deciding factor for anyone interested in this particular laptop.

Performance

If you were expecting any serious performance from this machine, you are looking at the wrong laptop. It's ARM. It's an evaluation board in a laptop case. It isn't even close to an average mass-market laptop with recent components.

That said, as long as you stay away from Gnome or KDE, and keep your open-source gaming to the old-school variety, it should meet your needs. Mostly. Probably. Let's get some real numbers and you can decide for yourself. I'm going to compare this to five machines: a Raspberry Pi A, a Raspberry Pi 3, a Pentium 3-450, an Intel i5-5450S and a chroot config on a Galaxy Tab S2.

These machines are a rather diverse lot, so I'm going to try to keep things similar whenever possible. Any variations or special cases will be noted. In particular, the Tablet isn't compatible with any of the graphical tests. Kernel versions and Distros for the modern machines are as follows:

The Pentium 3 needs a bit of special care, however, since it has a 3DFX Voodoo 3 and X11 and Mesa acceleration support for this card has slowly vanished over the years. I will actually use three different versions of Debian on this machine to get reasonable hardware support. They are, in release order:

The exact version used will be mentioned in the benchmarks below.

7zip CPU Benchmarks

First up: CPU benchmarks. I will be using 7-zip in Benchmark mode for this purpose, as it takes advantage of multi-threading, and can be run on all machines - to an extent. The larger dictionary sizes require more ram than the Pentium 3 or the Pi A have available, so I will be using a dictionary size of 23. Additionally, the Teres will be running on 7-Zip version 9.20 while the remaining run 16.02. This is strictly due to what is available in the repository; the results do not seem unduly influenced by this difference.

The Pentium 3 is running Debian 9 for this benchmark. The results follow:

7-zip benchmarks

The first two categories are compression speed, while the second two are decompression speed. The /U categories are the MIPS ratings normalized by CPU usage, which effectively demonstrates the single-core performance. Note that the above chart is plotted on a logarithmic scale, due to the vast performance gap between some CPUs.

A simple conclusion can be drawn from this data: in raw compute power, the Teres A64 is roughly similar to a Raspberry Pi 3, albeit a little bit behind. Both trounce the two slower machines, but are in turn trounced by the modern CPU and by the Android Tablet. The tablet has an advantage in multi-threading by having 8 cores; the single threaded performance appears only slight better than the other ARM boards. Only in the decompression statistic does the multi-threaded performance of the Pi 3 & Teres match the single-threaded performance of the i5.

GLMark2

Most ARM-based solutions are focused towards OpenGLES, so I grabbed GLMark2 to do some benchmarking with this standards. This was compiled and run on three machines: The Pi 3, the Teres and the i5-3450S. I was unable to run this benchmark on the Pentium 3 on any configuration, and I was also unable to get any accelerated output from the Raspberry Pi A. I also was unable to find an Android build of this benchmark and the chroot does not allow accelerated video.

In the case of the Raspberry Pi 3, I ran into a peculiar problem: although the Broadcom drivers are provided in the /opt/vc folder structure, the benchmark simply raised a segmentation fault when I attempted to use them. The Pi 3 therefore has two benchmarks: whatever (assumed software) output it generates by default, and with the Beta OpenGL driver. The rather large result set is as follows:

GLMark2 benchmarks

Again, this is presented in a logarithmic chart, as the NVIDIA results are several orders of magnitude beyond the ARM machines.

The Teres results are... okay. The performance appears similar to what I would expect from software rasterization,although glxinfo does indicate the presence of acceleration. If something like DOSBox is used in GL mode, the scaling has a noticeable performance hit. The Pi without beta drivers is even worse, with lots of flashing images and odd glitches, so that's not a config anyone should be using. In comparison, the Teres is totally fine, even if the performance doesn't match what true acceleration should be providing.

GLXGears

GLXGears is somewhat of a tradition in Linux benchmarking, even though it's largely useless for testing modern card capabilities. That said, this is the only accelerated graphical benchmark I was able to run on almost every machine. The two machines missing out are the Pi A, due the previous video issues, and the tablet for obvious reasons. Ironically, there is a native Android build of Gears, but it runs at a locked 60 fps.

GLXGears benchmark

Results follow basically the same trends as the previous benchmarks, with the addition of the Pentium 3. The Pentium 3 is rather close to the Teres in performance when it can properly use the Voodoo 3. The 'SW' results from the Pentium 3 were obtained on Debian 6, while the 'V3' results were obtained on Debian 3.1. No results are available for Debian 9 from the P3, as GLXGears failed to run in that configuration.

DOOM

While we're on the topic of outdated benchmarks, let's throw some DOOM into the fray. Doom hasn't been a serious benchmarking tool in years, but Chocolate Doom still supports the timedemo feature. A laptop isn't worth very much if you can't use it to play DOOM either.

Using a software renderer, this is nominally a CPU benchmark, with some additional factors based on the full output window resolution and how quickly SDL can access the video buffer. It's almost certainly bound by other constraints, but this can provide a general guidance on just how much DOOM you can get from each machine. I also threw in a DOS Doom timedemo for a comparison of how fast the game can be when nothing is in the way.

When possible, DOOM was configured to run at a canvas size of 960x720, which is the size used to get full-screen on the Teres. The initial run on the P3-450 running Chocolate Doom was at 640x480, which is also included for comparison.

Doom benchmarks

A Pentium 3 is overkill for DOS Doom, so it's no surprise that runs well. Chocolate Doom runs at a playable 25.7 fps at 640x480 on the same PC, with a humbling 12.5 fps at the target resolution. That machine may also be held back by the lack of video acceleration, since the tests were run on Debian 9. Even so, the Pi A performed the worst of the bunch, at 7.8 FPS, which reminds of me of playing on my 386. The Teres reaches a strangely underwhelming 25.4 FPS, which is utterly creamed by the 71.8 FPS output by the Pi 3. I have no explanation given the relative parity of 7zip results.

Storage Performance

Disk benchmarks were captured on all machines using my benchmarking script. In addition to the built-in eMMC storage, I also benchmarked the microSD slot using a rather fast 16 GB U3 Samsung Extreme Plus microSD card I normally use for my GoPro. I used the same card in the Raspberry Pi benchmarks. A baseline benchmark is included with a USB 3 card reader to gauge the potential of the card itself. For the Pentium 3, I simply benchmarked its internal IDE drive as a comparison. I also included the internal flash memory of my Android tablet to get a better idea of a modern, commercial ARM product.

Disk read performance Disk write performance

In short, the Teres and both Pis are seriously held back by their SD interface. The card reader and all results from the tablet soar above what those machines are capable of. Excluding the tablet and USB card reader, all other read results are fairly similar, with the Teres built-in eMMC essentially the same as the microSD, though the IDE bus pulls ahead of them. On write performance the eMMC does fall behind the better microSD card, with both Pis and the Teres performing about the same. The microSD also pulls ahead of the IDE HDD, which is nice.

In conclusion, don't expect much from disk performance, and don't bother spending extra on a faster microSD card. As long as you can reach the \~20 MB/s write performance with a U1 card or a faster Class 10, you should be fine using just about anything to expand your storage.

Software

The laptop comes pre-installed with Ubuntu MATE, 16.04 LTS (Xenial Xerus), which works fine as a starting point. The original image bundled with the machine was pre-configured with a Teres wallpaper and the Arduino IDE. This change notwithstanding, there are no other notable deviations from a standard Ubuntu MATE setup. The latest image on the Teres web-site is even more traditional, with the default Ubuntu MATE background as well.

When attempting to customize the machine, I noticed is that the "MATE Menu" panel item would not function if I attempted to add it. It did not even display an icon in the chooser. I'm not sure if this is specific to the Teres, the ARM64 package in general, or if the MATE Menu package was broken for this version of Ubuntu. I'm not normally a MATE user, so I'm not familiar with its quirks.

Since it's Ubuntu, it's easy to switch to another desktop using apt if you aren't a MATE fan. I quickly migrated over to Xfce for my use, which ran quite reliably on this laptop and provided my usual, comfortable environment.

There are a couple packages specific to the hardware that are pre-installed. First is teres1-audioselect, which contains a utility and systemd unit to select the headphone jack mode between audio and serial port. Second, teres1-ledctrl, which contains a simple daemon and systemd unit to properly sequence the keyboard LEDs. Finally, There is teres-bluethooth (sic) package, which contains some bluetooth utilities and a systemd unit to provide support.

A few other scripts show up in the /usr/local folder structure that aren't part of a package, though most appear related to installation. Aside from the debug_switch.sh script mentioned in the Sound section, there is an a64_health.sh script, a script to install the arduino_ide, and a few scripts to perform an install to eMMC if booted from microSD. The a64_health.sh script prints the current CPU state, temperature, cooling mode and battery percentage.

These utilities are rather under-documented (even on the github page), so some trial-and-error (or source code browsing) may be in order. Those that can be executed by hand (e.g. audio select) do not have manual pages or respond to the --help argument.

Additional scripts appear to be available at the github page for other features, such as the HDMI switching script mentioned earlier.

Compatibility

The first and obvious source of software to run on the Teres A64 is the Ubuntu repositories. These should cover most use cases, especially considering the wide variety of open source software available nowadays. If you wish to branch out from the repos, the best option for compatibility is, of course, software that can run on any architecture (e.g. Java, Python, etc). However, be careful running some Java software, as there may be platform-native libraries involved, which will not operate. Finally, any software distributed in source code that doesn't happen to be in the repositories should be build-able using its documented build process.

Binaries for other ARM variants (armhf and armel) can also be executed, though some setup is needed. The initial image on the laptop included the armhf architecture, though this was not the case when I installed from the latest image. Attempting to run a binary with missing architecture configuration may result in the confusing error message 'No such file or directory'. If this happens to you, run the file command on the binary to confirm its architecture, then use dpkg --print-foreign-architectures to confirm what is installed. To add the armhf architectures and minimal libraries to run applications, execute the following commands as root/with sudo:

# dpkg --add-architecture armhf
# apt update
# apt install libc6:armhf

After that, I was able to execute an application compiled on a Raspberry Pi on the Teres. Other arm applications may require additional libraries. Note that the common ldd utility will not work across architectures. To see which libraries a binary uses, execute readelf -d $binary instead.

There aren't nearly as many pre-compiled ARM applications as X86, but there is some non-open source software aimed at the Raspberry Pi. However, some of this software may specifically target the Pi and be incompatible with other ARM processors. The first binary-distributed application I wanted to try was the PICO-8 fantasy console, but the readelf output listed dependencies on libwiringPi.so and libbcm_host.so libraries. The former library is open source, but is targeted specifically to the Pi, so it would require porting. The latter is part of the Broadcom-packaged binary libraries in /opt/vc on a Pi, and contains many symbols related to controlling the display. Suffice to say, providing a replacement is a non-trivial activity. Binaries depending on any such libraries won't be compatible with the Teres.

QEMU emulation for X86 and X86_64

X86/X86_64 applications can indeed be run on an ARM processor, thanks to the wonders of emulation. For old DOS applications, obviously DOSBox is the suggested means (see next section). For everything else, there's QEMU. QEMU can emulate even more processor types, but this will be focusing on X86 and X86_64, referred to below as i386 and amd64 based on their Debian architecture names.

QEMU has two possible modes of operation: system emulation, and userspace emulation. System emulation emulates a full system, i.e. a virtual machine. Userspace emulation allows Linux applications from another architecture to be emulated on-the-fly without running a full system. Both have their advantages and disadvantages. Both, unfortunately will be slow. Before getting into the details, I've run 7zip inside QEMU on both i386 and amd64 to compare against the previously-computed data:

7-zip performance with Emulation

I've removed the i5 from the plot so the performance can be more evenly compared. As expected, it's the slowest performance on the plot, with only the multi-threaded performance of the i386 decompression passing the single-threaded performance of the Pi A and Pentium 3. Looking at some benchmark results from Vogons, this would theoretically put performance around a Pentium 1, but the DOOM benchmarks I performed later suggest more like a 386. Both architectures seem reasonably similar in performance, and would be viable emulation targets. In the amd64 case, however, note that user-space emulation seems to print "warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]" each time a process is launched.

Userspace Emulation

User-space emulation is surprisingly seamless, thanks to the Debian multi-arch configuration, and just requires some minor initial setup. This is slightly more complicated on Ubuntu over base Debian, because the ARM repositories are separate from the main repos. If you have another Ubuntu install, you can copy your mirrors over from the sources.list, ensuring the release name is set to xenial. In my case, I added the Canadian archive repository URLs. You will also need to specify which repositories are to be used with which architectures, or you will get various errors when updating.

deb [arch=armhf,arm64] http://ports.ubuntu.com/ xenial main restricted universe multiverse
deb-src http://ports.ubuntu.com/ xenial main restricted universe multiverse

deb [arch=armhf,arm64] http://ports.ubuntu.com/ xenial-updates main restricted universe multiverse
deb-src http://ports.ubuntu.com/ xenial-updates main restricted universe multiverse

deb [arch=armhf,arm64] http://ports.ubuntu.com/ xenial-security main restricted universe multiverse
deb-src http://ports.ubuntu.com/ xenial-security main restricted universe multiverse

# deb http://ca.archive.ubuntu.com/ xenial-backports main restricted universe multiverse
# deb-src http://ca.archive.ubuntu.com/ xenial-backports main restricted universe multiverse

deb [arch=i386,amd64] http://ca.archive.ubuntu.com/ubuntu/ xenial main restricted universe multiverse
deb-src http://ca.archive.ubuntu.com/ubuntu/  xenial main restricted universe multiverse

deb [arch=i386,amd64] http://ca.archive.ubuntu.com/ubuntu/  xenial-updates main restricted universe multiverse
deb-src http://ca.archive.ubuntu.com/ubuntu/  xenial-updates main restricted universe multiverse

deb [arch=i386,amd64] http://ca.archive.ubuntu.com/ubuntu/  xenial-security main restricted universe multiverse
deb-src http://ca.archive.ubuntu.com/ubuntu/  xenial-security main restricted universe multiverse

If you aren't from Canada, I suggest replacing ca with the nearest country code that hosts a mirror. Next, simply add the architecture(s) to emulate and install QEMU, plus minimally the C libraries from each architecture:

# dpkg --add-architecture i386
# dpkg --add-architecture amd64
# apt update
# apt install libc6:i386 libc6:amd64 qemu

Congratulations! Hello world should now work. Additionally, any Deb-packaged applications should now be installable, with proper dependency resolution from the foreign libraries. Foreign versions of libraries or applications can be installed from the repositories by appending the architecture as a suffix to the apt line. For example:

# apt install wine:i386

Unfortunately, most of my graphical test applications failed. The most common failure mode was to consume CPU for a while, then silently stopping but failing to draw anything. This was the case for Beyond Compare, as well as the i386 version of Qalculate and Escape Goat. Cave Story+ managed to draw a black screen, but failed acquiring a sound device with SDL.

Wine managed to draw the winecfg and explorer.exe applications, but was less successful with running some classic Entertainment Pack games (granted, they are WIN16 apps). Some other attempted Windows applications simply froze per the above, though I didn't test very many.

In all, compatibility is rather poor, with generally better results for terminal applications than anything graphical.

System Emulation

System emulation is both easier and harder to configure, depending on your point of view. Up-front, it doesn't require any apt source modifications; simply install QEMU and, if you like to have a configuration gui, Virtual Machine Manager as follows:

# apt install qemu virt-manager

You will also need to add your user to the libvirtd group for virt-manager use (example for default olimex user):

# usermod olimex -a -G libvirtd

Beyond that, grab an ISO, fire up the Virtual Machine manager, and start defining, then install a virtual machine. Due to performance, I would stick with anything that does not require a fast CPU to be usable. Old versions of Windows (pre-XP), or Distros with low requirements will probably be suitable.

I installed a Windows 98 SE VM to test the process. I did have a few issues during the install that required a force off/power on cycle to continue, though the install did complete. However, after starting the resulting VM, it was missing some key drivers, such as the CD-ROM, which was needed to install anything else. The add hardware wizard would similarly freeze if told to detect non-plug-and-play hardware. The install was performed using essentially the default settings for Virtual Machine Manager (+floppy drive), so manually using qemu-system-i386 with a different machine type may provide a better experience. Alternatively, preparing the VM on a faster machine then copying will likely be faster and easier.

Although QEMU supports multiple video output modes, only VNC and SDL are supported by the build available in the Ubuntu repositories. Other builds could provide GTK or SPICE, which may be available in other distro options described later. In the default distro, virt-manager will only use VNC, while SDL can be accomplished using the QEMU command line. On my Windows 98 VM, both are very slow, though the SDL is slightly improved when I benchmarked it (see performance section later). To get a general idea of how the Windows VM runs, here's a video I recorded in SDL mode:

DOSBox

As mentioned briefly above, DOSBox is another option for running old X86 applications, specifically of the DOS variety. Unfortunately, DOSBox has to work extra hard on an ARM machine, as some of the higher performance modes on a typical X86 desktop do not work. Due to the OpenGL issues, you'll also be stuck with a fixed scaling output (2x or 3x, typically), which limits the options somewhat. With the repository version of DOSBox, I wasn't really able to push much beyond the default 3000 cycles without running into sound issues and/or dropped frames. This would put the machine somewhere around 1992 in terms of what can be run. To go faster, you will need to compile an SVN version yourself. How much of an improvement, you ask? And how does it compare to QEMU? Well, that's what the next section is for.

Emulation Performance and Recommendations

So, you probably gathered by now that all PC emulation options are slow. This section aims to provide some numbers to that statement.

That's right, it's time for more DOOM. I am going to attempt to quantify the affect of the multiple emulation options, as well as alternate video modes and/or disabling sound. Note that I was unable to successfully get sound working with QEMU running DOOM in DOS, so those results should probably be compared against the "DOSBox No Sound" statistic to get a comparable result.

Also note that DOSBox "overlay" and "OpenGL" video modes technically worked, but they froze and would not continue drawing when I attempted to run the benchmark. Expect them to be less than optimal if they do work.

DOOM Performance with Emulation

It's no surprise that Chocolate DOOM creamed the other options, so it results in a very simple recommendation: if at all possible, stick to open source software that can run natively on ARM. The emulation gap is rather staggering on this machine, which doesn't really provide a good experience. When compiling the SVN version, DOSBox did provide some competition, but could not even reach the slowest option of Chocolate Doom.

However, if you have a DOS application, you should absolutely run it in DOSBox, no questions asked. QEMU shows some modest performance gains over the distro-provided DOSBox package, but those disappear once you build the SVN code.

If emulating command-line applications for Linux (or even Windows command-line via Wine), use QEMU user-space emulation. When it works, the convenience cannot be beat. If you have a graphical Linux application, or a very old, not particularly demanding Windows application, go ahead and try it, but chances are good that it won't behave as expected.

QEMU System emulation should only be used if all other options fail, and requires quite a bit of patience. Per earlier recommendations, I suggest creating the VM on a more capable machine then porting it over. SDL is definitely the way to go if you're comfortable with the QEMU command-line options, though virt-manager is pretty convenient if you don't mind the hit for going to VNC. If using older OSes, you can save RAM and disk space by going well below the "default" QEMU settings. I used 128 MB of RAM and a 1 GB disk image when trying out the Win 98 setup, which is plenty for that OS.

Kernel and Upgrading

The TERES A64 runs on a custom Linux Kernel based on version 3.10.104. Combined with the Ubuntu MATE 16.04 LTS, this machine could use some upgrades. So what are the options like?

Distribution Upgrade

The "easy" upgrade is to simply do an Ubuntu distribution upgrade. I used the Debian-style, but you can always go for the Ubuntu method as well. Most guides seem to do the upgrade in a GUI, but I find that running from a TTY session (e.g. Ctrl + Alt + F1) is usually safest. This will result in a generally good, upgraded system, but not without some caveats.

These are, in no particular order:

man pages may refuse to render.
This is actually an upstream Debian bug that comes to light during an upgrade, but only on older Kernels (like this one!). The solution from askubuntu is to disable apparmor on man using the following commands:
# apt install apparmor-utils 
# aa-disable /usr/bin/man
Pulseaudio may detect the audio device as two separate mono outputs instead of a combined stereo.
I don't have a good solution for this one, but a simple work-around is to uninstall pulseaudio for now. The base alsa device still registers properly, and works as expected with most applications. A full fix would require some significant digging into Pulse Audio's configuration files and possibly its source code.
upower (and thus most desktop environments) will not detect the correct battery and not report battery status.
No solution for this one, but a work-around is to use $ upower -d to report current power status. Again, this appears to be interactions with older kernels. A fix would require a Kernel update, or possibly a custom build of upower. Although this may seem superficial at first glance, this also means that any power management is unable to detect between plugged and unplugged states for performing power savings. This can impact battery life unless you make all your power settings conservative.

The post on the official Olimex forum thread only mentions some of these issues, and did not seem to drive much interest in any fixes. It also reported some HDMI issues, but I did not test HDMI before I downgraded back to 16.04.

Alternate Distributions

I was going to label this section "Kernel Upgrade", but upgrading the Kernel in-place isn't really much of an option, short of taking a newer version and porting over the changes from the Olimex github repository. The better option is to use another distribution that is already based around a newer Kernel. The main development push for this board is Armbian, of which there are images both on the Armbian site, as well as from Olimex.

Olimex suggests their version of the distro, but they also independently provide deb files for some of their fixes, which could theoretically be installed in the upstream distro too. In the interest of comparison, I'll try both.

Upstream Armbian

There are, in fact, two variations of the upstream Armbian distro at at present: one based on Ubuntu Bionic Beaver (18.04 LTS), and another based on Debian Stretch (9). I opted for Debian to start with, then went back and tried the Ubuntu build after. The Debian distro starts as a console-only "server" distro, though a desktop can be loaded after. The Ubuntu distro starts with an Xfce Desktop. Both distros are, by default, configured to run directly from the microSD card, and do not provide a direct means to install to the eMMC. If you wish to do this, I suggest referring to some discussion on the Olimex forums. If you have a large microSD card, you may prefer to use that as your root drive anyways.

You will need to refer to the Armbian getting started for the default credentials, though once that is complete, you will have a working install. The first step after logging in will be to configure the wireless so you can download packages. If you are using Ubuntu, you can use the GUI per normal. If you are using Debian, you can either use armbian-config to connect to a wireless access point, or for more fun, use nmcli:

# nmcli device wifi rescan
# nmcli device wifi list
# nmcli device wifi connect {Insert SSID Here} password {Insert Passphrase Here}

Following this, you can use the typical apt commands to update existing packages, then install some new ones. To upgrade the Debian install with a GUI, I installed the xserver-xorg, xfce4 xfce4-goodies and lightdm packages. You'll likely want to add a few more to customize to your liking regardless of which distro you started with.

After configuring the Armbian setup, it is already apparent that the power source issues from upgrading the Teres Ubuntu image are not present, though Armbian does introduce some issues of its own. The two most notable issues are the lack of sound, and some issues with suspend mode. Both issues should be fixed given enough development time. If you were interested in digging in to fix things yourself, more so the better.

On the Debian build in particular, 3D output did not appear to function properly. I was able to get some basic behaviour by installing the libgl1-mesa-dri package, but this only fixed a few desktop applications. I still was unable to run glxgears or glxinfo in this config. I'm sure there is some way to do this; perhaps investigating the Ubuntu package install or configuration may provide some insight. For the Ubuntu-based distro, it does work fairly well, though it's still hard to tell whether it is truly accelerated or not. See the additional benchmarks below for some notes on that.

Armbian does introduce some advantages of its own, beyond simply a newer Kernel. Xrandr is now supported, so you can use your desktop environment to properly (and easily) configure the external display. Alternate resolutions and setting the primary display all work as they are supposed to. HDMI audio works too, which allows some form of audio output on Armbian. Unfortunately, XInput joysticks still don't work, so you'd probably need to do a kernel rebuild for that.

I did install the Teres fix packages, but the bluetooth module still failed to initialize with "Can't get port settings: Input/Output error" on rtk_hciattach for either Ubuntu or Debian. It does work with the Teres-packaged distro below, so it would take a bit of digging to see what Olimex did there. The keyboard LED package worked fine, though.

Teres-packaged Armbian

The Teres version of Armbian is very similar to the Ubuntu-based Armbian, with the Xfce desktop. However, like the "normal" distro, it comes pre-configured with an 'olimex' user rather than the Armbian user creation process. A sound device now appears in PulseAudio, which works as expected. However, the headphone jack is not detected, and there does not appear to be a way (at present) to select it. The packages for LED control and Bluetooth are both included, though strangely only the bluetooth package was installed. Unlike base Armbian, the bluetooth module behaved as expected, without any errors.

Strangely, this distribution refused to establish a wireless connection with my router. I tested both the network manager GUI as a normal user, and nmcli (per above) as root. In all cases, it behaved as if I had provided the wrong password. To confirm my sanity, I also cross-checked my password in the router settings. Unable to resolve this, I used a USB ethernet adaptor for the remaining checks of this Distro.

The other notes from standard Armbian still apply; battery status and xrandr work properly, though suspend still does not work.

Armbian Benchmarks

From re-benchmarking, it becomes apparent that performance is substantially improved; correcting some of the strange results when compared to the Pi 3. In most cases, both Armbian distros are essentially the same. When differences appear, they will be noted, otherwise only one result will be shown. With that said, let's start with the DOOM benchmarks:

DOOM Benchmarks comparing Distros

Performance is over double running Chocolate DOOM, and is essentially in-line with the Pi 3. DOSBox shows a much more modest improvement, however.

I also tested Chocolate DOOM on both Ubuntu-based Armbian distros, though they included the newer version 3.0.0. If using this option, you will want to set the force_software_renderer option to 1 to keep it from trying to use OpenGL It only provided a modest 36-33.6 fps, which is perhaps based on some changes to that version of Chocolate DOOM? Still a fine frame rate for normal play, though a small step backwards from the Debian-based Armbian performance.

The 7-zip benchmark results show a similar increase to DOSBox, though the results were generally fine to begin with:

7-Zip Distro Comparison

In the case of the disk performance, the eMMC read speed is almost doubled, though microSD performance is unchanged. It is unclear what caused this effect.

Armbian Read Performance Armbian Write Performance

3D is a little bit more interesting:

Armbian GLXGears Comparison

The Olimex distro seems essentially the same as 16.04, but the upstream Bionic distro shows a gain of about 50 fps on glxgears. This is still well short of what the Pi is capable of, but it is a step in the right direction. It's still not entirely clear if these are simply due to the same CPU gains as above, or if the video hardware is being used meaningfully. More development is likely still needed in either case. It is also quite strange that the Olimex distro does not also show this gain; it's has the same base OS, so it should be seeing this as well.

Summary and Conclusions

The Teres is undeniably an interesting device, and provides a enjoyable build process, but is it a device you will want to use after the build is complete? This is going to depend entirely with what you hope to get from the machine. If you expect to build the laptop then generally just use it, you will be disappointed and will want to look elsewhere. You can use the machine for some simple development if you stick with 16.04, but you aren't going to get anywhere close to the performance you needed if you wanted something like a portable RetroPie alternative.

If, however, you wish to get into Kernel and/or distribution development; congratulations, you have a reason to get this laptop. The Armbian project has a number of avenues to support, and the full hardware configuration for the laptop is well known. Go grab the schematics, pull up some data sheets and start poking away at some of the problem areas in the current build. This machine is first and foremost built for tinkering, and should really only be considered if you are willing to do the extra work.

Pros:
➕ Panel crisp and readable
➕ Touch-pad responsive without accidental use while typing
➕ microSD for expandability
➕ Good battery life
➕ Lightweight

Cons:
➖ Average CPU performance (between Pi 2 and 3)
➖ Touch-pad buttons stiff
➖ TN Panel
➖ Keyboard is a bit compressed
➖ Poor eMMC and microSD performance (though Armbian helps the former)
➖ Lots of screws and rubber feet to remove if re-opening
➖ No real expansion options aside from microSD

Fixable Cons:
🔧 3D performance is poor, unclear if hardware-accelerated or just software
🔧 Sometimes missed keystrokes
🔧 Various regressions when switching from Ubuntu MATE to Armbian

Comments

Add a Comment
Comment Atom Feed