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:

• 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).

• Serious sound quality issue on headphones
• MicroSD compatibilties issues

• HTC Dream
• Nokia N900
• Google Nexus One
• Samsung Nexus S
• Google/Samsung Galaxy Nexus
• Goldelico GTA04

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

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.

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)

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

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.

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

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.

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.
  

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.

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