When the Librem laptops were announced last year, I was quite excited and I ordered both the 15 and 13-inch models. My 13-inch model arrived last week, and I have begun the process of porting FreeBSD to it.
I have to say, I am very excited to finally have a laptop from a fully-cooperative manufacturer, where I can get my hands on all the hardware specs and possibly even upstream fixes. This is a very welcome boon after a decade of having to deal with flaky BIOS issues, black-box hardware, and other difficulties.
The physical laptop itself is very solid and rather light. It doesn’t creak, and the lid stays put even better than a macbook. My only complaints are that the camera/microphone and wireless kill-switches are unlabeled, and that ethernet cables tend to fall out of the drop-down port. Aside from those minor issues, I’m quite pleased with the physical unit.
It’s hard to see the kill-switches in the photo below, but they are on the hinge under the screen.
My only other regret is that the dvorak keyboard option became available after I’d ordered mine. Oh well; maybe I can sweet-talk them into swapping it for me at a conference 😉
It was also very nice to unpack a laptop without implicitly accepting a Microsoft license agreement by opening the box!
BIOS and FreeBSD Installation
The first thing I do when I get a new laptop is poke around in the BIOS menu (no photos yet). The librem has a coreboot port, but I decided to get FreeBSD installed and check the system out a bit before diving into the art of flashing my BIOS, so I was looking at the proprietary American Megatrends BIOS menu. Even still, I was pleased by the features it presented, most notably the ability to set up custom signing keys. I am going to have to do some work on a signed FreeBSD boot and loader chain.
My FreeBSD installation went off without any serious issues. I installed FreeBSD 11 from a bootable memstick option, setting up a pure-ZFS system. I had ordered a 1TB spindle drive and a 250GB SSD. I reserved 48GB of the SSD for swap (total of 64GB memory). I then set up a ZFS pool with the spindle drive as the main storage, a 16GB intent log on the SSD, and the rest of the SSD as an L2ARC cache device. (I will eventually set up the ZFS volume to make all writes synchronous, so as to really use the intent log.) I realize some might consider ZFS on a laptop to be overkill; however, I have found it to be an extremely versatile and stable filesystem. It is incredibly crash-resistant and corruption-resistant, and its snapshotting is invaluable for risky updates. The transparent compression features are useful as well, and can effectively increase your available space by a sizable amount. Lastly, I have used the ability to serialize and deserialize the entire filesystem more than once.
I did encounter one of the issues in this process: a sporadic boot-hang and USB timeout that I now strongly suspect to be a timing bug in the FreeBSD boot process.
FreeBSD did handle the hardware kill-switches rather well (I’ve heard reports of Linux kernel panicking from them). Flipping them off causes some kernel messages about timeouts, but the bus re-initializes upon flipping them back on. If you boot with them off, then flip them on, the kernel detects the hardware properly.
The first thing I do on a new FreeBSD system is grab the source tree and build world, followed by kernel customization. I noticed that building Clang has gotten pretty slow these days (which doesn’t bother me too much; I’d rather the compiler have a lot of optimization machinery than not).
After that, I grabbed the latest ports tree and started building the usual suspects to test the system (also, to get to where I could test X11). I also grabbed Jean-Sebastian’s Intel graphics patch to see if that driver worked with the Broadwell card. Sadly, it didn’t.
Most of the hardware Just Works™, which is nice. I was particularly pleased that all the fn-key combinations work out-of-the-box. I have never seen that happen with any other vendor.
The following is a list of the working hardware:
- The EFI boot/loader
- SD card reader (mmc driver)
- Realtek Ethernet (re driver)
- System management bus and CPU frequency/temperature (smb, smbus, ichsmb, coretemp, cpufreq drivers)
- Intel High-Def Audio (snd_hda driver), though I haven’t tested the microphone yet. Also, plugging into the headphone jack properly switches to headphones from the speakers (I’ve seen that not work).
- Hard Drive and SSD (obviously)
- USB ports
Unfortunately, the Intel accelerated graphics drivers don’t support the Broadwell cards. This will come eventually, but FreeBSD is in the midst of a graphics framework overhaul to better track the Linux drivers. Looks like it’s going to be VESA for now.
There are currently some issues, which I will be working to fix:
- The Atheros 9462 card is detected, but the radio doesn’t seem to be working. The pciconf tool reports a few errors, and scans seem to run, but don’t pick up anything. I have confirmed this is not a hardware issue by booting with a Kali linux memstick.
- Blank screen on resume. My initial investigations reveal some ACPI execution errors during resume, which may be related. I need to get up in the kernel source and add some logging to see what’s going on.
- VESA wierdness with X11. The VESA X driver works mostly, but if you switch back to the terminal, there’s a couple of pixels around the border of the screen that stay the way they looked in X. Also, when you shutdown X, the screen freezes and the logs indicate some kind of timeout. Both of these seem to implicate the VGA BIOS.
- Sporadic boot-hang and USB timeouts. These seem to be specific to a kernel configuration, and go away when changing the verbosity level. This strongly indicates a timing-related bug in the kernel initialization procedures.
Of these issues, the wireless card and blank screen are the most critical, followed by the X11 weirdness. I will be in contact with the Librem developers should my initial attempts to fix these issues prove unsuccessful.
Following that, I want to see if there’s a way to make the kill-switches behave more gracefully. If the USB driver could be connected to treat those devices as hot-pluggable, or else assume timeouts are disconnects.
In any case, stay tuned for updates…