Published: Fri 03 December 2010
By Denis 'GNUtoo' Carikli
In Article .
GNU/Linux on smartphones:
I started to seriously contribute to
free software after
buying the Openmoko
Freerunner (also called GTA02).SHR (the
GNU/Linux distribution I used on the Freerunner), by adding packages
upstream, in
OpenEmbedded .
Openembedded wasn't very stable: The packages weren't even built with
the same options when building from the same openembedded revision. The
options picked depended on the packages you built before, and on the order
in which it built the packages dependencies.
Vala
wasn't very stable on
ARM.
EFL
API
was constantly changing. This often broke crucial SHR graphical utilities
required for basic phone usage(phone calls, SMS, and so on).
Involving the users in testing images, to identify and fix breakges faster,
and inform users on the known issues, was done too late.
Ironically, nowadays Openembedded, Vala, and EFL issues seem to be fixed.
Over time, most of the Freerunner hardware related issues were fixed by
software, or hardware reworks. Some really annoying issue remained such as:
Serious sound quality issue on headphones
MicroSD compatibilties issues
The hardware also started to look really slow compared to newer smartphones,
such as the Palm pre ,
The Nokia N900 or the
HTC Dream .
This lead some developers to port SHR to newer phones.
I was then involved in the port on many phones, by adapting the vendor Linux
kernel and the SHR userspace.
SHR issues:
The availability of newer, more powerful, and way less buggy smartphones
hardware led me (and other involved developers) to try to have 100%
free software operating systems running on them.
This was important as the Openmoko community was going away, switching to such
devices, but running operating systems with non-free software on that
hardware.
However, porting SHR to newer phones took too much time to make it really
useful:
The devices stoped being sold when the port started to be close to usable for
basic telephony use.
At that point most developers also went away trying to port SHR on newer and
faster hardware.
Then not much remained to make the device daily usable.
That was the case for most ports, leading me to try to finish all the ports on
the hardware I had.
My goal wasn't to specifically run SHR on such devices, it was instead to run
100% free software distributions on them.
SHR used Xorg and had
many of the free software programs you can find on regular GNU/Linux
distributions.
It had graphical programs made specifically for touchscreen, handling the
telephony features one would expect from a smartphone, such as calls, SMS and
so on.
Some other programs were also written for playing music, using the terminal,
and other uses.
The many graphical free software programs found on regular GNU/Linux
distributions had to be adapted to work on such high resolution screen and to
be usable with a touchscreen.
SHR was better at adapting such programs than Debian, thanks to openembedded
flexibility, and unlike QTmoko, it could also run graphical programs that
didn't use QT.
Debian also lacked recent versions of the SHR specific graphical programs(such
as the ones handling telephony) and interface(Illume and EFL).
At the end of the day, SHR appeared promising because it had a mostly free
software system and applications on top of it.
The issue was that it had no policy to only include free software, and in
fact, it shipped a non-free program that made the GPS work on the Openmoko
GTA01(The first phone made by Openmoko).
That contrasted with other systems:
Maemo
(The distribution shipping with the Nokia N900): The system had a lot of
non-free components, but most of the applications running on top of it
were free software.
WebOS (The
distribution shipping with the Palm Pre): The graphical user interface and
software required to make the hardware work was non-free. As with the
Nokia N900, there was a lot of free software applications running on it.
More effort was required to integrate them, as WebOS didn't use
Xorg .
Android
:
Its sources were available, but wound't run on actual hardware, because it
required non-free hardware-dependant software to work. At the time it also
had very few free software applications on top, which needed to be
installed by hand (There was no package manager like
F-Droid ).
Creation of Replicant, A 100% free software Android distribution
There seem to be a growing interest in having a free software Android
distribution to run on the HTC dream, various people were interested, one
person even tried to build Android with as few proprietary software as
possible.
Replicant was then created to gather people and interest and to produce 100%
free software distributions running on the first available Android
smartphone(The HTC Dream).
It was primarly targetting Android, but also tried to share resources with the
people and projects interested in running GNU/Linux on it.
Though, most people were interested in running a 100% free Android
distribution.
I was interested in having both options available.
Practically speaking, Android had many advantages (and some drawbacks):
It was way faster to make it work: Adding a new phone was often a matter
of weeks, whereas with SHR it could take more than one year (often the
case with Android and proprietary GNU/Linux based devices). This is
because, by keeping Android, no big kernel and userspace adaptation were
necessary anymore.
It had very few bugs compared to SHR.
It lacked applications compared to SHR.
The first devices supported by Replicant had serious
freedom/privacy/security flaws that were discovered later. This was due to
the hardware architecture of such devices. Some of the SHR supported
devices didn't have such flaws.
I gradually stopped contributing to SHR. The main reason for it was that I
spent my time fixing bugs and making devices usable, having no time left to
make a 100% free software version of it.
I totally stopped contributing when the project switched focus and started
depending on proprietary software to make new hardware work.
Replicant: First devices support
In Replicant
Bradley Kuhn did
the project setup: he got us the project name, the domain name, the website
and infrastructure hosting.
In the beginning, the only way to install applications under Replicant was to
download the application pakcage and then to install it from the device or
trough an external computer.
This was very inconvenient because many free software applications only
published source code. It also required the users to verify by themselves
the authenticity and integrity of the pakcage.
Therefor Replicant badly needed a graphical application to manage packages.
Aaron Williamson attempted to fix this problem by trying to adapt a package
manager called slideme, to suit Replicant.
F-droid appeared later and is now used by Replicant.
Graziano Sorbaioli helped by testing and promoting Replicant.
Mirella Vedovetto did the Logo.
I did all the rest, that is making the HTC Dream work without non-free
software on the processor running Replicant.
At the time, Replicant was based on the official google source code (called
Android Open Source Project or AOSP). Downloading, compiling and running this
source code resulted in a non-working phone that cound't call, had no audio,
had no GPS, no screen rotation and so on.
The code making theses work was in non-free libraries, that I had to avoid or
replace. Fortunately there were some non-device specific "references
implementations" libraries that could be used as a starting point. Over
time, other projects started working on hardware support for devices using
qualcomm system on a chip(SOC) ,
so I also integrated their work when it made sense.
Theses libraries were used by the Android hardware abstraction layer.
This hardware abstraction layer permited to handle the non-standardness
of the hardware vendors Linux kenrels, and the "userspace drivers".
Even standard GNU/Linux distributions uses "userspace drivers" to make some
hardware work, such as modems, so an abstraction layer makes sense
anyway.
After that I also worked on porting Replicant to the Nexus One, another
devices with a qualcomm system on a chip(SOC), and on helping people that
were willing to do the same thing (Trough IRC help and documentation).
Beside some complex display issue, the port was mostly straingtforward.
While working on Replicant, I also learned more about the freedom privacy
and security issues that are the direct consequence of the hardware design
choices of smartphones and the processor/system on a chip they use.
A smartphone is conceptually similar to a laptop connected to a
Wireless modem .
In fact, nothing would prevent to port Android to run on a standard laptop.
Some Android distributions even do exactly that.
Wireless modems also have their own processor, and typically only run
proprietary software. On smartphone, Android runs on what is called the main
processor (or application processor), whereas the modem runs on the
"baseband processor". They are often abreviated as AP and BP.
On smartphones, the kind of connection between the main processor(Running
Android) and the modem processor can differ a lot. So far I saw:
Serial ports (Openmoko GTA01 and GTA02)
USB (Goldelico GTA04)
HSIC (Galaxy S3)
Shared memory(RAM) (most qualcomm SOCs, Nexus S)
Practically speaking, The HTC Dream was using an MSM7201A system on a chip
from Qualcomm, which had the main processor and the modem processor on the
same chip. In this system on a chip, modem had access to:
The RAM (Which was shared between the main processor and the modem)
The storage device (Here the NAND )
The sound card (since it was implemented in the modem)
The GPS (also implemented in the modem)
The Nexus S was later found to also used shared RAM.
This was deduced by reading the kenrel driver for the modem.
The Linux modem drivers usually makes sure that userspace can talk to the
modem, so here the RAM allocation for the modem was clearly visible in the
driver.
The userspace libraries then implemented the protocol used to talk to the
modem.
Replicant: new maintainership
Someone, with the "paulk" nick, asked me on IRC what was the best
(smart)phone with respect to freedom.
Answering to this common question always requires to take into account the
use cases, freedom requirements, and usability requirements for the
smartphone user. So in his case the smartphone that was the most adapted was
the OpenMoko GTA02.
That device later broke, and so paulk (Paul Kocialkowski) had to buy a new
one and this time settled on the HTC Dream. I helped him getting started to
contribute to Replicant, helping with git, free software norms and so
on.
At first his contributions to Replicant were minimal but he later decided to
port Replicant on the nexus S.
This new device was way more promising for freedom but writing the code to
talk to the modem
did not seem simple at all: unlike with the HTC dream, the modem modem
protocol was here, non-standard and non-documented.
From my point of view, buying that device and porting Replicant on it
appeared very risky, because I feared that there was a high risk of (him) not
being able to make the modem work. Four months after buying the device, he
had SMS working.
This success was also made possible by the fact that the proprietary modem
library was very verbose, and that there was already a free software
implementation for the lower level of the protocol, for another samsung
smarphone which ran GNU/Linux.
Paul then became the main developer and maintainer of the Replicant project.
Since the SHR project then started to target the Nexus S too, He then worked
in collaboration with Simon Busch (morphis on IRC) of the SHR project, to
make a modem library that was usable in both GNU/Linux and
Android(Replicant).
Even if I kept being very interested in Replicant and even did small
contributions, I was personaly busy with other free software projects such as
Coreboot.
Making osmocomBB usable daily:
Harald Welte announcement on the mailing list.
Trying to make the nuttx port work with alan
Upstremaing the code
Layer1 and deserpate attempt, relocation for work
Coreboot: How it started for me.
Since I knew about Coreboot(It was called LinuxBIOS back then), I spent a lot
of time trying to find supported mainboards, locally(in Milan, Italy).
I didn't find any: once supported, the mainboards weren't sold new anymore,
and finding specific mainboards second hand was not easy nor convenient for me
at the time.
When I upgraded my desktop computer, I tried again, and didn't succeed either.
However noticed that the mainboard I bought had a HE10 serial port connector.
Over time I kept casually checking the Coreboot website to see if any new
interesting boards that I could actually buy were added.
One day I noticed that the M4A785-M was mentioned, and I had an M4A785T-M...
I really had to try...
My plan was to try the M4A785-M code, however I lacked the ability to
externaly reprogram the flash chip: Without that ability, your only way is to
program the flash chip then reboot.
Then if the code makes the mainboard boot, you're good. But if it doesn't, and
that you you don't have an external programmer that would permit you to
reprogram the flash chip again, then the mainboard is functionally equivalent
to a broken mainboard.
Since the risk was big (bricking the mainboard) and the probablity of having
the mainboard fully boot my GNU/Linux distribution was low to moderate,
I coun't take that risk.
The Coreboot project even strongly advise users to have a recovery mechanism,
such as an external programmer, in case something goes wrong. And it often
does during development.
Coreboot: Quest for an external flash chip programmer.
The preferred way of installing Coreboot was to use a free software program
called flashrom that was used
to program the mainboard's flash chip. It can do it either:
By running on the mainboard you want to program (we call it "flashing"
in jargon)
By "swapping" the flash chip: This technique requires two mainboards with
the same flash connector. When the mainboard running Coreboot is not
booting, the user is supposed to take out its flash chip (not all
mainboards supports it), then to boot a second mainboard, and replace its
flash chip by the one from the Coreboot mainboard. Once done the user can
use flashrom on the second mainboard to reflash the chip of the first
one.
A common issue with this technique is that the users erounously flash the
wrong chip, ending up with two bricked mainboards. This is why having 3
flash chip is strongly advised. The third flash chip is supposed to be
kept in a separate place to help avoid mistakes.
The second mainboard also needs to be able to speak the same bus protocol
than the flash chip that you want to flash. Common bus protocols are
parallel, SPI, FHW, and LPC. Chip with different protocols can exist in
the same chip package .
The first case doesn't permit you to recover from code that isn't able to boot
your mainboard.
The second case required an extra mainboard that I didn't have: The older
mainboards that I had didn't have the same connector, nor compatible bus
protocols.
A custom external programmer was then the obvious choice, but I had no
supported devices.
I however had a GNU/Linux embedded device (The bug 2.0 from Buglabs, which I
still have and use). This was a device targetting the kind of people using
Arduinos, but unlike arduinos it ran GNU/Linux and could be programmed in
java. It also had several modules that could be plugged in it, like a GPS
module, some sensors, a screen, and so on.
I won the first version (The bug 1.3) of the device years before at the FOSDEM
conference, in Belgium, and since I have been participating a lot and having
fun in the Buglabs community, I was sent the new WiFi version, and then the
new 2.0 version that was totally redesigned.
Beside the non-free WiFi firmware, no non-free software was required to make
the hardware work. Even the java stack was free software.
For their previous devices, since the official java was not liberated yet they
used the free software alternatives. Once liberated they funded the port of
the liberated version to ARM and used it.
One of the modules you could plug into was a breakout modules (it was called
the Von Hippel module as a reference to Eric Von Hippel). The pins that were
available included the SPI pins.
In theory I would then just have to wire a DPI-8 connector to it somehow,
cross-compile flashrom and run it.
When trying that, it didn't work.
Flashrom developers in the "#flashrom" IRC channel helped extensively to
verify that the hardware connection were fine and ended up making me test a
patch for flashrom which made it work.
So to do the numerous tests, each time I powered on my desktop computer, took
out the flash chip, did the tests, and before shutting down the computer, I
made it reprogram the flash chip with the BIOS image.
This prevented from functionally breaking the computer since at some point
reading the flash chip corrupted it. At the end I found that the real issue
was fixed in the mainline linux kenrel, so I backported the patch and made
Buglabs integrate it in their kernel modifications.
Later I also documented how to use the openmoko debug board as an external
flash chip programmer, and even wrote a naive firmware (with avr-libc) to make
the AVR arduinos behave like a flashrom compatible flashrer: Flashrom has a
protocol made for such case and I only had to implement it.
This naive firmware was called serprogduino.
Later when a better and more portable firmware called frserduino, for Arduinos
and other microcontroller boards was written by someone else. The interesting
parts of my implementation were merged with frserduino. Because of that my
serprogduino code is now obsolete.
Coreboot: M4A785T-M port.
Now that I had a safe enough external flash programmer, I could finally try to
port Coreboot to the Asus M4A785T-M mainboard.
I already knew the internal serial port connector
pinout as I had used it for some other project
where I attempted to program (unsuccessfully) a
PIC microcontroller to build a Pinguino
microcontroller board. I later learned that there are several standards
pinouts for such connectors. I also made sure that
the serial port was working correctly before proceeding.
The most prominent difference between the M4A785T and the M4A785T-M was that
the former supported DDR2, while the latter supported DDR3.
With the first attempt, I compiled the M4A785T code and tried to modify it to
enable DDR3, unsuccessfully.
Hopefully after flashing it, at boot, I had Coreboot logs appearing on the
serial port.
After working a bit on it, the mainboard was booting but still had huge
usability issues, which I worked on when my free time wasn't took by the other
free software projects I had in parallel:
CPU Frequency scaling was not working
Linux's boot log had critical warnings and required arguments like
pci=nocrs to boot
The graphics was almost unusable: the screen was flickering, and the
computer could even freeze wile changing the resolution.
So I had to work a bit more on it and fix the above. I also enabled external
GPUs.
As of today, some issues probably still remain when using more than 4G of RAM
with 64bit GNU/Linux distributions.
Using 32bit distributions with PAE kernels might
make such issues disappear.
The internal audio also might not work. I used an external USB sound card to
workaround the issue
Coreboot: Lenovo X60.
WIP
After having a somewhat working M4A785T-M destkop, I tried to find a laptop
to run coreboot on. As it was already supported by coreboot, the Lenovo
Thinkpad X60 was a good candidate. At that point adding the support for a new
laptop would have been too much work, and I also didn't have enough experience
with Coreboot to do that.
The issue is that I cound't find any locally. I didn't want to buy one online
either, as the laptop can only be bought second-hand. At the end of the day,
I bought one during a short trip in France.
The internal flashing procedure was complicated,
but it was not something I coun't handle. I started to follow the procedure,
and asked on IRC if the last step was strictly necessary. I was told by
mistakethat it wasn't. So I didn't do it, and at the end of the day, the
laptop woudn't boot anymore.
I then ordered a SOIC-8 clip to recover from that, and I could finally use
coreboot on that laptop.
However I wasn't fully satisfied, because, to have display work before the
Linux GPU driver is loaded, you needed to extract proprietary software from
the BIOS and include it in the coreboot image you flashed.
This proprietary software is called by several names:
Video BIOS
Video Option rom
VGA Option rom