Tag: Laptops

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!

facepalm

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!

double-facepalm

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!

ic-test-clip

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

massimo

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

UEFITool

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

2016-12-16-16-25-03

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.

2016-12-21-18-13-25

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.

logic_analyzer_read_commands

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.

2016-12-21-17-52-14

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:

2016-12-16-00-20-19

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!

2016-12-21-17-47-40

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.

facepalm

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!

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:

outstanding-vs-shipped-orders-2014-to-2016-10-annotated

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!

At crossroads for the Librem 15″ 4K: lessons learned from supply chain dependencies

The good news

Over the past few months, Purism has made great strides to improve on its hardware and software offering, as well as making your user & customer experience smoother. Besides shipping a hundreds of Librem laptops to backers (we will give you a better overview of this in a separate blog post with interesting data visualizations):

Over the past year, we have been offering the option to pre-order the Librem 15 with a 4K (UltraHD/HiDPI) display. Our screen suppliers wanted to move to 4K as their standard offering, and sold us that it would be ready in time for us.

While we have been shipping hundreds of regular (1920×1080) Librem 15″ and Librem 13″ models, those of you who chose to order the 4K variant of the Librem 15″ model had to wait for the 4K displays to become available through our supply chain. A couple of delays happened, and we made it a point to always keep you up to date on the situation (as seen here, here and here). This summer, we were reasonably confident we would still be able to ship these 4K models by October this year.

The bad news

football-goal-formations-tactics

Today’s blog post is painful to write but necessary, as it continues our tradition of accountability towards you. Even as we poured our heart and soul into trying to make 4K happen, external factors made plan A, plan B, and even plan C derail. LG (and its subsidiaries) has now let us down, just like Samsung did, putting us back onto “infinite backorder with no ETA”. The difference, this time, is that there are no more “easily” accessible 4K display panels suppliers left to turn to, bringing us back to square one when it comes to this particular component. Everything else in the supply chain, including our own operations, was aligned and going well, so it’s not for lack of work and efforts on our part. Our mistake was to readily believe Samsung and LG on the future availability of their screens.

At this point, we don’t think having you wait any more is acceptable, so we’re giving up on the 4K variant of the Librem 15 for now; we will be providing the regular Librem 15 instead, along with other models and their upcoming revisions. We are going back to “2K” so that we can confidently ship the goods without introducing any further delays undermining your trust in what we’re doing.

Rest assured this not a decision we are taking lightly. We made heavy investments trying to make this happen, and have spent sums that we cannot recoup: approximately $75,000 in assembly line retooling and deposits for 4K screens to Samsung and LG for orders that will, it seems, never materialize. We are trying to negotiate and recover some of the supplier deposits, but at this point we have to consider this money a net loss. On the other hand, we’ve made other investments early in our campaign that were worth it (for example: $50k to place an initial order for rarer Intel CPUs requested by some backers, $25k to retool the motherboard to 6 layers to support 32GB of RAM, progressively growing our team…).

We will be intensifying our product & service development pace, and we are still working on everything else part of our mission (including the Intel ME issue, achieving FSF endorsement of our software and working toward FSF RYF certification of our hardware in the long term). With your help, we can do this.

The updated operations roadmap

"The roadmap", courtesy of our creative director François Téchené
“The roadmap”, artwork courtesy of our creative director François Téchené

We may revisit the switch to 4K later, when we can get absolute certainty about it (no more preorders, we’ll only believe display manufacturers when they have the 4K panels in stock and ready to ship for us immediately), but for now we must regroup our forces to win this war.

Our plans (for the next 12-24 months) are now:

  1. Begin shipping the 1920×1080 version of the Librem 15 in September and into October (instead of the 4K variant), as per the options provided to you further below.
  2. Order enough materials for the Librem 11, 13 and 15, so we can ship from stock (without having long delays discouraging people from buying).
  3. Plan/design our upcoming Purism phone (we will be posting a survey about this soon, stay tuned!).
    In mid-2017, redesign the Librem 13 and Librem 15, including ways to meet the hardware selection criteria to qualify for “RYF” certification by the Free Software Foundation.
  4. Release “Purist Services” (our upcoming secure and private telecommunications infrastructure for you to use).
  5. Launch the Purism phone as an invite-only pre-order campaign.
  6. Launch the new Librem 13 and Librem 15, ship from stock for all orders.

What are my options if I pre-ordered a Librem 15 “4K”?

Should you choose to get the Librem 15 with the 1920×1080 IPS screen as originally planned, which we do have in stock (a bit over 50 units that we can assemble and ship quickly; we will re-stock soon to meet the demand and ship the remainder during September-October), you have the following compensation options:

  1. Maintaining the configuration and pricetag you paid, and getting 150% of the difference in credit for our future products (including our upcoming Purism phone). Therefore, the ~$300 price difference of the 4K screen would become $450 in credit that you can reinvest in any of our future products and services. Besides being a pretty interesting “early bird” opportunity for you from a pricing standpoint, this will help us get faster to the goal of providing the Purism phone and Purist Services infrastructure. You will also get an invitation to be among the first ones to try our Purist Services.
  2. Upgrade your RAM and/or SSD on your Librem 15 for up to $450 in value.
  3. Normal refund of the price difference.

You can, of course, decide to switch to a different product of ours, such as the Librem 11 or 13, but that means you will have to wait a few more weeks than if you were to choose the original Librem 15.

Please contact us at support@puri.sm to let us know what you would prefer us to do with your order.

We’ll need your help to continue this journey.

As always, your patronage is an investment that helps us deliver on our promise and make the case for privacy-respecting Free Software computers. We are very grateful to all of you who are supporting us (through purchases, word-of-mouth, feedback, etc.) and making it possible for us to fulfill our mission. If you have any comments, suggestions or encouragements you would like to share, feel free to send us your thoughts at feedback@puri.sm — or come have a chat with us on the “#purism” IRC channel on Freenode.

todd-weaver-on-the-new-screensavers-episode-65

Purism CEO Todd Weaver interviewed on The New Screensavers episode #65

Purism CEO Todd Weaver made an appearance on the TWiT network on Saturday August 6th, 2016 with host Leo Laporte on the online TV show The New Screen Savers. Todd and Leo discussed Purism’s Librem line of products and what sets them apart from other free and non-free offerings, the importance of Free/Libre and Open-Source software, our operating system and web browser, and Purism’s philosophy and future plans.

Todd spoke with Leo about the hardware found inside our 13 and 15 inch Librem laptops, and how they are as freedom-respecting as currently technologically possible in a modern machine, with less possibility of including a backdoor. Todd spoke about recent Intel processors’ “Management Engine”, breaking down the issue of having a potential backdoor in Intel chips commonly found in modern computers, then proceeded to explain how Purism circumvents this privacy and security issue (see also our related article to learn more about how Purism avoids the Intel AMT remote access backdoor).

Purism hopes to work with Intel to strip out parts of the ME that many computer professionals feel is a privacy invasion, and began a petition that quickly garnered over 1000 signatures.

Weaver explained the goals of our operating system, PureOS, which is to provide an OS that is entirely respectful of your personal freedom, privacy and security.

Additional discussion was had on how we manufacture our own motherboards, how we source hardware (see our business model), the fact that we do not participate in the “surveillance capitalism” commonly found with larger companies, and our future goal of manufacturing a privacy-centric and “no-carrier” phone, providing a set of fully encrypted communication tools.

You can buy these laptops directly from our store. Questions or comments? Let us know at feedback@puri.sm

Purism is combining hardware and software designed to better protect your privacy

When it comes time to purchase a new computer or tablet, often we compare specifications from one computer to the next. We may take a look at storage size, amount of RAM, brand, cost… but we often times forget what is arguably the most important thing when considering a new computer purchase: our data.

Stored on our devices are our private thoughts, likes, pictures, videos, documents and browsing history; collectively our “Digital Life.” In many ways, our computers have in fact become an extension of our own brains. More and more people are beginning to question and inquire further into what companies—that create the applications and operating systems that we use every day—are doing with this data accumulated through their use. Are these companies using our data to market to us, build profiles on us, or otherwise monitor what we do? And more importantly, are our devices secure?

Have you ever really given that much thought?

High end devices such as products from Lenovo, Apple’s Macs, Microsoft’s Surface line and even lower end devices such as Google’s Chromebooks all ship with operating systems that—to one degree or another—are monitoring what you do on your computer. There is much debate as to why, how much, and what precisely are they monitoring with this data, but for some of us, any data monitoring is too much.

Enter Purism.

Purism was created with a belief system designed to combine the most privacy respecting software wrapped in beautiful and well-made hardware.  Simply put: we want you to have the same form and function that you are used to, albeit in a much more private and secure manner. We believe that you and your data are important and that your data should remain yours, and yours alone. Purism does no monitoring or data collection. None. Can you say the same for your current device and operating system?

The Librem line of laptops and 2-in-1 devices come pre-installed with a complete and fully functional office suite. Additional applications are available to provide alternatives to the creative applications from Adobe and other companies. Our web browser, PureBrowser, is built upon the familiar Firefox but with the best privacy respecting add-ons pre-installed. These add-ons block and prevent many forms of malware, ads, and other forms of trackers. Our industry-first Hardware Kill Switches physically cut the electrical power to the web camera, microphone, and Wi-Fi, giving you assurance that no one is watching, listening or hacking you and your computer. These are physical switches, not a piece of software.

It’s become commonplace these days to have to open an account in order to download or use applications. In many ways, gone are the days of application use anonymity… Except when using Purism’s Linux based line of Librem devices. We do not require you to log in or create an account to use any of the thousands of applications available through our store. If you see something that you like, download it and give it a try. They are all free, without having to give up your usage data.

When considering your next hardware purchase, if you have the knowledge and ability to perform background task and Internet connection analysis, we encourage you to take a look at the processes and connections that Windows, OSX or Chrome OS are running on your current device, behind the scenes; these are simply not there with PureOS. Purism has no interest in serving you ads or monitoring what you do. Our business is to combine the best privacy-respecting software into great-looking hardware that will last you for years to come.

We’ve glossed over the minutiae that many computing professionals are already aware of but we hope that this piece provoked some thoughts in your mind about the current state of computing. Got questions or suggestions for us? Send us your thoughts at feedback(at)puri.sm

4K At Last! Purism Librem 15 rev2 4K

We have had a long road to get to 4K in our second revision of the Librem 15 units. This has not been without frustration with supply chain delays, but we are finally finished testing a fully functional 4K prototype that is ready for mass production.

librem-15-rev2-4k-full-1920px

The story to get the 4K panel is full of ups, downs, twists, and turns. When we learned from one of our suppliers that we could get Samsung 4K panels in our Librem 15, we jumped at the opportunity. We prepaid for the panels, moved the Librem 15 line from 2K (1920×1080) to 4K (3840×2160), and asked if backers would like to get 2K or 4K, shipping 2K and holding the 4K until they would arrive, which moved most orders to 4K. All this was exciting, until Samsung’s 4K panels were on backorder, then backorder again, and again. We were in a real bind, because there was no alternative 4K screen, until LG entered the scene. We then requested a sample 4K screen from LG, modified the case and front panel to fit the new LG 4K screen. We then hit an additional delay on funding the screen purchase, tooling, and assembly, since we prepaid for the Samsung panels we had to look at how to cover the additional cost of LG screens. After juggling some pieces, such as refunds on the Samsung screens, negotiating lower cost from the delays with the supply chain to cover the screen price increase, and even supply chain funding, we got the LG based Librem 15 rev2 4k prototype approved and ready for mass production.

librem-15-rev2-4k-right-side-1920px

Now that we are approved for mass production on the Librem 15 rev2 4k, we can provide more accurate dates for delivery to backers as we approach receipt of the panels. LG expects to get us the full panel order within 6 to 8 weeks, and we will then assemble and ship through all our back orders within 3 to 4 weeks. Any new orders will be shipping after September.

Thank you for all the support, and patience, as we have worked through an unbelievably painful process working through the supply chain delays. We have learned a lot through this process, and are going to work even harder to avoid this type of delay ever again. We are looking to remove any supply chain delays in the future by raising funds to be able to order enough product to ship from stock.

librem-15-rev2-4k-left-side-1920px

Newsletter 2016-06-07

1. Thank You!

First off we wanted to say “Thank You!” to all of you for helping build Purism to what it is today, we have a lot more we want to do, and with your continued support we can change the world for the better.


2. This Newsletter List

We are now combining all our lists from our Resellers, Sales, Petitions, Email, Forums, etc. into this single newsletter list we will utilize to keep you informed. We tried very hard to only include those who have opted-in to receive these newsletters, if you wish to unsubscribe just email: announce-leave@announce.puri.sm and you will be instructed how to unsubscribe.


3. Continuing to Ship!

We have been shipping the Librem 13 Laptops, the Librem 15 1080p Laptops, and will continue to ship through the order queue. We are evaluating the first 5 Librem 15 4k Laptops and will provide ship dates for those orders once we confirm them. In related news, we will be seeking larger investment so we can ship from stock for future orders.


5. The Librem 11

A workstation that converts to a laptop, that also converts into a tablet. This is the dream machine for a lot of users. Help support it!

Buy Now


6. Intel “Me-Less” Petition

During our last meeting with Intel, we discussed getting a petition to show Intel how much interest there is to have Intel create an “ME-less” CPU in the future. Please sign it!

Sign The Petition


7. Supply Chain Investment

We want to show our thanks for your support! We’ve deeply value your support of our business over the years and wouldn’t be here without it. Therefore, we want to share our success with you and show thanks for your support.

Invest & Earn Profits

All of us at Purism, are excited to announce our recent partnership with Kickfurther, a crowdfinancing platform to obtain financing for our recent growth as a company. Be a part of our success and earn money while doing so. We’re offering our fans the opportunity to earn 12% in 6.5 months for contributing and supporting us! Our business goes up on the Kickfurther site on Jun 9, 2016 at 5PM EST but we’re granting early access from the above link.

We’d much prefer paying interest to backers than we would to banks.

Signup through https://kickfurther.com/s/2qbt4zz8ls to instantly receive $5!


8. Equity Investment (Coming Soon)…

We are in the growth stage, looking to place much larger orders to begin shipping from stock, which means we must begin to seek investment. We will be sharing this investment opportunity with all our backers, if you qualify to invest we would love to have you on board! More information will be coming soon.


9. A Librem Phone is Coming

We are begining the stages to create a phone, your continued support with our existing products ensure we can create a phone designed to respect users’ rights to privacy, security, and freedom.


Thank you for your continued support!

Purism

To unsubscribe: announce-leave@announce.puri.sm

Librem 15 rev2 2k and 4k Status

We’ve written previously about the delays surrounding the 4k screens from Samsung both in this blog and on social media, and we now have more information that we can share.

We have received stock of our Librem 15 rev2 2k, the 1920x1080p screens, and will be fulfilling orders from that stock in the coming weeks. We are finalizing testing and OS loading this week and next.

We have found an alternative to Samsung for the 4k panels, from LG, so have ordered a handful of 4k prototype panels from LG. This allows us to leverage two suppliers to determine which one can provide us the back ordered 4k panels to fulfill the remaining Librem 15 rev2 4k panels.

The decision is up to you if you would like to accept the 1080p screens or continue to wait for the 4k.

Currently, we are reporting that the 4k screens will be made available to us in the “month of May.” However, considering the past supply chain delays, even with having two suppliers, it is safer to assume user delivery in June.

Your options are currently one of these three choices:

If you originally ordered a 1080p display and were then later upgraded to the 4k display, you will be getting the 1080p screen from your original 1080p order unless you specifically want to want for the 4k.

If you originally ordered a 4k display but are willing to downgrade to 1080p, you may do so now and your order will be filled. We will increase your memory, drive size, or drive type to compensate for the screen downgrade.

We appreciate your continued support and patience with this issue. Many of you have been more patient with us than some of us have been with Samsung. Please write us at support@puri.sm with order details and your choice or any other questions that you may have.