As my interest in the ARM architecture is growing, I decided to buy myself a toy to play with, based on one of those big.LITTLE asymmetric multicore 64-bit ARM processors, and see how they perform. I settled on the ASUS C101PA Chromebook after a friend successfully installed a Linux distribution on it.
I bought this machine for about $250 on Amazon, which I consider quite cheap. After I received the little thing (10″ only !), I started exploring and tinkering, which resulted in a bunch of instructions and scripts to install a Debian stable distribution without too much pain, replacing the original ChromeOS system on the internal eMMC.
My overall opinion of this Chromebook is mildly good at best. On one hand, the processor performs well. With a powersave/conservative CPUfreq governor, and low backlight intensity, the machine consumes less than 300 mA, and can last 15-20 hours at rest, 5-10 hours with reasonable or even intense activity. Basic functionalities are quite reliable, e.g. all inputs respond well all the time, the screen is good despite being glossy, but it’s a touchscreen, and I had no problem with the internal eMMC or an external microSD card, or USB. The webcam seems to work well too.
On the other hand, other devices just don’t perform that good. In particular, sound. I have no idea why, but the ALSA driver for the Rockchip RK3399 SoC exposes the speaker and the microphone as devices that Pulseaudio can’t really make sense of. I’m not an ALSA/Pulseaudio expert at all so I may have missed something, but searching the Internet made me realize this isn’t an isolated case. Volume settings are also a bit weird, with effective values between 0 and 10 only, leaving you struggling to understand why changing the volume has no effect on the output outside that range. On the other hand, the headphones output uses the full 0-100 range. My current workaround for output selection is to make applications use specific ALSA output devices. Playing a movie with the mpv player and headphones looks like this : mpv -ao alsa –audio-device=alsa/plughw:CARD=rk3399grusound,DEV=2 movie.mp4. Yeah, very convenient.
Wireless mostly works, but only in the 2.4 GHz band (when using the 5 GHz band, latencies are huge for no apparent reason). Bluetooth isn’t very reliable, and I couldn’t use it for networking through a smartphone for more than 10-20 minutes or so. The keyboard, while very pleasant to work with (large, light keys), lacks keys that I find very convenient, such as page-up/down, home, F11 and F12. An alternate function (Fn) key would have been a welcome addition. This can be worked around with remapping keys in the X.Org server. Oh and, there is currently no DRI/DRM support for the Mali GPU yet, so it’s all software rendering.
In conclusion, I’m happily surprised to observe that a very large part of the packaged software seems to work as well as on x86 machines. The only major exception for me is Qemu when trying to emulate an x86_64 machine (I’ll have to check more recent versions). On the other hand, the kernel itself, with its old 4.4 long term version (older than the 4.9 Debian stable kernel) and its driver bugs, is a clear disappointment. With just a little more software quality there, and an alternate function key, those Chromebooks would make perfect, cheap, developer-friendly mobile machines.
