Setup Guide & Mini Review of BQ Aquaris M10 Ubuntu Edition Tablet from a Developer’s Perspective

BQ Aquaris M10 UBuntu Edition is the first officially supported Ubuntu tablet on the market. Blu, a frequent commenter on this blog, has purchased the Full HD version, and in the guest post below, shares his experience setting up the device for development purpose, before shortly providing his overall impressions about the tablet itself.

Quick introduction

Ever since I had to retire my trusty-but-ancient ARM notebook (a Genesi Efika iMX51) I’ve been looking for a new ARM notebook or perhaps a 2-in-1 device, that I could use for development on the go. The basic requirements are long battery life, passive cooling and reasonable price. Also, Just Enough Power™ for running vim, a couple of toolchains (gcc/clang with gold) and, well, enough grunt to run my coding experiments. Naturally, BQ M10 Ubuntu Edition immediately got my attention to the extent of me placing an order, which got delivered this past week. Allow me to share my impressions from the M10 so far.

First thing first: turning the M10 into a coder’s productivity device

There is plenty of know-how on the web regarding how to ‘unlock’ a Ubuntu Touch device into a full-fledged Linux box, but here we will describe the minimum steps to achieve this, moreover without the need for a desktop. The M10 needs to be on a Wifi network with Internet access, though.

From the Ubuntu Store, install the terminal application – access to the store requires a registration with a valid email address. Once we have that, we have proper control over our device via the on-screen kbd or via a physical Bluetooth or micro USB kbd.

What we immediately see from the above is that the device hosts a quad Cortex-A53 r0p3 (CPU part 0xd03), and the userspace is armhf – ’CPU architecture’ in /proc/cpuinfo should say ‘AArch64’ for an arm64 userspace; instead it says ‘8’ on an armhf userspace.

Typing on the on-screen kbd is a mere curiosity, so before we get ourselves a decent Bluetooth kbd or a micro USB-to-female-USB adapter (for a standard usb kbd) we will need something better to type on. Getting an ssh server on the device takes a minimal effort – the package is already installed, it just needs enablement. We also need a public ssh key ready on the desktop machine, as the ssh server is factory-configured for public-key access only. So, assuming we have our public key handy on the desktop, we need to do the following in our M10 home:

Now we can ssh to phablet@respective_ip and enjoy a proper kbd. Apropos, the final step of actually enabling the ssh server should also be achieved via engaging the tablet’s Developer mode in the About This Device tab in the system settings.

A quick look at the mounted filesystem shows that the rootfs is mounted as read-only, and that can be a show-stopper for any apt-get we plan to do next. So we need to enable read-write mode on the root fs via:

Please note that the system will automatically reboot after this command; our rootfs will be write-enabled after that. Then we can:

Just be warned that keeping the rootfs in write-enabled state actually disables OTA updates of the tablet fw. So once we’re done with apt-get for the day, we might want to:

For reference, these are the g++ and clang++ versions that we can get on the tablet currently from the standard vivid repositories:

Running (natively-built) binaries from within our home folder takes some tinkering, though. The reason for that is apparmor – this daemon is factory-configured to not allow the execution of apps from the /userdata mount-point (/userdata/user-data is where our home is at). To solve that inconvenience, we need to find the app profile of our indispensable terminal app, and edit it appropriately to allow the execution of binaries from our home.

Please note the actual version of the terminal app might be different. In there we find the following lines:

And add to them:

Followed by:

So, now we can build and test our code on the M10. A couple of notes:

• Since this is an armhf userland, i.e. it’s 32-bit ARM, the default target of gcc/g++ is thumb2 (as per Canonical’s worldview) – one might want to pass -marm to the compiler for a few more percents of performance.
• There’s a compressed ramdrive of the size of 0.5GB taken from our precious little 2GB RAM; it’s used as a swap partition. Whether that’s a beneficial decision for our purposes is not clear.
• The Cortex-A53 in the MT8163A (i.e. the 1.5GHz version) appears to be somewhat slower in this configuration than other vendor’s A53s of the same revision (e.g. Rockchip’s RK3368 @ 1.51GHz). I don’t know what to attribute this to yet. Could be because of intricacies of the scheduler and/or performance manager, though the latter should be bog standard cpufreq. Or because of the lxc container with a minimal android providing the display painting services. Or it could be a hw difference somewhere in the cache hierarchy. An investigation is pending in the indefinite future.

Informal impressions

The M10 is a solidly-built piece of ‘luggable’ electronics, AKA portable things you always lug along in your backpack for 24/7 accessibility. Whenever I’ve found myself wishing for something more in the M10, it’s normally been a sw issue. Back to my original criteria for a productivity portable, its battery life is nice – lasts between one and two days of trivial coding use – vim, build, test, repeat. The pricing is slightly on the upper side for this class of hw, IMO, but hey, early adopters’ premium (which apparently I was willing to pay). For the price one gets a cluster of Cortex-A53 at (almost) industry-standard performance levels, 2GB of RAM and 16GB of eMMC (of ~150MB/s read BW). The quality of the screen also bears mentioning – it’s quite nice – better than that of my aging Acer netbook.

That said, the things that need improving going forward:

• Android needs to go; Canonical need to pull their act together and provide a proper 100% Linux on this class of devices. Whether that includes ‘muscling’ vendors like MediaTek into conformance or just paying for the development of native graphics stacks – that’s rather irrelevant to the end user.
• Along the above: out with the armhf and in with the arm64 userspaces on aarch64 hw – it’s about darn time.
• Prices need to get more realistic, but that’s a matter of market adoption, I guess. At least, for the price of the M10 one should be able to get 4GB or RAM.

Jean-Luc Aufranc (CNXSoft)

Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress