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.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
phablet@ubuntu-phablet:~$ uname -a Linux ubuntu-phablet 3.10.93+ #1 SMP PREEMPT Wed Mar 30 09:09:10 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux phablet@ubuntu-phablet:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 15.04 Release: 15.04 Codename: vivid phablet@ubuntu-phablet:~$ lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0 Off-line CPU(s) list: 1-3 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 1 CPU max MHz: 1500.0000 CPU min MHz: 600.0000 phablet@ubuntu-phablet:~$ cat /proc/cpuinfo Processor : AArch64 Processor rev 3 (aarch64) processor : 0 BogoMIPS : 26.00 Features : fp asimd aes pmull sha1 sha2 crc32 wp half thumb fastmult vfp edsp neon vfpv3 tlsi vfpv4 idiva idivt CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 3 Hardware : MT8163 |
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:
|
1 2 3 4 5 |
$ mkdir .ssh $ scp desktop_user@desktop:/home/desktop_user/.ssh/id_rsa.pub .ssh/authorized_keys $ chmod 700 .ssh $ chmod 600 .ssh/authorized_keys $ android-gadget-service enable ssh |
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:
|
1 |
$ android-gadget-service enable writable |
Please note that the system will automatically reboot after this command; our rootfs will be write-enabled after that. Then we can:
|
1 2 |
$ sudo apt-get update $ sudo apt-get install those-much-needed-packages |
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:
|
1 |
$ android-gadget-service disable writable |
For reference, these are the g++ and clang++ versions that we can get on the tablet currently from the standard vivid repositories:
|
1 2 3 4 5 6 7 8 9 |
phablet@ubuntu-phablet:~$ g++ --version g++ (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. phablet@ubuntu-phablet:~$ clang++ --version Ubuntu clang version 3.6.0-2ubuntu1 (tags/RELEASE_360/final) (based on LLVM 3.6.0) Target: arm-unknown-linux-gnueabihf Thread model: posix |
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.
|
1 |
$ sudo vim /var/lib/apparmor/profiles/click_com.ubuntu.terminal_terminal_0.7.190 |
Please note the actual version of the terminal app might be different. In there we find the following lines:
|
1 2 3 4 5 6 |
profile "com.ubuntu.terminal_terminal_0.7.190" (attach_disconnected) { capability, network, / rwkl, /** rwlkm, /** pix, |
And add to them:
|
1 |
/userdata/user-data/phablet/** pix, |
Followed by:
|
1 |
$ sudo service apparmor restart |
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 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
I’ll quote you here:
What we immediately see from the above is that the device hosts a quad Cortex-A53 p0r3 (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.
That is not correct. CPU architecture info from /proc/cpuinfo has nothing to do with userspace (you have 3.10.93 kernel, see here – https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/arm64/kernel/setup.c?h=v3.10.93#n397 and you’ll see that CPU architecture: 8 is hardcoded in kernel).
Basically you have 32bit OS running on 64bit SoC 🙂
Change from AArch64 to just 8 happened with mainline kernel commit https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/?h=linux-3.14.y&id=42b34c73ae40e3158779a5d47dcd514702804613 which is merged to other versions too.
Stane1983: Apparently I was not clear, so let me elaborate. I’m well aware M10 is running a 32-bit userspace on an aarch64 kernel via aarch32 support. And you’re right to note that ‘CPU architecture: 8’ was hardcoded for a certain timespan in the arm64 stock kernels, but at least in android space (which is where this tablet originates from) the nomenclature did change with respect to what that filed should specify. Traditionally arm kernels used to show a numeric for the architecture version there (i.e. ARMv7 would be ‘7’, ARMv8 would be ‘8’, etc), but with the advent of aarch64, (early) aarch64 kernels started reporting ‘AArch64’ in that field. To avoid the ensuing confusion, the android kernel adopted a policy where cpuinfo would report the architecture version based on what task is asking – for 32-bit tasks the value would be ‘8’, and for 64-bit tasks – ‘AArch64’
https://android.googlesource.com/kernel/tegra/+/3868e7f8d47992922756d1aa6590f0d556c669b8%5E!/
Now, since it doesn’t make much sense for an arm64 userspace to use an armhf cat binary, it is fairly safe to assume that if an android kernel returns ‘CPU architecture: 8’ when asked from the terminal, then it’s an armhf userspace.
@Stane1983
@blu
It’s sad, when you can’t even trust what /proc/cpuinfo returns these days without checking the exact kernel version and whether it’s an “Android hacked kernel” or not.
@cnxsoft It’s even more sad when one realizes it all stems from the darn GPU support. And ARM Holdings themselves are not without guilt there.
@blu
Isn’t it more accurate to just run “file” on a system binary to see what is the userspace compiled with?
@Eversor Sure, there are multiple ways to tell whether a userspace is armhf or arm64 (e.g. the target triple of clang is one). Dumping /proc/cpuinfo is just among the first things I normally do on a newly-accessed linuxbox, so chronologically that was the first indicator for me M10 featured an armhf usespace.
@blu
Right. So from your explanation above, I see two ways the system may be compiled here: ARMv7-A (armhf) or ARMv8-A (AArch32). What is the system supposed to show on cpuinfo if the system is built on AArch32? Either way, it is better of them to actually do so, since running 64bit wouldn’t affect perfomance much – especially if it’s on AArch32 – and with 2GB of RAM it would run rather “tight”.
Why doesn’t my m10 rotate properly? It just doesn’t work at all. The accelerometer is sensing.tux racer plays fine!
@Eversor
Actually, armhf is the only viable option for a 32-bit userspace under aarch64. Hypothetically, armel could be an option too, but I haven’t heard of anybody ever attempting that.
Here’s how cpuinfo looks on the same-ish kernel (another 3.10 originating from android) but under arm64 userspace:
processor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: AArch64
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 3
versus M10’s armhf userspace:
processor : 0
BogoMIPS : 26.00
Features : fp asimd aes pmull sha1 sha2 crc32 wp half thumb fastmult vfp edsp neon vfpv3 tlsi vfpv4 idiva idivt
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 3
Notice how besides the difference in CPU architecture, the features fields on the armhf userspace also duplicates armv7-applicable features in their armv7 form. For instance, ‘asimd’ in armv8 is ‘neon’ in armv7, so you get both of those in the features list.
@Mu They seem to have a sw bug in the rotation logic. Just rotate the tablet in the desired orientation, then enable desktop mode, while leaving the rotation lock disabled – that normally fixes it for me (and I normally use the M10 in desktop mode anyway).
Thanks for reply wheres the switch? Also libreoffice is permanently stuck in portrait!
I had high hopes for the m10, I used the e5 for a while but had to flash to android. Some issues have still not been fixed. The wireless connectivity is awful and when browsing constantly get no network connection messages only alleviated by constant refreshing!!
@Mu Both switches are in the applets menu in the upper-right corner – just swipe down on that, and several applet tabs will appear. The rotation-lock switch has its own tab, while the desktop-mode switch is in the System tab.
Re the wifi connectivity – I haven’t noticed any apparent issues on either of the two wifi networks I’ve used the M10 so far. I need to test it with more networks.
@blu
arg – it always goes to portrait in libreoffice even when using rotation lock AND desktop mode!
why did they release this POS
another expensive budget android device bought from BQ (time to reflash)
@Mu
If LibreOffice goes portrait that just means the buggy orientation logic is still active – it sometimes ‘locks in’ for some reason. Then any app except for the unity launcher will rotate to portrait when the tablet is actually in landscape orientation. You need to take the tablet out of this mode. Perhaps the order of toggling the switches does matter. I know that even if my M10 goes into that buggy orientation mode, it eventually snaps out of it at the state of those switches I described. But it’s not a per-app thing – all apps behave consistently. Right now every app on my M10 displays in landscape, LibreOffice included.
@blu
Is there something I can do to permanently keep it in landscape (other than the switches..)
@Mu
anything magic I can write in the terminal to lock it into landscape permanently
One other thing I’ve noticed. When charging should a LED be lit ( red for instance ) when on ?
@Mu Ok, I know why the desktop/dashboard stays in landscape while everything else rotates when the tablet is in buggy rotation mode:
$ cat /usr/share/applications/unity8-dash.desktop
[Desktop Entry]
Type=Application
Name=Scopes
Comment=An interface for using the Scopes system
Exec=/usr/bin/unity8-dash
Terminal=false
Icon=/usr/share/unity8/Dash/unity8-dash.png
NoDisplay=true
X-Ubuntu-Touch=true
X-Ubuntu-Supported-Orientations=primary
The reason is the last line – the x-ubuntu-support-orientation key; ‘primary’ means for the app to stick to the device’s default orientation (which for the M10 appears to be landscape). The possible values of the key are described here: http://unity.ubuntu.com/2015/07/15/whats-new-in-ota-5/
So one way to force individual apps to stop rotating is via their desktop configuration files. For system apps those config files sit in /usr/share/applications, while for user-installed apps they are in ~/.local/share/applications/
@blu
Sure enough this works !! Just did for web browser. Guess I should be pleased a fix is there in text file.but still very annoying. My m10 doesn’t seem to do any kind of rotation AT ALL.
Sensor seems fine though in other paps and games ( meter sensors tux racer).
Hope this nonsense is fixed by nrext update
@Mu For the record, I did try a more holistic approach disabling (via unbind interface) the gsensor and msensor drivers*, but that did not help stop the rotation, so I’m out of ideas for the time being.
* The M10 hosts a Bosch BMA255+BMM050 gyro/compass/accel sensor combo, interfaced over the i2c bus.
That’s interesting and bizarre. The way mine works it seems no input from sensors drives the rotation.
There is plenty of know-how on the web regarding how to ‘unlock’ a Ubuntu Touch device into a full-fledged Linux box
could you point me ?
Btw, I installed OTA-11 and am still getting the same rotation problems.
@mu
Apologies for the truly late reply – I just noticed your latest post by accident, after going OTA-11 myself (yep, the rotation issue is still present).
Well, one way to unlock the device is to follow the instructions from this article up to the point of ssh enablement, and then further customise the M10 to your liking. For instance I’ve nuked the X-desktop click package from mine (package com.ubuntu.puritine located at /opt/click.ubuntu.com) freeing some 1.6GB from the root mount point. That has allowed me to install quite a few .deb packages from the standard repositories (mainly for arm64 development). So it really depends what you want to use your M10 for as a linux box.
How do you register the tablet?(Ubuntu Aquaris M10)