5 Apr 2018
I joke that I run the slowest machine in the free software community.
Amusing as it is to hold the title, it isn’t particularly an exaggeration.
As I outlined in “My Name is Cafe Beverage”, since the beginning of 2018, I have been using my “Librebook” full time. That is, my Chromebook based on the Rockchip RK3288 chipset, running entirely free software from the boot firmware up. I dream of a world where all software is free; while I realise that for many people, proprietary software’s lure is still too strong, I strive to set an example for how a modern digitally-connected life can be driven by a free software stack like this.
Why this particular laptop though? This machine, the Asus C201, was released in 2015. Surely, there was some option for committed free software activists before then? Indeed, the Libreboot project supports a number of laptops compatible with free software, of which the ARM-based C201 is only one. The other laptops are, for the most part, x86 laptops released over a decade ago. Before this laptop was available, those other machines like the Thinkpad X60 used by Richard Stallman himself were the best free software supporting laptops targeting end-users.
But that is the past. This new laptop is supported now; it is time for a new day in the Libreboot project history. Besides being new and shiny (!), the C201 can be a superior choice over the X60 or the X200 in terms of freedom. Backed by an ARM chip rather than an Intel or AMD x86 chip, there is no proprietary microcode, neither burned in to the processor nor required to be loaded on boot for proper functioning – indeed, the processor has no microcode whatsoever! Additionally, as documented on the Libreboot wiki, the embedded controller (EC) in the laptop is designed to run a free software firmware. The EC is a small real-time chip found in laptops that manages miscellaneous tasks like power management and the keyboard. Whereas the EC on the old Thinkpads ran proprietary firmware that our community quietly accepted, content with the rest of their boot freedom, the EC found in Chromebooks runs free software firmware that the end-user is able to modify, compile, and reflash on the device, if they so choose. While the machine is not perfect in terms of firmware freedom, it is a step up from the older laptops endorsed by the Libreboot project and by the Free Software Foundation itself. (Unfortunately, the laptop is not quite ready to be endorsed by these holistic organisations, for reasons discussed below. The hope is that with work to address other tangential issues, they will be able to endorse this newer ARM laptop.)
What of the x86 laptops? While they are certainly popular in our community, I am not convinced that they are worthy candidates for software freedom going forward. There has not been a new x86 laptop made that is able to meet “Respects Your Freedom” certification in almost a decade. There was, briefly, a surge of interest in freeing the remaining components of the Sandybridge microarchitecture, a task which would require developing a 0-day exploit against the mystical, well-guarded “Management Engine” (ME), in order to disable it and qualify for Libreboot support, matching the basic standards of freedom that our community has come to depend on.
What is this Management Engine, anyway? The Intel ME, for the uninitiated, is a secondary core running a proprietary real-time operating system with terrifying capabilities, publicly known to be used for remote management in enterprise settings, firmware-level Digital Restrictions Management, and privately for heaven knows what else. Dating back beyond a decade – and with an analogue system, the “Platform Security Processor” (PSP) in AMD machines appearing later – some suspect that the ME was placed under 3-letter agency supervision. Regardless of the potential involvement of shadowy government agencies, we do know that the Management Engine is a security hole, with multiple critical vulnerabilities having been discovered recently. x86 machines, whether from Intel or possibly AMD, are a bust for freedom. Attempts to neuter this system, through a project called me_cleaner, have been more or less successful. But disabling it entirely is an open problem that may not have a solution, let alone a practical, legal solution suitable for the masses and endorsable by our leaders.
But as for ARM devices? While there is TrustZone, which on certain devices can be used for ME-like tasks, there is nothing that compares to the ME in scale and threat. While all of the Sandybridge effort was dedicated to disabling a component that should not have existed in the first place, in a just world that valued software freedom over corporate and governmental special interests. When the C201 was added to Libreboot, there was no part to disable at all.
ARM devices are the future of software freedom. The C201 is the first step on a long-term path there.
Without further ado, I’d like to share what life is like, as a programmer in the digital era, living on a Rockchip. So, how do I use my device?
Simple.
In freedom.
The proprietary operating system that was bundled with machine when I first purchased it, ChromeOS, has been thoroughly wiped from the laptop. Instead, it has been replaced with Debian GNU/Linux, running with only the main repository: neither contrib nor non-free are enabled. I would prefer to run an FSF-endorsed distribution, but to my knowledge, there are none supporting this machine that suit my needs. (For a short while, I had used Parabola GNU/Linux, a free software fork of Arch Linux, but as a bleeding edge distribution, this was not a comfortable experience. For contrast, Debian-based systems have been home for years. I would be excited by efforts to port FSF-endorsed distributions to the machine, and excepting showstopper issues, I would gladly switch for my freedom’s sake.)
For the kernel, I run mainline! There is no ChromeOS kernel here, nor is there a load of vendor-specific patches. I did need to apply some small patches to improve USB stability, but even those have been merged since the previous kernel update. Unfortunately, I had to compile it myself as I have been so far unable to boot a recent, prepackaged, blobless, mainline kernel. Additionally, I had to scrap together disparate sources of information on packaging the kernel into a format that depthcharge, the free software bootloader used in tandem with coreboot on Google’s Chromebooks, could boot from. While this was inconvenient, it is a small price to pay for freedom.
I only use free drivers. In particular, I do not use the vendor’s proprietary blob driver for the GPU, the Mali T760. Blobs have no place in the free world, and as a number of developers before me in our community have shown, there is no legitimate reason to keep perfectly good hardware locked up with a blob. But following the lead of developers like Luc Verhaegan from lima and Rob Clark from freedreno, I do not merely complain about the blob for this hardware. Nor do I pretend the graphics processor does not exist, creating a fragile equilibrium where the status of the driver freedom does not matter, in which I would not use any graphics driver. No, alongside my fabulous teammates, I have spent the previous months developing the Panfrost driver, a free software driver for this GPU and others of its family. Our project is progressing well, and sooner than later, graphics acceleration on this device will be completely usable in freedom.
On the subject of graphics, in the mean time before the Panfrost driver is ready for day-to-day use, I run i3. This tiling window manager, although incredibly minimalistic, is lightweight and ideal for a setup that does not have fast graphics quite yet. I’m looking forward to the day that I will be able to run GNOME 3 again, a feat which is currently all but impossible in freedom due to the slowness of software rendering, but for now, this is the setup that I need to use.
Beyond that, I run a standard GNU/Linux desktop. I browse in Dillo or Firefox. I read my mail in mutt (by choice, not due to hardware constraints). I write my blog posts in vim (ditto). I do schoolwork in LibreOffice. I make digital artwork in Krita, Inkscape, and Synfig. All in all, I don’t miss my old proprietary-software-bound laptop – my new one works well enough but with respect for my freedom.
Unfortunately, however much I love my device – and I do love my Rockchip laptop – there is much work to be done before it can be recommended to end-users interested in software freedom. The fact is, although I have managed to use this laptop in freedom to accomplish all of the computing I would normally, the road has been rocky (pun intended). If, as a reasonably seasoned developer with an understanding of the basics of system administration, I struggle to setup this machine for daily use, how can I expect anyone else to setup the machine with ease? If, as a graphics driver developer, I must avoid high-quality free software like GNOME and blender because it is too slow without the free drivers, how can I expect a GNOME user that may not know what a GPU is to switch to the laptop?
There are a number of specific issues with this machine when running the full free software stack with mainline (thank you to #linux-rockchip among others for help collecting the list):
Difficulty using the bootloader. depthcharge does not take a usual EFI or BIOS kernel image; it requires a specialised packaging format which is tricky even for developers to use. Off the bat, installing a custom kernel (or even general system) is difficult. Additionally, there is a looming threat of data loss due to wiping from accidental switches from developer mode, an issue to which non-technical users would be particularly susceptible.
No pre-packaged kernel. This is the distribution side of the above – packing for depthcharge is necessary when distributions aren’t packaging their kernels this way themselves.
No pre-compiled kernel at all! Standard kernels inexplicably fail at a white screen at the beginning of booting. This issue has been anecdotally reported by a number of other enthusiasts with this hardware, but there is no known fix. Somehow I managed to circumvent this when compiling the kernel myself.
No pre-packaged system image. Again, without distributions supporting the machine, it is prohibitively difficult for end-users to install a system of their choice.
Missing GPU drivers. This lack is tied closely to the missing free software graphics driver, a problem which we in the Panfrost project are busy solving.
Internal wifi requires proprietary firmware. There are a few wi-fi chips used in the various RK3288 laptop models; as far as I know, there are chips by both Broadcom and Marvell. Both require proprietary firmware loaded to the device in order to be used, and if I understand correctly, the former has had an over-the-air exploitable privilege escalation attack against it in the past (Broadpwn). These firmwares are not benign. Internal wifi is out of the picture.
USB with the dwc2 driver is incredibly buggy. This driver is, apparently, known to be a mess. Even ChromeOS on this machine has had issues relating to bugs in this driver: nobody is immune from the wrath of dwc2. Unfortunately, this makes certain USB devices unstable.
ath9k_htc does not work at all with the buggy dwc2. Extension of the above, except that ath9k_htc is the preferred USB wifi device as far as firmware freedom is concerned. With this chipset nigh unusable on the laptop, external wifi in practice needs to use a comparatively less free chipset, such as a Realtek-based dongle like I lamentably use.
Missing packages. Krita, for instance, still does not build on this architecture without a number of hacky patches.
Buggy audio support. It’s possible this is true across GNU/Linux desktop, though, given how notoriously picky ALSA and PulseAudio can be; that said, the sound controller on the RK3288 is… peculiar and is known to cause issues when improperly configured.
General form factor issues. There is only 16GB of internal storage; the keyboard is not especially comfortable to type on; the screen is low-resolution with poor colour contrast. This is what is to be expected of a low budget Chromebook; there are other devices with the same chipset that are more amenable to daily use.
Yes, this is a long list. No, I don’t think the issues will be solved magically by virtue of me venting about them on my blog. Yes, I do think that as a community, we have the power to solve them. Already a number of these issues are seeing progress. I have personally been focused on the GPU debacle. Various folks involved in distributions and packaging have been working on easing the process of system installation and providing full prepackaged system images, albeit not for any mainstream images. I’d like to give a shout out to the devsus project, which provides fully free Devuan GNU/Linux (Debian GNU/Linux sans systemd) images for this laptop. Still, it is a ways to go before this laptop can be totally recommended for general non-technical users who are interested in free software, matching the state of its much older x86 counterparts.
Additionally, a number of these issues will potentially be mitigated by using a newer SoC that does not depend on the dwc2 driver nor the armhf (rather than arm64) architecture. I have yet to evaluate these options.
What is there to do? If you’re a developer or a sysadmin, begin working to fix some of these! There’s a lot to be done and not a lot of people working on it, but the problems are definitely tractable with patience, care, and motivation. All we’re waiting for is someone to do them.
Still, the C201 was released as a budget laptop in 2015. It is 2018 now. Google only supports Chromebooks for five years after their initial release, which means there are only two years before this particular machine will be declared end-of-life and will stop receiving support patches in ChromeOS, patches which frequently would otherwise be eligible for merging back up into mainline free software packages. There is only so much to be done with this current Asus C201.
Fortunately, the journey does not end at the C201, built on the RK3288. For starters, all of the software freedom considerations of this Chromebook apply to every other RK3288 Chromebook – and there are a number of them. If there were interest, it would be relatively easy to add support for these to Libreboot as well. The software support, on an operating system level and above, should be identical.
More importantly, there is not only the RK3288 chip that wins this gold standard for freedom. Its successor, the RK3399, shares its characteristics, allowing unsigned boot, free firmware, and so on. That said, the RK3399 is newer, higher performance, and powering devices that have not even been released to the public yet. The RK3399 is a promising candidate for Libreboot support, and with no risk of end-of-life in the near future, efforts to improve its driver situation on mainline with free software will not have been in vain.
It is true that as a community, we still have not yet gained the critical mass needed to let free ARM devices replace their aging x86 counterparts. However, it is clear the future for these devices based on Rockchip chips is bright.