Free software projects I participated in:
GNU/Linux on smartphones:

I started to seriously contribute to free software after buying the Openmoko Freerunner (also called GTA02).
I started by adding games and communication software to SHR(the GNU/Linux distribution I used on the Freerunner), by adding packages upstream, in OpenEmbedded.
At that time SHR wasn't very stable(here it means that it had many bugs making its use difficult). Because of that I was involved in fixing many of such bugs.
In my opinion, SHR had a huge number of bugs because it was based on many unstable software. At that time:

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: 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:

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):

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:

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 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:

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:

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.


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: