Tag: Newsletter and status updates

Replenishing the inventory — The new Librem 13 to be manufactured and shipped through the spring of 2017

True to the promise we have made last month, we are thrilled to announce that today, February 15th, 2017, we are placing orders throughout our supply chain for all components needed for the Librem 13 v2 to begin shipping-from-inventory in April-May onwards! This comes after months of efforts to:

  • upgrade parts of our supply chain, case, backlit keyboard, kill switches, and battery;
  • close investment to place a large-enough order that we can have inventory to ship directly from.

This is a critical step. Future Librem 13 orders, from April-May onwards, will only take days to fulfill. Incrementally throughout 2017, this will become the way we fulfill orders for all our existing products.

A last minute opportunity to hop onto this batch

As we are purchasing supplies to create a large inventory of Librem 13 v2 units, any extra Librem 13 orders placed between today and March 15th will be added on top of this large order and can thus be expected to ship at the same time (estimated time of arrival to you: April-May, 2017). So if any of you were waiting for the opportunity to buy units that would ship quickly to you, now is your best opportunity—and you’ll be supporting us in the process, creating a virtuous circle. Please spread the word to those around you as well!

Will this batch ship with coreboot preinstalled?

Most likely. We will try as much as possible to squeeze this into the manufacturing schedule as we are nearing completion on our coreboot porting and validation for the Librem 13 v1 (more news coming soon), but we’re not making hard guarantees about having it ready just yet. If the timeframe is too tight to preinstall it on units to be shipped in April-May, we will offer to have your order wait until we can pre-install coreboot, or provide you with tools and instructions to install it yourself through a simple software update.

What about the Librem 11 and 15?

Our 13″ laptop being the most popular model, we’re fulfilling orders for this product line as the first batch of 2017, simultaneously creating inventory for future Librem 13 orders. For those who have preordered Librem 15 and Librem 11 units, you will have to wait a little bit longer, but not very long: this new Librem 13 batch, and our ability to finally ship the Librem 13 from inventory, will help us gain the financial leverage we need to do the same for the Librem 11 and Librem 15 soon afterwards. We’re hoping to achieve this during the beginning of the summer (or earlier). We will keep you updated on our progress—for now, we just need to be careful and do things one step at a time.

Thanks for your support!

A new PureOS website

2017 new pureos websiteI’m happy to announce that I have put together a new website dedicated to PureOS, with its own domain name: https://pureos.net

I created the PureOS website from scratch and made sure that not only is PureOS freedom-and privacy-respecting, its website would be as well.

  • It enforces HTTPS.
  • It is Icecat and Tor friendly.
  • There is no javascript at all—the interactive top menu that is displayed on small screens (mobile / tablets) is only made of CSS (with the checkbox trick)!
  • At the moment it doesn’t use any backend/framework (it is pure HTML), but I am also working on a small PHP backend that would handle very simple freedom-respecting templates as well as translations, following LibreJS rules for JavaScript usage. This backend is not complete yet but it will be released under a GPLv3 license.

Don’t hesitate to download and try PureOS! Your feedback is more than welcome as we want this fully free distribution to be as user-friendly and freedom respecting as possible. Those two goals are compatible.

I believe the world is reaching a point where the lack of freedom is starting to become noticeably less comfortable than the virtual comfort promoted by restrictive software makers. More and more people feel concerned about privacy, freedom and ethics in general. Most of them are beginning to understand why Free Software is so important (I was/am one of them!) The problem is that many people out there are under the impression that they are not “technical” enough to run a free OS like GNU/Linux, and so, they just give up… we must convince them that things are moving forward in the world of software freedom and that PureOS is as respectful of their freedom & privacy as it is modern, full-featured and easy to use by everyone.

Librem 13 coreboot report – February 3rd, 2017: It’s Alive!

2017-01-24--11.41.34 librem 13 memtest with coreboot
Memtest with coreboot on the Librem 13

Hi again everyone and welcome to the “Good news” post!

It’s been 3 weeks since I wrote my last blog post but this is going to be a short update, in big part because I’ve spent the first two weeks sick in bed and thus wasn’t able to do much at all. However, in the last week I did manage to make some big progress, and the result represents such a great milestone that it warrants a blog post of its own. And, well, I doubt many will complain about not having to read through a wall of text for today’s blog post 🙂

So the good news is: coreboot is working on the Librem 13. The laptop boots into Linux and most things are working! The only issue I have found so far is that the M.2 SATA port doesn’t seem to work properly yet (see below for more info).

Getting video output


You may remember that, at the end of my 2nd blog post, I had finally managed to build coreboot with all of the binary blobs included and it should have worked but it didn’t for “some reason”, so I was going to try to enable debugging to see where it froze.

After installing the “Screwdriver” image on the BeagleBone Black and enabling the EHCI debugging in the coreboot config, I was able to get the debug output from coreboot. It was really quite easy to achieve. The screwdriver image for BBB is pretty much a “boot it and it will Just Work™” thing, no configuration or app installs to do on it. As for enabling EHCI debugging, it took me a couple of tries because I had to enable two options in different config menus, not just one (enable EHCI log debugging, then enable the option to send the log via USB), but thankfully the wiki page explained that so once I followed the docs, it was quite simple. And for the curious/future reference, the USB port which outputs the EHCI debugging is the one on the right side of the laptop.

Once I had the boot log from coreboot, I noticed that it hadn’t frozen anywhere, the last line was about coreboot launching the payload SeaBIOS, so coreboot did everything up until the end. I checked the various steps and it had initialized the RAM, the refcode, the VBIOS, etc. I figured, “Maybe it’s a configuration issue”, so I checked my lspci output from before, and saw that the VGA Controller PCI ID was “8086,1616”, then I went into the coreboot config and saw that it was set to “8086,0406”. So I changed that, and flashed coreboot and when I booted the machine, the video controller worked and I saw the SeaBIOS prompt. Hurray!

The Curious Case of the M.2 SSD

Unfortunately, once I tried booting Linux, it failed with a “Read Error”:

After spending some time trying to figure it out and not being able to (there is no “Read Error” string or anything that could print such a string in the SeaBIOS code, so I couldn’t track down where the error came from, and there is no EHCI debug since coreboot is already done booting and the issue is from SeaBIOS), I tried booting PureOS from the USB installation drive instead, and I was able to boot into the live environment without any problems. Wow, first success! PureOS is booting with coreboot! There was much rejoicing.

To begin investigating the SSD issue, I used the same set of commands from the Motherboard porting guide and started comparing the results, and there were a few differences, but I’m still not sure what they mean. Here’s an example of some of the differences between the two lspci outputs (the problematic SATA controller) :

L13 M2 SATA coreboot lspci diff meld

For reference, you can see the full lspci output with and without coreboot.

Even after booting into Linux, the internal SSD was not accessible, and ‘dmesg’ was showing errors initializing the SATA controller.

SeaBIOS was sometimes seeing the M.2 SSD (but was never able to boot from it):


Sometimes, it wouldn’t see the M.2 SSD at all:


…and sometimes, it would just show garbage:


However, it had no issues detecting and booting from the USB stick, so I had an idea; I installed a 2.5″ HDD into my Librem 13 and tried that. It was immediatly detected by the PureOS liveUSB. So I installed PureOS on the HDD, and rebooted. While SeaBIOS still didn’t detect the SSD, it detected the 2.5″ HDD and was able to boot flawlessly with it. Still no SSD detection even with PureOS fully booted from the HDD however, and dmesg still complained about various SATA initialization issues.

I took the opportunity to test the wifi, video card, speakers, and everything seemed to work. I then booted into MemTest86+ and tested the RAM overnight. There were no errors after more than 17 hours of RAM testing.

As I booted Linux again I noticed the ME PCI device wasn’t in the lspci output, so I wondered if I somehow messed up the ME partition, therefore I left the computer running for a couple of hours to make sure it wouldn’t shut down (due to ME watchdog), then I noticed something weird: I suddenly had a /dev/sdb* set of devices. The output of ‘dmesg’ showed that it magically was able to detect it somehow and I was now able to access the M.2 SSD.


So I did a few more tests, and it seems that after a few minutes (30 minutes to an hour), the M.2 SSD connector will suddenly start responding and Linux will be able to initialize it and detect/access the SSD. It also seems that suspending/resuming the laptop helps trigger the M.2 initialization much faster. I still have no idea why this happens. And once, it managed to initialize the SSD after only 3 seconds instead of the usual 30 minutes, as you can see in this ‘dmesg’ output here :

2017-01-31 dmesg errors

I have now started reading up on the PCI Configuration space in order to understand the differences in the lspci output and hopefully fix the M.2 issues. My current theory is that since the PCI subsystem ID is different when using the vendor BIOS than from using the coreboot BIOS, it’s possible that the subsystem ID somehow tells SeaBIOS/Linux that this specific SATA controller has a quirk that changes the initialization timings. This is only a wild guess for the time being, hopefully in the next few weeks I’ll understand enough about the way PCI initialization works to be able to figure out what goes wrong.


My current status is that PureOS boots and is perfectly usable, however the M.2 controller doesn’t work reliably. Also, the MEI PCI device as well as the USB EHCI device have disappeared from the ‘lspci’ output (both USB ports are working though). The lspci output is also different for most of the other devices when compared to the original BIOS.

One other thing worth mentioning is that I have stopped using the IC clip already. Since I am able to boot into Linux with coreboot, I can now use flashrom to flash the BIOS directly from Linux and I’ve used it to do my BIOS updates while testing in the last few days. This is great, because not only does it speed up development, but it also confirms/tests the process that existing Librem 13 owners will go through to update their laptops to coreboot.

Here is the Acceptance Test Matrix that I mentioned in my previous article, which I’ve found in an old post on the coreboot blog, where I’ve stricken whatever I have had time to test and confirm as working, and made bold anything known not to work :

  1. Cold boot: memory controller works.
  2. Cold boot: all installed DRAM is online.
  3. Cold boot: graphics controller works.
  4. Cold boot: SATA controller succeeds.
  5. Cold boot: EC controller responds ok to init code.
  6. Cold boot: LCD backlight turns on.
  7. Cold boot: linux boots ok in text mode.
  8. Cold boot: linux boots ok in framebuffer (boot splash) mode.
  9. Cold boot: X initializes the LCD at full native resolution.
  10. Cold boot: X enables hardware acceleration.
  11. Boot time: Cold boot to grub succeeds in less than a set timeout.
  12. Boot time: Reboot from linux back to linux succeeds in less than a set timeout.
  13. Boot time: Power down succeeds in less than a set timeout.
  14. SeaBIOS test: keyboard works.
  15. Grub test: keyboard works.
  16. Grub test: text mode and framebuffer graphics work.
  17. Cold boot to USB linux succeeds. (We plan to use SeaBIOS for boot device selection, barring major bugs.)
  18. Reboot to USB linux succeeds.
  19. EC test: fan spins.
  20. EC test: holding power for >5 seconds forces a power down.
  21. ACPI test: lid switch works.
  22. ACPI test: power button event received ok.
  23. ACPI test: AC power on/off event received ok.
  24. ACPI+EC+battery test: battery percentage works.
  25. Media keys on keyboard work in linux.
  26. Device tests: internal mic, internal speakers, webcam, webcam mic, wifi, bluetooth, hard drive, SSD, SD card, each USB port, headphone jack.
  27. prime95 (one instance bound to each hyperthread) for a fixed time to test CPU thermal management.
  28. glxgears for a fixed time to test GPU thermal management.
  29. During prime95 test, CPU digital thermal sensor should give reasonable results.
  30. Linux suspend ok.
  31. LCD backlight adjustable in linux.
  32. Linux kernel boot messages should not contain too many errors. (Only the SATA errors are appearing)

As you can see we have at least 22 out of 32 items that are considered tested and done, which means we’re at least two-thirds there—most of the other items are probably working as well, I just hadn’t had time to test them yet.

I hope to have the M.2 issues fixed within the next couple of weeks, then, after making sure it is perfectly safe to flash coreboot to any Librem 13, we’ll probably release a beta image for people to test (it will come with plenty of disclaimers though!) After that, I’ll work on disabling the Intel ME (first by using the me_cleaner tool, then testing if it works as expected).

We’ll keep you posted on the progress.

Librem 13 coreboot report – January 12, 2017

Hello again Purists! I’ve made some progress on the coreboot port to the Librem 13 v1 hardware.

logic-analyzer_and_probesYou probably remember that my initial post about coreboot development was mostly about the v2 hardware and all the mistakes I made while getting familiar with BIOS development. One comment I’ve heard on the previous post is that it was over-complicated to use a Logic Analyzer in order to do a dump of the flash. Of course it was over-complicated, but I did it for reasons other than just creating a dump. I did it because:

  • I hadn’t received the sockets/other hardware I ordered.
  • It sounded like a fun thing to do while I wait. And I simply love using the Saleae Logic Analyzer, and I look for any excuse to use it!
  • The logic analyzer doesn’t only give me a dump, it gives me a trace of all accesses, it allows me to see “which offsets are accessed when”.
  • When I see the process of what happens exactly (which bytes are read/executed first, where does it jump, etc.), it helps me better understand the boot process.
  • It lets me see which areas of the flash are ignored/not accessed. That also allows me to see which areas/partitions of the ME region are not protected by a signature (if the reads are not all sequential).
  • If I see the ME code being read in its entirety twice, it might mean that there is a ToCToU exploit that can be used there (signature is checked during the first read, then the ME code is loaded into memory).

So yeah, it might have been overkill, but it was interesting to do, that’s why I did it.

Dumping the Librem 13 v1 BIOS from software

At the end of my previous post, I explained that I had finally found a Librem 13 v1 that I could use. Given how it took us 3 weeks to finally manage to get one, I don’t want to be making the same mistakes this time around and bricking a very hard-to-replace laptop. Therefore, I decided against soldering a socket on the motherboard this time, or to be more precise, I decided to only solder the socket after/if I brick the laptop (once it becomes necessary). So my first task was to try, by any means necessary, to dump the flash contents using software only. Of course, I still did my logic analyzer trace, just for fun 🙂

I found the flash chip to be an 8MB MX25L6406E chip, and the vendor BIOS was from American Megatrends (AMI). aptiov-screenshotSince I knew that flashrom wouldn’t work on laptops (more on that later), the first thing I tried was to find the flashing tool from the AMI utilities. I didn’t know what kind of BIOS I had, but looking at the screenshot from the Aptio-V page, it was clear that it wasn’t Aptio-V, so I had the choice between AMIBIOS or Aptio-4… so I first tried the one for AMIBIOS, I created a bootable DOS USB stick and copied AFUDOS to it… but it failed, then I tried the tool for Aptio-4, it failed, but it gave me an error message that said I need to use the tool for Aptio-5, so I finally downloaded the AFUDOS utility for the Aptio-V BIOS and that one worked (facepalm!). So I dumped my BIOS, success! Hmm, it’s only a 6MB file, weird…

Now, I figured that “It’s nice and all, but I need to be able to do it from a GNU/Linux platform”, because Librem users will be using PureOS so they’d need a way to dump/flash their BIOS from there. Thankfully, I found that AMI also has a tool called “AFULNX” for GNU/Linux, but for some reason it’s not available for download. I eventually found a link to it, which I can’t seem to find again now, but I also found this great article by Roman Hargrave that explained just how “awesome” (emphasis: sarcasm) AFULNX is. To make a long story short, the AFULNX tool will extract the source for a kernel module and try to build it, which will always fail because they are missing an include, then it deletes those source files, so I’d have to be quick enough to suspend the process before it deletes the files, then make a copy and fix the code so it compiles, then I need that kernel module file to be renamed (otherwise on the next execution it deletes it and retries).

Anyway, I managed to run AFULNX and dump my kernel. It’s another 6MB binary, which is weird because I know from the spec of the chipset, that the flash is supposed to be 8MB. So I compare the BIOS I dumped with the one that was dumped with the Logic Analyzer… Surprise, surprise, they are completely different. After a little investigating, I realize they are not so different, but the BIOS dumped by AFULNX is actually the last 6MB of the flash, while the first 2MB were completely skipped. Comparing the images from the v1 and v2 BIOS images, and also looking at the LA trace, I could see that the first thing being read is the offset 0x10, which contains the magic number 0x5aa5f00f in both images, so I figured that the flash has some sort of “filesystem” which itself contains the BIOS file, and that the AFULNX binary only dumps that BIOS file without the filesystem itself. This meant that my dump was useless in the case of a bricked laptop. I needed a full flash image, otherwise I couldn’t recover.

I then started investigating what this “filesystem” is, and I can’t say that I found a lot of documentation! Thankfully, I know the magic number of 0x5aa5f00f and that helped me find some stuff about it such as a patch on flashrom talking about supporting “ROM layout from IFD“, then, I found the magic number in the ichdesc.py from the tool called romdump which seems to be used to split the raw flash into multiple parts (one of which is the 6MB BIOS file from AFULNX), the file calls it the “ICH flash descriptor”… which led me to something called “ich9gen” that is used to generate that structure (so, is it an ICH9 or an IFD format?). Obviously ICH is a reference to the Intel Controller Hub, which I assume is the one parsing that flash structure (but then why does the coreboot developer manual say that the CPU just loads the top most 16 bytes from the flash? That’s clearly not the case since there is an actual structure to the BIOS and the ICH is the one parsing it prior to the BIOS getting executed). Anyway, I eventually figured out that it’s called (in coreboot speak) a “descriptor” which is used to define “regions” in the flash, one of those regions is the Intel ME firmware, another one is the GbE (Gigabit Ethernet) configuration data, which is used to configure the Intel integrated GbE device (it contains the MAC address for example), as well as the BIOS region which contains the actual UEFI BIOS.

So… at that point I still haven’t managed to do a proper full flash dump using a software method, but at least, I have good BIOS dumps from AFULNX and AFUDOS, right? I then decide to use romdump to extract the BIOS from my logic-analyzer dump, and compare the BIOS dump from AFULNX with the one from the Logic Analyzer, to see what kind of corruption I got from the logic analyzer… and when comparing the two, I realize that the BIOS dumped from AFULNX is the one that is corrupted!


In the AFULNX BIOS dump, there were some huge chunks that were all “0xffffffff” but were filled with data in the logic analyzer BIOS dump. Also, There were some differences in some bytes which, when I looked at the full LA trace, I saw those bytes being read about 20 times with the exact same data being returned each time (confirming the data to be valid) and yet, the one from AFULNX was different…

So I compared the AFULNX dump with the bios dump from AFUDOS, and… the files were different! The two BIOS dumps from AFULNX and AFUDOS were not only very different from the logic analyzer dump, they were also highly different from each other, confirming that they were both corrupted. That just makes everything worse… Why would a software-based dump of the BIOS result in corrupted data? And that’s using the official tool!


If the data is corrupted, how can I trust it? Most importantly how can I write to the BIOS if writing might cause it to be corrupted (i.e.: “is coreboot failing or is the image that was written to the flash wrong”)? Since AFULNX is not open-source, I was hoping to eventually reverse engineer AFULNX itself, to figure out what it does and port those “exceptions” (if there are any) to flashrom to make it support the Librem 13 hardware. That would allow the users to dump and write their flash with the coreboot BIOS using the free/libre and open source flashrom tool, but if that data can’t be trusted, it’s unacceptable. I need to find a way to do a proper and reliable dump of the flash.

Interlude: building coreboot

While I was thinking on how to do the dump, I decided to move to something else: building coreboot for the Librem (I had previously built coreboot for qemu, following the instructions on the wiki, but that’s not very helpful for the Librem 13). So I configured coreboot with ‘make menuconfig’, set the mainboard to the Librem 13, and ran ‘make’. Of course, it failed for some magical reason that I can’t remember right now, but after wrestling a bit with it I eventually realized that I was missing the BLOBs in the 3rdparty/blobs directory, and without it, I couldn’t build it. So I tried to disable the blobs from the config, but it still complained. I couldn’t find information on where to find those blobs that it needed, and I was a bit lost in all of that, to be honest. The only information I found was about the binary situation of coreboot but not on how and where to find the binary blobs, what filename to give to the files, in which directory to put them, etc. I’m going to skip ahead now and spare you the details of long nights crying and wondering “What am I doing wrong?” and just tell you that the coreboot project has a separate repository for binary blobs which needs to be cloned into the ‘3rdparty/’ directory (replacing the empty ‘blobs’ directory in it). Also, even if you ask for a fake IFD in the config, removing the need for the descriptor.bin and me.bin binaries, it will still look for the microcode blobs, which is a separate config option (which was causing things to fail for me).

So, the good news is, the CPU microcode blobs are in that blobs repository… but the descriptor.bin and me.bin binaries are not, and those will have to be created/copied manually; they come from my own flash dump and can be extracted using the tool ‘utils/ifdtool’ from my full raw BIOS dump. Great, I don’t have that!

Back to the dump!


Time to try some alternative methods. In the previous blog post, I spoke about the possibility of using an IC test clip (actually, about using the Logic Analyzer’s test clips) and an external power supply to power the flash chip, but I considered that to be a dangerous thing to do (based on some post I read on the flashrom mailing list). It turns out that while I was afraid of doing that, it’s really not that dangerous and it is actually the preferred method of doing things.

  • I apparently got ‘tricked’ into using the socket method simply because I stumbled onto this page in the coreboot wiki and thought that’s what I needed to do.
  • Last week, Zlatan was at the CCC and participated in the coreboot install session, where he got someone from coreboot to dump his flash, compile coreboot and flash it on his Librem 13. It didn’t work, but it was a helpful event because I realized, “If coreboot developers are using the IC test clip and it’s safe, then I probably also should”, so I researched that further and found posts/wiki pages that confirm it to be a good method to use, then I ordered one, received it overnight, and started playing around with doing a dump of the flash using hardware—but without soldering!

With the IC test clip on hand, I started looking for docs about that tool and saw a lot of wiki pages explaining how to do it. Most of them said to use an ATX Power supply to supply the 3.3V to the chip, and to always connect the power line last. So my first try was to connect the IC clip (so easy to use! Wonderful.) to my breadboard with the same FTDI UM232H as before, then disconnect the battery from the laptop, then connect the power line. The LED on the FTDI suddenly dimmed (it is powering much more than just the flash chip), and my PC was suddenly unable to access the FTDI chip. It still recognizes it but it complains about being unable to reset it. So I brought out a second FTDI chip, and used the first one for all the data/signal lines, and the second one for the power line only (and I did connect the ground from both FTDI chips together), but it was failing, it just couldn’t recognize the flash. I eventually realized that the problem was that flashrom was trying to read from the wrong FTDI (since I had two connected to my PC), so once I specified the right serial number to use, it was still failing, this time with “unable to read serial from device”. I suppose that second FTDI was simply draining my laptop’s USB power or something, I’m not sure exactly what the issue was, but I decided to just go grab myself an ATX power supply and use that instead. After I shorted the PS_ON pin on the power supply to get it to turn on, and made sure the orange wires are for the 3.3V power rail, I connected it all and tried again, it still failed! But at least, I was getting a response. I was getting this response from the chip :

RDID returned 0xe1 0x10 0x0b. RDID byte 0 parity violation. probe_spi_rdid_generic: id1 0xe1, id2 0x100b

But once I checked the datasheet for the MX25L6406E chip, it said that the RDID response (the manufacturer/device ID) should be 0xc2 0x20 0x17, and I noticed that 0xe1 is 1 bit shifted from 0xc2, so I figured that the FTDI must be too fast for the flash chip (even though FTDI was running at 30MHz, and the flash datasheet says it supports a clock of 86MHz—maybe only for reads?). I decided to try lowering the clock, so I changed the clock to 15MHz and it worked! So yay, finally, I was able to dump the flash. I did five dumps, and they all had the exact same checksum, that meant that there was no corruption in any of the dumps. Now I can get back to work!

For the curious, here is the command I used to dump the flash:

../flashrom/flashrom -p ft2232_spi:type=232H,serial=FTVDZ6J5,divisor=4 -c "MX25L6406E/MX25L6408E" -V -r v1.rom

I was then able to use the idftool to split the rom image into the 3 regions it contained (the descriptor, the ME and the BIOS regions). It didn’t contain a GbE region because the Librem does not use the Intel network card. I put the right files in the right directories and coreboot finally compiled!

A good scare

Now, before I test out coreboot, I decided to go grab all the information I can on my hardware, so that if something happens, at least, I would have that. so I went to the Motherboard Porting Guide on coreboot.org, read it, installed all the dependencies, then after quickly looking at the commands that I’m told to copy-paste (just some lspci, lsusb, etc.), I proceeded to paste this block of commands in my terminal in order to gather all the logs that I would need :

 lspci -nnvvvxxxx > lspci.log 2>lspci.err.log
 lsusb -vvv > lsusb.log 2>lsusb.err.log
 superiotool -deV > superiotool.log 2> superiotool.err.log
 inteltool -a > inteltool.log 2> inteltool.err.log
 ectool -i > ectool.log 2>ectool.err.log
 msrtool > msrtool.log 2>msrtool.err.log
 dmidecode > dmidecode.log 2>dmidecode.err.log
 biosdecode > biosdecode.log 2>biosdecode.err.log
 nvramtool -x > nvramtool.log 2>nvramtool.err.log
 dmesg > dmesg.log 2>dmesg.err.log
 flashrom -V -p internal:laptop=force_I_want_a_brick > flashrom_info.log 2>flashrom_info.err.log
 flashrom -V -p internal:laptop=force_I_want_a_brick -r rom.bin > flashrom_read.log 2>flashrom_read.err.log
 acpidump > acpidump.log 2>acpidump.err.log
 for x in /sys/class/sound/card0/hw*; do cat "$x/init_pin_configs" > pin_"$(basename "$x")"; done
 for x in /proc/asound/card0/codec#*; do cat "$x" > "$(basename "$x")"; done
 cat /proc/cpuinfo > cpuinfo.log 2>cpuinfo.err.log
 cat /proc/ioports > ioports.log 2>ioports.err.log
 cat /sys/class/input/input*/id/bustype > input_bustypes.log

And only after I pasted it, I saw the next line in the wiki (below the block of commands) that says, “Save all logs in safe place, and also rom.bin file.”, and noticed that flashrom is used in there too, but since I knew flashrom typically doesn’t work on laptops (as explained in my last blog post) I assumed that command probably just didn’t work and there would be no rom.bin… until I saw the option given to flashrom: laptop=force_i_want_a_brick


I was half horrified, half amused—this seemed like a ridiculously dangerous thing to put in a long “to be copy/pasted” block of seemingly harmless commands. “Those options shouldn’t be part of a script, they should be set consciously by the user after a big warning!”, I thought. I later discussed this on IRC with the coreboot developers; while most agree that the risk is minimal and it is fairly safe, it was also agreed upon that the option shouldn’t be there in the wiki because of the risk to the user. So that will change soon (if not by a coreboot dev, then I will edit the wiki to add clear warnings).

Thankfully, the resulting “rom.bin” had the full 8MB BIOS dump in my case, and it was all correct (I later compared it with my dump made with the IC clip, and it was almost identical, small differences must be due to the ME constantly writing data to the flash and thus changing some bytes). And so it seems I can indeed dump the flash from software only. Whew!

After some research and discussion on IRC, it turns out that the big problem with flashrom and laptops is the EC (The Embedded Controller), which handles battery charging, the power on/off events,etc..) : if the EC is reading the flash, then you can get some conflicts. Sometimes the EC will appear as a fake flash to the PCH and act as a proxy, but either way, the real problem is just the conflict between EC and PCH trying to access the flash, and it happens to be safe on the Librem 13 because the EC is using a seperate flash chip instead. An old blog post from 2015 on the Purism blog confirms that. So, no more need for AFULNX (or reverse engineering what it does to bypass the EC): we can certainly use flashrom to dump and write the coreboot update to the Librem 13 laptops.

Finding Nemo and Dory: the MRC and the VBIOS

I then used my IC clip setup to write the coreboot image into the flash, and turned on the laptop. The laptop stayed on, but the screen remained black. I asked around on the coreboot IRC channel to get some pointers. After posting my config file, I was told that I am missing 2 important items: the mrc.bin binary blob, and the VBIOS (Video/VGA BIOS); without a VBIOS there would be no graphics support, and without mrc.bin there would be no RAM. So I started searching for this “mrc.bin”, and found very little information on what is “MRC”, what it is for and where I can get it. Thankfully, the folks on IRC were very nice and helped me figure things out.

The MRC blob does the RAM initialization, and it is necessary for the Broadwell architecture to use MRC.bin because there is no native memory init support in coreboot for Haswell/Broadwell chips, unlike older Intel chips. From my understand, it’s in some kind of Google-specific format or that Google is the one creating those mrc.bin binary blobs, and apparently, it can’t be redistributed, but I’m not sure… So I have 3 options, either use the provided MRC.bin from a chromebook’s (with similar chipset) coreboot but not be able to redistribute it (users would have to extract it from the chromebook bios image themselves), or I could use the Intel FSP, but support in coreboot is incomplete, so I’d have to add the support for it somehow, or reverse engineer the memory initialization and re-implement that in coreboot natively. I think reverse engineering it may be the best thing for the future, but for now all I want is to get this running as fast as possible, so I’ll go with the MRC solution for now.

  • In any case, I couldn’t just download the mrc.bin file from somewhere, and it was not in coreboot’s blobs repository either. It’s apparently the same blob as the one used in the Google Chromebook Samus which uses a similar Broadwell chipset, all I needed to do was to run the ‘./utils/chromebook/crosfirmware.sh samus’ command which would download the chromebook recovery image for the Samus device, and extract the BIOS from it. Then I could use cbfstool to extract the mrc.bin binary from it as explained in this commit (see additions to the README file). Unfortunately, cbfstool would refuse to extract/print the BIOS because it couldn’t detect it as being a coreboot BIOS. Thankfully, someone on IRC (coolstar) quickly told me to use ‘-r BOOT_STUB’ option which fixes things. Once I did that, I got the mrc.bin file.
  • Then I was told I would also need the refcode… “What is the refcode?” Well, they didn’t know, and it doesn’t seem to be clear either from the coreboot config help page, as it only says it’s an “external reference code to be put in cbfs” (by the way, cbfs is the coreboot filesystem which contains all the coreboot code and blobs, etc..). Eventually, I found some email on the U-boot mailing list saying that the Broadwell chipsets need an additional reference code to be executed in order to initialize the PCH. So I extracted the refcode binary blob as well and added it to coreboot.

The VBIOS, on the other hand, was the easy part. I followed the instructions from the coreboot wiki, I tried the bios_extract method, but it couldn’t recognize my BIOS as being an AMI BIOS, so I looked in the bios_extract source code, and figured out how it detects the BIOS vendor (it looks for specific strings in it), and I realized that my BIOS didn’t fit (it didn’t have anything close to those strings at all) and it wasn’t a simple bug to fix it and make it work… so I figured, maybe it’s considered a “UEFI” bios, so I followed the “UEFI method” which uses the UEFITool, so I installed it, ran it, gave it my vendor BIOS, and it recognized it as a UEFI bios and showed me a tree of “lots of stuff”:


To find the VBIOS, the wiki says to:

* Look for the “CSMCORE” DXE Driver ? usually having the hash ‘a062cf1f-8473-4aa3-8793-600bc4ffe9a8’?
* Search for text “VGA Compatible BIOS” (uncheck unicode)
* Search for text “PCIR” (uncheck unicode)

And so, I did, I found the DXE Driver called “CSM DXE” with the correct hash. I thought that I would then open that item and search for “VGA Compatible BIOS” in it, but nope, when I did the search, it gave me a completely different module, and when I searched for “PCIR” it gave me a bunch of different modules which matched… and I had no idea what to chose. I made my choice on the single result from “VGA Compatible BIOS” and extracted that one. I tried it and it didn’t work, so I wasn’t sure if it was right, but it felt right. Eventually, I put back my original vendor BIOS on the flash, booted the Librem 13 into PureOs, and used the “extraction from mapped memory” method to grab the VBIOS directly from GNU/Linux. As I compared it, it was identical to the vbios.bin that I extracted from UEFITool, so I at least knew that I had the right file.

Next steps

Going deep.I now have coreboot with the proper descriptor, ME regions, VBIOS, MRC.bin (and refcode), but I don’t know yet why it still doesn’t boot. The next step for me will be to see how I can debug it. There are some ways to debug coreboot but I haven’t looked at them yet. There’s an old blog post about debugging coreboot on the Librem 13, but I’m not sure I’m in the mood to be soldering on the LPC lines (and where are they?), but Zlatan in the CCC coreboot session said that the coreboot developer was able to debug that it had stopped at the vga init stage for him (they didn’t have the VBIOS, I think), so there is obviously going to be a way to do that, and I doubt they soldered on the LPC lines in the middle of a conference. I think it’s safe to assume that I could use a beaglebone black (which I have already) and use the EHCI debug port to capture debug information. That will be my challenge for next week and once I achieve that, I will be able to debug what happens and hopefully figure out what went wrong and fix coreboot so it can boot the Librem 13!

Now, there are still some questions that I needed to know.

  • For example, assuming I get coreboot to work on my Librem 13, how can I know that it’s doing it’s job? I need a checklist of what coreboot is supposed to be doing and a way to check if it does it correctly. Thankfully, I found this old article that lists a checklist of 32 items for the Librem 13 coreboot port to be considered done.
  • I also wanted to know what are the risks to the motherboard if I have a wrong configuration in coreboot, are there components that could get fried? I got the answer today from IRC (thank you agra, avph, felix_, icon, for all the help), and the answer is that it’s “highly unlikely” that I could damage the board, although it is possible, such as supplying a too high voltage to the memory controller. Most boards are safe however, as the voltage regulator would not allow such things, but some motherboards might not be as safe as others, so I’d need to check the voltage regulators on my board to see what kind of values they allow.

So, now, I feel much more at ease with everything. My knowledge is of course still quite incomplete, but I don’t feel as blind as I felt last month, and I have a clear path towards what I need to be doing. Hopefully, I can find out easily how to enable debugging next week, figure out where everything went wrong, fix it, and “Tada! coreboot works!” But yeah, it’s probably going to be a little more complicated than that 😉

Diving back into coreboot development

Hello Purists!

Let me first introduce myself: I’m Youness Alaoui, mostly known as KaKaRoTo, and I’m a Free/Libre Software enthusiast and developer. I’ve been hired by Purism to work on porting coreboot to the Librem laptops, as well as to try and tackle the Intel ME issue afterwards.

I know many of you are very excited about the prospect of having coreboot running on your Librem and finally dropping the proprietary AMI BIOS that came with it. That’s why I’ll be posting reports here about progress I’m making—what I’ve done so far, and what is left to be done.

The first priority is to test and finish the initial port of the Librem 13 v1 that coreboot developer Duncan Laurie started (with one of the 4 librem laptops that Purism donated to the coreboot team back then). The second task will be to port our newest Librem 13 “v2” hardware prototype to coreboot. In order to do all that, I have to learn a lot about the BIOS, coreboot internals, and general hardware initialization on modern computers. I have started the learning process at the end of November, and I still have lots to learn.

Today’s progress report is quite lengthy, so if you’re not interested in the technical details, here’s the “TL;DR” version:

  • I’m still in the early stages of my learning curve.
  • I’ve just received the hardware, so I can now start experimenting/testing coreboot on it.
  • I want to proceed very carefully and not rush anything, in order to avoid making any irreversible mistakes and to make sure that nobody bricks or somehow damages their laptop when the update to coreboot is made available (the good news is that it will be possible to update the BIOS on your machine from software only).

Read on for the details of my progress since I started.

Initial Research

I have a diversified low-level development & reverse engineering background, but I have never had the chance to learn about the details of the boot process on a common PC before, so my first task was to learn about it.

Overall, I’ve been a bit disappointed in the lack of clear and understandable information on the process that happens at boot. I was hoping to see some sort of “BIOS for newbies” guide somewhere, but unfortunately, it isn’t that easy 😉

If standard “applications” development is like surfing and middleware+kernel development is like snorkelling, the world of coreboot and BIOSes is a bit like diving to the very bottom of the ocean—a vast and mostly uncharted territory, full of highly complex systems that make you wonder about how it all works. And you must be careful not to step on a stingray.

Going deep.

On the coreboot wiki and associated websites, there is a lot of information that merely triggers more questions in your head. For example:

  • The CS:IP value at boot points to 0xFFFFF0 and that should point to the top of the BIOS, but how does the CPU map that address to the SPI flash rom, does it get read and stored on RAM (obviously not since the RAM is not yet initialized) or is that segment special and automatically triggers hardware-based SPI reads from the flash when accessed ? Does this mean that the CPU itself has a hardware controller for the flash? or is that the super I/O in which case how does the CPU tell the super I/O to do those reads?
  • What about the actual filesystem in the flash, who parses it? Or is that irrelevant since the CPU starts at the top of the BIOS image and the filesystem headers/etc.. is at the bottom (that turns out to not be true since the filesystem magic at offset 0x10 is the first thing being read at boot) ?
  • What is the checklist of things that the BIOS needs to initialize, and how does the southbridge/northbridge/superIO affect it?
  • Assuming I have a superIO with part number ABCD1234 and coreboot supports ABCD1233, what should I be looking for (in the datasheets, presumably) in order to know what to change to make the new chip supported by coreboot?
  • coreboot also uses “device tree” files which appear to be a major component in porting a new board, and pretty much all the documentation I found on those files, their purpose, and their syntax boils down to, “Read the source code for the device tree compiler to understand how it works”.

I also watched a few youtube videos from coreboot developers giving talks at various conferences, and while that was very interesting and educational, it was mostly meant to promote coreboot, or to talk about its history or talk about the higher level rather than the details. There is one talk about coreboot internals, but it seems to be lower level than what I need right now.

Maybe there is good documentation that answers my questions but I just haven’t been able to find it yet, either because I’m not so good with searching, or because I keep getting lost and distracted whenever I search for something. While I complained earlier about the lack of documentation, I feel like I need to clarify here: there actually is a lot of documentation, the problem (when you’re not encountering an area with missing parts) is that it’s easy to get lost and, globally, it is hard to figure out what to read in which order. In various cases the amount and complexity of documentation is simply staggering. Every time I find an interesting document, I start reading it, it starts referencing things (and there are a lot of acronyms in this world) that I never heard of before, so I start researching that, and I find 100 documents to explain what it is, and they either give me the short description (useless) or the detailed technical description, which is another hundreds of pages of documentation, that itself, references other things that I need to research again. Rinse, repeat until exhaustion.

  • One good example is this Motherboard porting guide page which I would have loved to find early and I didn’t stumble on it until my 3rd week of research, even though it’s right there on the Documentation page, but I didn’t see it because that Documentation page first lists a lot of other pages, such as “Creating valid IRQ tables” which led me to research IRQ tables, and PCI devices, and how they work, and what is an IRQ port, and how the interrupts work, etc. then I saw the link about how to solder a socket to your board, then I saw/read a dozen other articles before scrolling down and seeing the motherboard porting guide link which I needed.
  • Another example is that I found various 1000+ pages datasheets from Intel and other whitepapers/articles on the boot process, but there’s no way I’m going to be able to read and understand all of that (without forgetting 99% of it in the process). I usually learn by experimentation, so I saved those documents for later reference and kept researching.

As you can see, we’re in the paradoxical situation where we sit between two extremes: on many areas there is a certain lack of documentation (or missing parts, or hard to find docs), while in other areas there is an excess in documentation, and I can’t seem to find any docs to cover the middleground—some kind of comprehensive Introduction to Everything that doesn’t skip over all the important bits, without letting/requiring you to stray away from the doc.

To summarize: I’ve learned a lot, about the hardware, about the boot process, and about coreboot itself, but I still have a lot of things to learn.

Adventures in Hardware Land


Probing the Librem 13 v2 prototype

I received the Librem 13 v2 prototype hardware fairly quickly, and my first task was to try and dump the BIOS from it. The BIOS that came with it was from InsydeH2O, and when I tried to run flashrom to get it to dump the flash, it failed and gave me an error message saying that flashrom does not support laptops (due to possible EC conflicts) and that I must use the official tool for reading/writing to the BIOS.

Unfortunately, I couldn’t find an InsydeH2O flasher tool that worked on the machine. I did find the (apparently) appropriate tool but it wasn’t working for me for some reason, so I decided to do things a little differently.

First, I identified SOIC8 chips on the motherboard using a digital microscope, and found the one which I assumed was the BIOS then connected it to a Saleae Logic Pro 16 Logic Analyzer.


I was able to get a nice trace of the first 10 seconds of boot, showing the BIOS being read. Now I had to make sense of that, so I’ve read parts of the chipset’s datasheet and wrote a script that parses a .csv file generated from the Logic Analyzer and outputs the entire SPI command trace with data and rebuilds the data into a single buffer (I’ve pushed my code to Github if you want it). I was then able to get a nice image of the flash. Only about 43% of the flash was dumped, but it was all that was needed to boot the device, so I assume the data that was not read is simply unused portions of the flash.


Unfortunately, and I did not know that yet, the data that was read was corrupted. The reason is simply because the logic analyzer wires might have introduced crosstalk and added noise to the data, due to the relatively long wires being used—considering that this is running on 50 MHz, the chances of noise were higher, causing the data to be slightly corrupted. You’ll soon know why this is a problem!

I now (presumably) had a nice dump of the BIOS on hand. Although it was all the data needed to boot the PC, it was still only 42.8% of the actual flash data, so I would have had to do a new and more complete dump, but I didn’t know how I could achieve it without powering the chip:

  • If I turn on the laptop, so the flash is powered, then I can’t talk to the chip because the Southbridge is already controlling it and driving the pins high or low.
  • If instead, I keep the laptop off, and just power the chip, then I will be powering the entire 3.3V rail of the laptop, which could half-boot some other chips, and that just didn’t sound like a good thing for me to do. I didn’t want to be injecting 3.3V into the motherboard while all the other power rails are off, as it might fry some components (maybe not, but I don’t want to run that risk). I’ve seen others mention that they did exactly that (provide external 3.3V power to the chip in order to read it while the PC is off) in the coreboot mailing list and old blog posts, but I was too worried to attempt it myself, considering this is pretty much the only v2 hardware available right now.

So the only solution left for me to finish dumping the BIOS was to remove the chip from the motherboard and use an external flasher to dump it.

Preparing for transplants

I already had plans to replace the SOIC8 flash chip with a socket, because I wanted to have an external flasher and the ability to test my BIOS easily while developing coreboot—otherwise, as soon as I’d flash a bad BIOS, I would run the risk of bricking the laptop.

So the first thing I built was an external programmer, which consisted of an FTDI UM232H board in a breadboard, with a SOIC8 socket soldered on this SMT breakout board from Adafruit. Then I wired everything and tested using some spare SOIC8 flash chips I bought and flashrom was able to read/write to the chip without problems.


Once that was done, I took every precaution possible before attempting to replace the flash chip on the motherboard itself. After all, I’m not purely a hardware guy—you could say I’m a software guy who plays around with hardware. Thankfully, in the past few years, I’ve learned some soldering skills, but looking at that incredible motherboard was scary. I mean, look at this miniature piece of art, this is what I had to de/re-solder:


I know the popular method for desoldering a multi-pin chip is to use a heat gun, but I couldn’t see how I could put any kind of broad heat on that area without all these incredibly small resistors being melted and blown away by the hot air. Those resistors looked incredibly small and fragile, and I didn’t know if there were some components on the other side of the PCB that would just fall off the board due to gravity, so the heat gun was not an option.

I started looking for alternative methods to desolder such components and found this video on how to use a copper wire to lift the pads of the chip while desoldering. I planned to do that, so I first started by soldering one of the spare SOIC8 flash chips I bought with the SOIC8 breakout board, then tried to desolder it, but it just came out by using the solder wick, so I didn’t even get to try this new method. I tried to desolder using the solder wick on the flash on the motherboard as well, but that didn’t work, so I tried the copper wire method… and it didn’t work either. But while trying to do that, I noticed the chip moved easily, so I decided to just spam both sides with solder and remove it that way. It only took a couple of seconds to get it removed! And thus it went very easily, and it was clean, and it was great, and there was much rejoicing!


No notable damage to surrounding areas, besides the plastic vent grid that had to be damaged a bit by the soldering iron (there was no way around it, and it was needed for the socket to fit anyway) and some slight damage to the ground pin from the motherboard—thankfully, the ground pad is still usable since it remained attached to the motherboard even though the pad itself lifted off the board.

Strange things happen

As you know, by that time I already had a working “external programmer” setup, so I removed the solder from the pads of the original flash chip, put it into the socket on the breadboard, and tried to dump it… but flashrom couldn’t find the chip. No problem; I put the flash chip that I had before (with which I had just tested the working programmer 5 minutes earlier)… and it wasn’t working either! Odd. I assumed some wire got disconnected, so I checked everything twice, but nothing was wrong, so I put back both chips and both were unreadable. I grabbed a brand new chip from the tube I got, and tested it, and it worked. So, for some reason, both the original flash chip from the laptop as well as another flash chip which was on the breadboard (away from the laptop) have decided to both become completely unresponsive within 5 minutes of them being both working. “Hmmm.”

The only explanation I see for this would be some kind of ESD (electro-static discharge) that damaged the chip, but this wouldn’t make sense either because, first of all, I was wearing an anti-static wrist strap (for the first time in my life, because even though I never damaged anything with ESD before, I didn’t want to push my luck with this one-of-a-kind prototype laptop) and, secondly, if it was an ESD it should have damaged one chip—not two—considering that I wasn’t touching both at the same time. I had also disconnected the battery from the motherboard before attempting any work, so I don’t think I fried the chip by causing a short circuit with solder while desoldering (and that still wouldn’t explain the second chip from the breadboard also being damaged). I guess this is one of the big unresolved mysteries of life: why did the chicken cross the road, and why did those chips self-destruct?

Oh well! Not a big deal, right? I grabbed a new chip, flashed it with the dump I had made using the logic analyzer, and put it into the laptop… Except it didn’t boot.


And that’s why I spoke earlier about the data getting corrupted. I eventually changed my code to see if there ever were multiple reads of the same addresses, and to compare the values between the two reads when that happened, which confirmed to me that there was indeed corruption, since there were a few ranges where the data was read more than once and it returned different results in multiple reads.

I know the socket on the Librem 13 v2 hardware is properly soldered though: if I put a blank flash the laptop shuts down immediately after turning on, but if I put the corrupted flash in it, it stays on, the keyboard backlight is on, but the screen never turns on and the laptop doesn’t boot.

So, one week in, and I already “broke” my v2 hardware—but thankfully, it’s nothing major, at least not anything like what I was imagining (lots of resistors/components desoldered and loose, scratching the board with the iron, dropping a huge bead of solder somewhere on the MB, or shorting some pins that would make the motherboard throw lots of smoke on first boot, etc!) I just need to get a copy of the original BIOS, or maybe try to experiment with coreboot and gradually fix things until I get things working.

Getting the Librem 13 v1 hardware

Through all this, I had not yet received a Librem v1 laptop for testing the existing coreboot port. Remember my statement at the start of this post where I said that the first priority is to get the existing coreboot port to work on the v1 hardware? Well, to do that, I first needed to get my hands on a v1 Librem 13. Unfortunately, Purism has already sold all of the v1 laptops from inventory (with no plans on ordering new ones since production has moved to the v2 hardware). Thankfully however, after a long wait (3 weeks!) and numerous internal emails, we finally managed to get a hold of one such unit. We had originally planned some complicated swapping (asking James to forfeit his Librem 13 and Jeff to send him his Librem 15 in exchange, which means backups/transfers and complex shipping timing to minimize downtime), until we got a surprise email from Nicole three weeks down the road where she offered to give up her Librem 13 unit, for Science! Nicole said, “The prospect of some progress on the Coreboot front is worth almost any effort so I gladly contribute what I can.”

Wrapping up

As you can see, we’re at the beginning of this new effort, and the Librem 13 v1 is another story that I’ll be covering in the next blog post(s). It’ll be interesting as well, so stay tuned for more news!

Purism Warrant Canary Updated January 1st 2017

Happy GNU year!

Before (or on) the first day of each quarter, Purism, following the general rules of warrant canaries, will update its own Warrant Canary page if none of the listed items occurs.


Warrant Canary, January 1st 2017

  1. We have not placed any backdoors into our software or hardware, and we have not complied with any requests to do so.
  2. We have not received, nor complied with any National Security Letters or FISA court orders.
  3. We have not been subject to any gag order by a FISA court.

The next statement will be published on the first day of each quarter (January 1st, April 1st, July 1st, October 1st). Please refer to the Warrant Canary page for details and digital signatures.

Growing to Ship from Inventory in 2017

Thank you all for supporting Purism, with ordering hardware, donations, volunteering, downloading PureOS, using our products, and of course the kind words. We are excited to finally approach the transition from “build-to-order” (where users have tended to wait months for Librem products) to shipping from inventory, where new users will be waiting merely days for Librem products. This is the most important step we’re taking yet.

To do this, we are leveraging past sales revenue to get investment and a larger line-of-credit, so we can place an even larger order for all the supplies, hardware, and component parts needed to build and house inventory.

The Librem 13 v2 prototype
The Librem 13 v2 prototype

This larger order is expected to be placed in January, and we intend it to include: the Librem 13 v2, the Librem 15 v2, and the Librem 11 v1. There is typically an 8 week lead time for fabrication, which means placing our bulk inventory orders in January will allow us to fulfill the remaining preorders and backorders in March, and ship-from-inventory beginning in April of 2017.

This is a very exciting transition for Purism to grow to meet the demand of users worldwide, and we could not have done this without your support, so thank you again.

Update from the trenches – operations, research and development for Q4 2016

Since our previous status update on manufacturing & shipping operations in August 2016, we had to tackle a lot of challenges in parallel: changing some of our suppliers, preparing new hardware, processing refunds, preparing PureOS 3, deploying new public infrastructure, seeking additional funds to enable us to ship “from stock” in the future, etc. The puzzle had so many moving parts that we really had to wait for dust to settle at the end of November to know where we stand and to provide you with this report.

In this blog post, we’ll be providing a global shipping status update, a quick update on R&D, and we’ll be sharing some great news for those interested in the Librem 13. In the interest of keeping this post short and sweet, we’ll be sending additional details via email to those with outstanding Librem 11 and 15 orders.

Shipped units, happy users

We did a couple of shipping batches for laptops during the winter, and once the Librem 15’s 4K screen supply crisis came to a close we resumed shipping the remaining Librem 13 and Librem 15 “1080p” orders.

As we prepared our new website contents, we created a “Global Shipping Status” page to illustrate how many laptops we’ve been shipping and to give customers a rough approximation of where they stand in the processing queue. We hope to soon replace this page by a personalized, dynamic shipping status page connected to your account and order status.

Until now, it was difficult for the public at large to get a clear picture on our operations and to realize that we were actually already shipping units to customers for quite a while, so these graphs should help set the record straight:


Looking at the two charts above, here are some very important take-aways:

  1. The Librem 13 started shipping fairly quickly after its campaign ended, and continued shipping afterwards.
  2. The reason the majority of the Librem 15 laptops took so long to ship initially was that we kept waiting and waiting for the 4K screens… Purism learned some hard lessons there. That mistake won’t happen again.
  3. The Librem 15’s original order quantity (from the first campaign) has been shipped by now.

So far, the feedback we’ve been hearing from those who received their laptops has been very positive. For example:

…to cite only two. It’s always greatly satisfying to hear positive stories like that. Please don’t hesitate to share yours! Your encouragement is a big part of what keeps us going through hard times.

Replacing weak links in the (supply) chain, preparing for growth

One thing we had to accomplish this quarter was to change some of our suppliers. One of the reasons for that was to have better flexibility and to enable us to build better-quality computers in future revisions.

It has taken us a couple of months to find satisfactory suppliers, negotiate, request and evaluate prototype units (to ensure they meet our quality standards and our particular privacy+freedom specifications), and then evaluate the feasibility of going into a new production run. We are now very happy to say that we have resolved the “manufacturing and logistics” side of the equation.

The other side of the equation is financing: to place a large-enough order to ship from stock, we are in the process of getting a line of credit (loan) to fund inventory. With this, we hope to place a large-enough supply order to finally get out of the chicken-and-egg problem (where many customers want to purchase Purism Librem laptops only if they are available for shipping on short notice, yet this requires inventory, which requires enough orders to create inventory on an ongoing basis).

A new Librem 13

Here’s a sneak peek of the prototype of the Librem 13 “Mark II” that would be replacing the Librem 13 v1 for any future shipments:

This would have very similar specs to the Librem 13 v1, with a few improvements on the casing, backlit keys and better keyboard feel, and a few changes like the location of the hardware killswitches. We’ll be providing more details on that in a separate blog post. We’re hoping to eventually provide a new revision of the Librem 15 as well, for which we will need to get new prototypes and nail down the details and logistics for it.

Progress on PureOS 3 towards distro certification

With the alpha release of PureOS 3 now available alongside our new public infrastructure like Phabricator (see devlog #3), we have started the process to get the PureOS software distribution certified by the Free Software Foundation. PureOS has always been 100% Free Software from the start (stricter than most GNU/Linux distributions, including Debian, Fedora, etc.) and getting official FSF endorsement for PureOS will provide recognition for our work and assurance for users that their operating system respects and enforces their software freedom.

Coreboot Research and Development resumes

In the past, we have promised to work towards liberating the BIOS/UEFI of our Librem laptops, and we’re continuing that commitment. We have previously made some efforts toward porting Coreboot to our devices: we have provided sample Librem 13 v1 laptops to Coreboot project contributors to facilitate this work, and a partial port came out of this initiative. We have also sponsored some developers to try to continue that line of work. In the end, we have been slowed down because we shifted focus on our manufacturing business needs to deliver product to users, and the odd phenomenon where our Coreboot contributors would end up going silent / disappear on us after a while. So we kept looking for someone who could do this work independently, and consistently.

This December, we brought on board a promising independent low-level BIOS/UEFI hacker that will be able to resume the Coreboot-related work, so we hope to provide coreboot for the Librem 13 v1 and v2 to start. Stay tuned for news on that front!

Purism Warrant Canary Updated October 1st 2016

Before (or on) the first day of each quarter, Purism, following the general rules of warrant canaries, will update its own Warrant Canary page if none of the listed items occurs.


Warrant Canary, October 1st 2016

  1. We have not placed any backdoors into our software or hardware, and we have not complied with any requests to do so.
  2. We have not received, nor complied with any National Security Letters or FISA court orders.
  3. We have not been subject to any gag order by a FISA court.

The next statement will be published on the first day of each quarter (January 1st, April 1st, July 1st, October 1st). Please refer to the Warrant Canary page for details and digital signatures.

Purism Devlog #2

Lets start this devlog with some good news, that we believe will make a lot of users happy and that it  will satisfy a few trolls as well. We moved away from Cloudflare. It was creating problems for Tor browser users (which was kind of ironic as we shipped with Tor browser on our machines as default) and the temporary solution was to whitelist all Tor nodes. We are  now finally Cloudflare free. Also our certificates are now from famous and all-loving LetsEncrypt, on all our servers.

With huge efforts to create PureOS infra, we also decided that now is the time for an entire transition. That is why we are moving all our services to a secure facility where we run our own dedicated servers. Fun times! Let us know if we broke  something during our transition! This is all brought to you by ever growing Purism team.

As we are approaching a day when PureOS infrastructure will soon be set up (hopefully in next 2 weeks), we also issue a call for volunteers. There will be wiki (which we need to populate with documentation, tutorials, ideas and magic), PureOS website (anyone eager to try their design and web coding skills?), bugtracker (oh yes, we all need that), code hosting (what would be an Free OS without Freedom code hosting service? 🙂 ) and many more goodies. Also, we issue call for ideas – if you have an idea on  how to improve any of above mentioned things please feel free to share. We want to find out what our users need and we will try to implement that with security and privacy in mind . Our vision and mission is to integrate Freedom, privacy and security. Lets talk how to improve Free software/hardware and society! IRC (#purism on freenode) and feedback@puri.sm are your friends for that.

What would be a devlog without bad news? I don’t have an answer for this but here are the bad news. While regular PureOS 2.1 image installs fine on all hardware (yes, even the NVMe SSDs) the OEM ISO fails. We are investigating this and hopefully we will resolve it this week, stay tuned. I am also very  pleased  regarding bugtracker – while we support people discussing in forums, it is a bit of an overload for our stuff to forward  complaints to us and then we through our support contact them back via forums (or in some cases mails) we must find a way to improve this. After all we are an open community and we must offer transparency in our bug reports, easy searchable by community and our stuff.

What is going on with Purist Services – well, we are issuing a volunteer call for people interested to work and chat with Joey Hess (our lead architect on this). Skills: knowledge about XMPP, OMEMO, IM, voice/audio calls (people that work and use Ring are of high interest to us. At least to our technical lead 😉 ), encrypted mails, UI/UX design (we need somehow to level up GPG usage and without really easy UI we are doomed to fail).

The last but not least – regarding all infrastructure build up, old PureOS infra will be the last to shut down. This means that you will  still have some issues with our archive. although we take all your reports seriously and fix them ASAP and we we are also preparing PureOS 2.2 release with it.

P.S. sneak peak for PureOS 3.0 which will get released with new infra – its codename will be Prometheus! That’s enough juicy details for now!!