Device maker Purism shares new details on the smartphone’s status and production schedule
SAN FRANCISCO, Calif., September 4, 2018 — Purism, the social purpose corporation which designs and produces popular digital rights respecting hardware, software, and services, is sharing the much anticipated progress and scheduling for its Librem 5 smartphone. Read more
As you might have noted when we announced closing the development kit “last call” sale, new specifications have been made public. I want to explain what led to these specifications and why we made the choices we made and what the current timeline is for the devkits and Librem 5 phones. Read more
These last few weeks, the Librem 5 team has been hard at work improving the current software stack as well as making great strides towards finalizing the development kit schematic. Here are the highlights of the exciting progress that has been made.
The images produced for the i.MX6 board now have phosh as the default shell and we are experimenting with PureOS as the base OS (instead of Debian buster). There is also now an x86_64 raw VM image being produced and you can follow these instructions on getting a copy of the image and running it. The VM image uses the same screen resolution that the actual Librem5 phone will use.
While the i.MX6 images have been developed for the current hardware in the team’s hands, work continues on the image to be used on the i.MX8-based development board and actual phone. Note that during the investigation of the i.MX8 CPU, there were freedom issues that needed to be addressed. To read more about this, checkout the Solving the first FSF RYF hurdle for the Librem 5 blog post.
The image built for the i.MX8 board can now boot a very basic mainline kernel (instead of the vendor kernel offered up by the manufacturer). The next steps are to bring more components (like the display) online and to upstream these changes. All in all though, this i.MX8 image is really coming together!
At some point, most people will likely use their Librem 5 at night so having redshift in place makes the screen easier on the eyes. There was some work done to implement some of Mutter‘s DBus API in phosh, needed for e.g. display configuration and redshift. So now, phosh can detect the attached outputs and supported video modes and report them in a mutter/gnome-shell compatible way so they show up in gnome-settings and gnome-settings-daemon is happy. This is the base for future gamma control work (redshift). This depends on a patch to wlroots which is currently under discussion.
Since phosh is the shell and it works hand-in-hand with wlroots, they both are key areas for the image development. There have been frequent updates to wlroots to stay current with the upstream snapshots. A minor issue was fixed in upstream wlroots to improve the error handling of compiling for armhf. Also support for adding custom video modes has been added to wlroots. Work on Gcr system-prompt integration is being done in phosh. This will solve a heap of authentication and modal dialog issues with PINs, PUKs, passwords, smart cards and keyrings by leveraging what’s already in GNOME.
There has been ongoing work into the onscreen keyboard (virtboard) which has led to virtboard being included in the images. In order for virtboard to show/hide when needed, merging of an input method (text-input) into wlroots was needed and GTK+ upstream was contacted about upstreaming the input method code. We are working on a patch securing the input method in our compositor. There has also been continued feedback from upstream on upstreaming the virtual keyboard protocol. The keyboard scales much better now too!
The calls application has also been added to the images for easy access. Within the calls app, the sending of DTMF tones has been added so that you can now hear those familiar sounds when touching a number on the keypad.
To make calls more robust, the possibility of doing unit tests of Calls’ oFono provider backend using the phonesim simulator were explored but unfortunately running ofonod requires root privileges in order to take ownership of the well-known name, org.ofono, which makes testing a massive headache if not impractical. Still though, unit tests for the Calls Provider interface using the dummy implementation, as well as tests for Origin and Call interfaces have been added.
The libhandy GTK+ widget has seen some growth too. HdyColumn has been added to help out with dynamic column resizing. There have also been some unit tests added for HdyArrows (used for directional swiping). A first version of libhandy has been released and v0.0.1 has even been uploaded to Debian experimental!
A demo app for libpurple has been drafted and an XMPP conversation has been established between the demo app and Dino. For encryption, an OMEMO conversation running with libpurple and the Lurch plugin was established. There has also been a conversation-view that pulls avatar/account data from a buddy list stored in xml. The ofono interface in SMS/XMPP was implemented into the demo app as well.
External factors have caused our development board schedule to slip beyond our initial June projected ship date. While developing the schematic for the development board, not all information was readily available so investigations were needed on various components (e.g. cameras, WLAN+BT, batteries, switches, push buttons, etc), and circuits needed to be added before the schematic is considered ready for review by the third party that will print the boards. The Librem 5 hardware team has done all of these required tasks and are in the process of ordering parts to be sent to the manufacturer of the boards. Our current rough estimate for shipment of the development boards is August 2018 but stay tuned for a more detailed blog post on the subject.
The Librem 5 matrix chat rooms have really exploded with lots of fantastic feedback and questions. Some community members have even stepped up to help find new issues, fix some issues, and add to the documentation. Due to the demand from the community, there is now an x86_64 VM raw image available that looks just like what the team is installing on the i.MX6 boards.
The Purism collaboration with the Plasma community continues as well. There are now some arm and aarch64 flatpaks of Plasma software. The Purism team is also actively investigating building a Plasma image for the i.MX6 boards as well.
A GTK+ page has been added with example apps and includes documentation on adaptive labels.
A phone constraints page has been added to outline some specific constraints that should be considered when developing apps for the Librem 5 phone.
We also recently attended the GUADEC conference in Spain where we got to interact with a lot of wonderful folks excited about the Librem 5. More on the GUADEC conference to com in a future progress report.
A big Thanks goes out to all of the external teams that have helped review and merge changes into upstream projects. Everyone’s time and contribution is much appreciated!
That’s all for now folks. Stay tuned for more exciting updates to come!
While investigating using the i.MX 8 for the Librem 5 phone we found an issue that would have been problematic for us to obtain the Free Software Foundation’s “Respects Your Freedom” (RYF) hardware endorsement:
In U-Boot there are a number of firmware blobs that need to be loaded into the DDR PHY so that it can be trained to work with DDR4. This training is done on every boot.
The normal boot sequence for the i.MX 8 is that the internal ROM loader loads the Secondary Program Loader (SPL) which, in this case, is a small version of U-Boot that can initialize the DDR and load the full U-Boot into DDR to finish the boot process. Very early in the SPL, the training blobs get loaded into the DDR PHY and the training sequence is run. The DDR training procedure is completely un-documented so re-writing the firmware blobs with free/libre or open source versions would be an arduous process.
We can’t ignore the DDR PHY because it is interface between the i.MX 8 internal buses and the DDR4 chips outside of the SOC. The DDR PHY is also part of the i.MX 8 silicon so we can’t just replace the DDR PHY with a different one. It also appears that all DDR PHY’s required this training to work with DDR4, so going to a different SOC wouldn’t solve it either.
The RYF has a “secondary processor” exclusion that can be granted on a case by case basis. We will leverage this exclusion to load and train the DDR PHY on the i.MX 8. We will use a secondary processor to keep binary blobs out of u-boot and the kernel.Read more
Purism has finalized the specifications for the Librem 5 development kit and will be placing all the component parts order and fabrication run the first week of June 2018. If you want to have early access to the hardware that will serve as the platform for the Librem 5 phone, you mustplace your dev kit order before June 1st, 2018. The price for the development kit is now $399, up from the early-bird pricing that was in effect during the campaign and until today. The dev kit is a small batch, “limited edition” product. After this batch, we are not planning for a second run (as the production of the phone itself will replace the dev kit in 2019).
We decided to wait to get the latest i.MX 8MSystem On Module (SOM), rather than utilizing the older i.MX 6 SOM, therefore having the dev kit align nicely with the ending phone hardware specifications. This means the dev kits will begin delivery in the latter part of August for the earliest orders while fulfilling other dev kits in September. Choosing to wait for the i.MX 8M SOM also means our hardware design for the Librem 5 phone is still on target for January 2019 because we are pooling efforts rather than separating them as two distinct projects. Our dev kit choices and advancements benefit the Librem 5 phone investment and timeline.
The current dev kit specification is (subject to minor changes during purchasing):
i.MX 8M system on module (SOM) including at least 2GB LPDDR4 RAM and 16GB eMMC (NOTE: The Librem 5 phone will have greater RAM and storage)
M.2 low power WiFi+Bluetooth card
M.2 cellular baseband card for 3G and 4G networks
5.7″ LCD touchscreen with a 18:9 (2:1) 720×1440 resolution
Holder for optional 18650 Li-poly rechargeable battery with charging from mainboard (battery not required and not included!)
The dev kit will be the raw PCB without any outer case (in other words, don’t expect to use it as a phone to carry in your pocket!), but the physical setup will be stable enough so that it can be used by developers. As we finalize the designs and renders we will publish images.
We are excited about the future of Heads on Librem laptops and the extra level of protection it can give customers. As a result we’ve both been writing about it a lot publicly and working on it a lot privately. What I’ve realized when I’ve talked to people about Heads and given demos, is that many people have never seen a tamper-evident boot process before. All of the concepts around tamper-evident boot are pretty abstract and it can be difficult to fully grasp how it protects you if you’ve never seen it work.
We have created a short demo that walks through a normal Heads boot process and demonstrates tamper detection. In the interest of keeping the demo short I only briefly described what was happening. In this post I will elaborate on what you are seeing in the video.
Step One: Normal Boot
The normal boot process for a computer that uses Heads is much like with any other computer, at least from a user experience standpoint. Like with other computers, you can bring up a full menu of different items to boot, but you can also pick one to set as your default. Once you set a boot option as a default, at boot time you can just press Enter and it will boot into your operating system just like with any other system.
Unlike with other systems, Heads is providing extra levels of security during the boot process. At that default boot screen, you will see a 6-digit number above the menu options. That is a TOTP (Time-based One Time Password) code that Heads uses to prove to you that it hasn’t been tampered with and can be trusted. If you’ve ever used a TOTP code in the past, normally it’s so you can authenticate yourself to a website using Two-Factor Authentication. In this case it’s the reverse: the computer (specifically Heads) is authenticating itself to you! If that code matches the code on your phone, you know it’s safe to proceed.
Once you hit Enter during a normal boot, Heads then verifies the signatures of all of its configuration files stored in /boot based on the copy of your public GPG key it has within it. These configuration files include a file that contains sha256 checksums for the rest of the files in /boot. Once it verifies your signature for that file, Heads can trust it hasn’t been modified so it uses it to make sure the rest of the files in /boot haven’t changed. Since all of them match, they weren’t tampered with so Heads proceeds with the boot process.
Step Two: Hack The Computer
Once the computer boots, I put my black hat on and “hack” my computer by defacing my /boot/grub/grub.cfg file with a comment. This is a benign hack for demonstration purposes, but the attacker could have just as easily modified grub.cfg to boot from an older kernel on your system that has a known security vulnerability, added a single user mode, or otherwise altered the boot process to make it easier to launch another attack.
An attack that changes a plain text configuration file leaves a trail that might be easier for a user to detect if they happened to edit the file themselves. A more sophisticated hacker would put a back door into your default initrd file (the initial file system your kernel uses when it boots) or even replace your kernel with a compromised version. Both of these kinds of attacks are almost impossible to detect without a system like Heads. Because all of these files are stored in /boot, and Heads checks all of them, it is able to detect all of these types of tampering.
Step Three: Detect Tampering
When the system reboots, it returns back to the main Heads boot screen. First I hit Enter to select the default boot option but this time when Heads scans all of the files in /boot, it detects that grub.cfg has been changed! Along with the warning, I also get the option to re-sign all of the files in /boot. This option exists because there are a number of perfectly legitimate reasons why your grub.cfg, initrd, kernel, or other /boot files might change either because you edited them yourself or you updated software that changed them. Otherwise if you don’t want to re-sign files you can return to the main menu.
If you choose to re-sign all of the files, you will get an additional warning screen that explains what Heads is about to do and another chance to exit out to the main menu. If you did choose to re-sign all of the files you would then insert a USB GPG smart card that held your private keys so you could re-sign the Heads configuration files in /boot.
Since I knew that I didn’t want to keep that “hacked” grub.cfg file, instead of signing the files I returned to the main menu. By default Heads used to error out to a recovery shell if it detected a file was tampered with. The assumption is that the expert user could then investigate and remedy the problem from within that shell. If you aren’t an expert user in this situation you might not know how to recover and would end up being locked out of your computer!
We understand that there are a number of situations where a user might legitimately or accidentally change files in /boot and while it’s not advisable to boot into a system that is actually tampered with by an attacker (because among other reasons, an attacker might be able to get your disk encryption or login passwords), we also don’t want to lock you out. We’ve added an “insecure boot mode” to Heads for these circumstances. When you select that option, Heads will ignore any tamper warnings and present you with a GRUB-style menu of boot options. You can then select a boot option and Heads will boot into your system. To make sure you know that this is an unsafe option, in addition to the warnings in the user interface, we also disable the splash screen and change the console to have a red background.
Step Four: (Optionally) Investigate Tampering
So what should you do if Heads alerts you to tampering? Exactly how you respond to a potentially legitimate tampering alert depends on a number of factors including what kind of user you are. I’ll step through three of the most common categories of Heads user and describe how they might respond to a legitimate tampering alert.
Category 1: Enterprise User
In the event of tampering, enterprise users would just hand the laptop over to their IT team and pick up a replacement while the IT team investigates. Some organizations might want to go a step further and work with us to customize their Heads image with branded and customized warning messages with their custom policies or direct the employee to an internal wiki or other resources. Some enterprises may even want to go even further and remove the ability to boot a machine that sets off tampering alerts. This would also be useful for employees who take their machine overseas to ensure the machine is in a safe state before they reconnect it to the corporate network.
Once the IT team receives the laptop, they can then inspect the laptop for tampering using their in-house tools and procedures, and then reflash the system back to their secure, internal image. For smaller organizations who may not have those capabilities, Purism also provides support services to bring the laptop back to a clean factory state.
Category 2: Expert-level End User
The expert level user will likely want to inspect the system themselves in the event of a legitimate tamper alert. While I demonstrate the insecure forced boot mode in the demo, the expert user would likely use the Heads recovery shell or boot into a USB recovery disk instead (like the PureOS live install disk) to investigate from there. Otherwise, when they boot their compromised system, they will be prompted for their disk decryption passphrase and login password and risk turning those secrets over to the attacker.
While the Heads recovery shell is limited to a small subset of Linux command-line tools, it has enough tools for the expert user to inspect files in /boot including a text editor to inspect grub.cfg and tools to mount the encrypted root file system from a trusted environment. Provided you trust Heads itself hasn’t been tampered with, you could inspect quite a bit just from this recovery shell alone.
If the Heads recovery shell didn’t provide enough tools, the expert user could also boot from a USB disk, mount the /boot partition and inspect the changed files. In the case of a modified grub.cfg they would just use a text editor for this. In the case of a modified initrd they would need to extract the file and inspect the extracted file system. From there they could also decide to mount the root file system and inspect it for rootkits as well. For users who may suspect Heads itself was tampered with, they would be able to use flashrom to pull down a copy of the version of Heads on the system and inspect it directly.
Category 3: Everyone Else
The average user is unlikely to put on their forensics hat and inspect a compromised system. While for the most part any alerts an average user will see will likely be a direct result of package updates or other changes they know they made, there’s a possibility that sometimes they might get an alert they weren’t expecting. For instance, if you took your laptop overseas on a trip and didn’t update it or otherwise change it during the trip, a tampering alert when you got home would be much more suspicious.
So what’s the average user to do? No matter what, you can always fall back to the insecure boot mode so you won’t lose access to their system or files. In that case even if you couldn’t inspect or fix the errors yourself, you could at least backup your personal files and reinstall the OS to get back to a safe state. Alternatively like with enterprise users you could also take advantage of Purism support services to reflash your system to a factory state.
Hopefully watching Heads in action has helped make it a bit more clear just how it will protect you from tampering. In future posts I will walk through other Heads features and workflows including registering a new TOTP code and completely resetting the TPM.
In November, we announced the availability of our Trusted Platform Module as a $99 add-on for early adopters, something that would allow us to cover the additional parts & labor costs, as well as test the waters to see how much demand there might be for this feature. We thought there would be “some” interest in that as an option, but we were not sure how much, especially since it was clearly presented as an “early preview” and offered at extra cost.
Well, it turns out that a lot of people want this. We were pleasantly surprised to see that, with orders placed since that time, 98% of customers chose to have a TPM even at extra cost. This proved there is very strong market demand for the level of security this hardware add-on can provide.
2018’s first new batch is in stock—with TPM
Thanks to the investment of those early TPM adopters who voted with their wallets and gave us the necessary “business case” and resources to work it out, we are extremely proud to announce that we now include the TPM chip in all new Librem 13 and Librem 15 orders by default, as a standard feature of our newest hardware revision shipping out this month.
All the rest of the chip specifications remain the same.
It is still costing us money to add the TPM feature, but we decided to eat the cost, as the greater public benefit is more important than profits (and that is in line with our social purpose status and mission). Adding a TPM by default without increasing the base price is a major accomplishment toward having security by default, and paves the way for convenient security and privacy protection for everyone. In addition to the previous announcement, you can read Kyle’s post to understand the security implications.
Wait, there’s more!
We are now offering Free International Shipping on all orders. This is essentially a permanent rebate of approximately 100 USD to all new international customers! As we have grown we have been able to leverage more standardized shipping options, and are now in a position to pass on that savings to Purism customers. Please note, however, that shipping insurance, local taxes, customs fees and import duties are still your responsibility as customers.
Thanks to popular demand, we are now offering Librem 13 and Librem 15 laptops with the backlit German keyboard layout. They are available for purchase in our store now, and will begin rolling out in mid-March.
Only a few non-TPM laptops remain in stock with the UK keyboard layout, so we are making a sale today to clear out that portion of the inventory. If you were looking for a Librem 13 with the UK physical key layout and no TPM, you can grab one of the few remaining ones and get an additional $99 off the previous no-TPM base price. In other words, instead of paying $1,478 “plus shipping” for the base configuration of the Librem 13 UK, you now pay $1,379 with free shipping!
We would like to thank all our users of Librem laptops and FSF endorsedPureOS, as well as all those that have backed the Librem 5 phone, and of course all those people who support us by feedback, kind words, and spreading the word. It is with this unified education approach that we can change the future of computing and digital rights for the better.
We have more great news in the pipeline. Next month, we hope to announce another major milestone in our inventory management & shipping operations. Stay tuned!
Being at FOSDEM 2018 was a blast! We received a lot of great feedback about what we have accomplished and what we aim to achieve. These sorts of constructive critiques from our community are how we grow and thrive so thank you so much for this! It helps us to focus our development. Moreover, I was very impressed by the appreciation that we received from the free software community. I know that relationships between companies, even Social Purpose Corporations—like Purism, and the free software communities are a delicate balance. You need to find a good balance between being transparent, open, and free on one side but also having revenue to sustain the development on the other side. The positive feedback we received at FOSDEM and the appreciation that was expressed for our projects was great to hear.
We are working really hard on making ethical products, based on free/libre and open source software a reality. This is not “just a job” for anybody on the Purism staff, we all love what we do and deeply believe in the good cause we are working so hard to achieve. Your appreciation and feedback is the fuel that drives us to work on it even harder. Thank you so much!
As I mentioned before, we have the i.MX 6 QuadPlus test hardware on hand, so here are some photos of our development board actually running something:
On the right, you can see the Nitrogen board with the modem card installed. On the left is our display running a browser displaying the Purism web-page and below it a terminal window in which I started the browser. To put the resolution of the display into perspective I put a Micro SD card on the display:
The terminal window is about as big as three Micro SD cards! This makes it very clear that a lot of work has to be put into making applications usable on a high resolution screen and to make them finger friendly since the only input system we have is the touch screen. In the next picture I put an Euro coin on the screen and switched back to text console:
Concerning the software, we are working on getting the basic framework to work with the hardware we have at hand. One essential piece is the middleware that handles the mobile modem that deals with making phone calls and sending and receiving SMS text messages. For this we want to bring up oFono since it is also used by KDE Plasma mobile. We have a first success to share:
This is the first SMS sent through oFono from the iMX board and the attached modem to a regular mobile smartphone where the screenshot was taken. So we are on the right track here and have a solution that is starting to work that suits multiple possible systems, like Plasma mobile or a future GNOME/GTK+ based mobile environment.
The SMS was sent with a python script using the native oFono DBus API. First the kernel drivers for the modem had to be enabled followed by running ofonod which autodetects the modem. Next the modem must be enabled and brought online (online-modem). Once this was done sending an SMS was as simple as:
purism@pureos:~/ofono/test$ sudo ./send-sms 07XXXXXXXXX "Sent from my Librem 5 i.MX6 dev board!"
The script itself is very simple and instructive. Simulating the reception of a text message can also be done, with a command such as this one:
purism@pureos:~/ofono/test$ sudo ./receive-smsb 'Sent to my Librem 5 i.MX6 dev board!' LocalSentTime = 2018-02-07T10:26:19+0000 SentTime = 2018-02-07T10:26:19+0000 Sender = +447XXXXXXXXX
The evolution of mobile hardware manufacturing
We are building a phone, so hardware is an important part of the process. In our last blog post we talked a bit about researching hardware manufacturing partners. Since we are not building yet-another Qualcomm SOC based phone, but starting from scratch, we are working to narrow down all the design choices and fabrication partners in the coming months. This additional research phase has everything to do with how the mobile phone hardware market has evolved in the past years and I want to share how this all works with you.
In the early days of smartphones, a common case was that the main CPU was separated from the cellular baseband modem and that the cellular modem would run its own firmware when implementing all of the necessary protocols that operate the radio interface—at first it was GSM, then UMTS (3G) and finally LTE (4G). These protocols and the handling of the radio interface have become so complex that the necessary computational power for handling this as well as the firmware sizes have grown over time. Current 3G/4G modems include a firmware of 60 or more megabytes are becoming more common. It did not take long before storing this firmware became an issue as well as at run time since this requires significant increases of RAM usage.
Smartphones usually have a second CPU core for the main operating system which also runs the phone applications and interacts with the users. This means that your device must have two RAM systems as well, one for the baseband and one for the host CPU. This also means you need two storages for firmware, one for the host CPU and one for the baseband. As you may imagine, getting all of these components working together in a form factor small enough to fit into someone’s hand takes a lot of development and manufacturing resources.
The advent of cheap smartphones
There is extreme pressure about the cost of smartphones. In today’s commodity market, we see simple smartphones starting at prices less than $100 USD.
The introduction of combined chips, with radio baseband plus host CPU on one silicon die inside one chip, massively reduced costs. This allows the host CPU and baseband to share RAM and storage. Since the radio can be made in the same silicon process as the host CPU, and both can be placed in a single chip package, we see substantial cost reduction in the semiconductor manufacturing as well as the cost of manufacturing the device. This saves you from having to use a second large chip for the radio itself, an extra flash chip for its firmware, and possibly an extra RAM chip for its operation. This does not only reduce the Bill of Materials (BOM), but also PCB space, and it enables the creation of even smaller and thinner devices. Today we see many big companies offer these types of combined chipsets—such as Qualcomm, Broadcom, and Mediatek to name a few.
These chips caused a big shift in the mobile baseband modem market. Formerly it was common to find discrete baseband modems on the market that were applicable for mobile battery powered handsets like the one we are developing. But since the rise of the combined chipsets, the need for separated modems has dropped to a level that does not justify their development as much. You can still find modem modules and cards but these modules are usually targeted for M2M (machine to machine) communication with only limited data rates and most of them do not have audio/voice functions. They usually come in pretty large cards, such as the miniPCIe or M.2. For us this means that our choice of separated baseband modems suitable for a phone is narrowed.
What this means for OEM, ODM or Build it Yourself
All of this consolidation has an impact on hardware manufacturers and our choices. Pretty much all current smartphone designs by OEM/ODM manufacturers are based on the combined chipset types; this is all they know and it is where they have expertise. Almost no one is making phones with separated basebands anymore, and the ones who do are not OEMs nor ODMs. The options are further limited by our requirement not to include any proprietary firmware on our host CPU (which we wrote about before): most fabricators are unfamiliar with i.MX 6 or i.MX 8 and do not want to risk a development based on it, which narrows our hardware design and manufacturing partners to a much smaller list.
However, we have some promising partners that we will continue to evaluate, and we are confident that we are going to be able to design and manufacture the Librem 5 as we originally specified. We just wanted to share with you why making this particular hardware is so challenging and why our team is the best one to execute on this design. To continue to discuss with some of the manufacturers and providers, Purism will visit Embedded World, one of the world’s largest embedded electronics trade shows, in Nürnberg (Germany) in the beginning of March. And, as usual, we will continue to keep you updated on our progress!
Good news with our existing evaluation boards
We have been patiently waiting for the i.MX 8M to become available, all according to the forecast timeline from NXP. In the meantime, we have started developing software using the i.MX 6 QuadPlus board from Boundary Devices, specifically the NITROGEN6_MAX (Nit6Qp_MAX) since it is the closest we get to production devices before NXP releases the i.MX 8M. We have a Debian Testing based image running as a testbed on these boards while the PureOS team is preparing to build PureOS for ARM and ARM64 in special.
On these evaluation boards we have all the interfaces that we need for software development:
Video input and output
USB for input devices
Serial console and a miniPCIe socket with SIM card connected for attaching a mobile modem
At the moment, we are using a Sierra Wireless MC7455 LTE miniPCIe modem card for development, which uses a Qualcomm MDM9230 baseband modem chip. This card is basically a USB device in a mPCIe form factor, i.e. we do not actually use the PCIe interface.
An extremely nice display to our kits using an HDMI-to-MIPI adapter board. The display is a 5.5″ AMOLED display with full-HD resolution with the native orientation as portrait mode.
This hardware setup allows us to start a lot of the software development work now to ensure our development continues in parallel until we have the i.MX 8M based hardware in hand.
It’s easy to take things for granted when your computer runs a non-free proprietary BIOS. While the BIOS that comes with your computer is usually configured to match its features that’s not always the case. You end up with a sort of binary arrangement: if your BIOS supports a feature or allows you to change a setting, great, but if it doesn’t, you are generally out of luck. One example is with some of the new UEFI computers that ship with stripped-down BIOS options. One example we ran across recently had legacy boot disabled, secure boot enabled, and no way to change either setting, which is a terrible restriction for users wanting a free software distribution like PureOS or any another distribution that avoids the misnamed “secure boot” UEFI option.
From the beginning our goal has been to ship ethical computers without any proprietary code and the BIOS was one of our first targets. Starting last summer, all our computers come with the Free/Libre and Open Source coreboot BIOS. In addition to the many ethical and security advantages behind shipping an ethical BIOS/firmware, another advantage we have is that if our coreboot image doesn’t support a feature today, that doesn’t mean it won’t tomorrow.
We are happy to announce that due to the hard work of Youness “KaKaRoTo” Alaoui and Matt “Mr. Chromebox” DeVillier we have added IOMMU and TPM support to our new coreboot 4.7 BIOS. I’ve tested this personally on a Librem 13v2 with the latest Qubes 4.0-rc4 installer and the install completes with no warnings and reboots into a functional Qubes 4 desktop with working sys-net and sys-usb HVM VMs. In this blog post I’ll go over these different features, what they are, and why they are important. Read more
Lately, news headlines have been packed with discussions about critical CPU bugs which are not only found in Intel CPUs, but also partially in AMD CPUs and some ARM cores. At the same time, some of our backers have voiced concerns about the future of NXP in light of a potential acquisition by Qualcomm. Therefore you might be wondering, “Will the Librem 5 be affected by these bugs too?” and “will the Purism team get the i.MX 8 chips as planned?”, so let’s address those questions now.
Not affected by Spectre/Meltdown
At the moment we are pretty confident that we will be using one of NXP’s new i.MX 8 family of CPUs/SOCs for the Librem 5 phone. More specifically we are looking at the i.MX 8M which features four ARM Cortex A53 cores. According to ARM, these cores are not affected by the issues now known as Spectre or Meltdown, which ARM’s announcement summarizes in their security update bulletin.
So for the moment we are pretty sure that the Librem 5 phone will not be affected, however we will continue to keep an eye on the situation since more information about these bugs is surfacing regularly. In this respect we can also happily report that we have a new consultant assisting our team in security questions concerning hardware-aided security as well as questions like “is the phone’s CPU affected by Spectre/Meltdown or not”.
Qualcomm possibly buying NXP: not a concern
For quite some time there have been rumors that Qualcomm might have an interest in acquiring NXP. Since we will be using an NXP chip as the main CPU, specifically one of the i.MX 8 family, we are well aware of this development and are watching it closely.
Qualcomm is an industry leader for high volume consumer electronics whereas NXP targets lower volume industrial customers. This results in pretty different approaches concerning support, especially for free software. Where NXP traditionally is pretty open with specifications, Qualcomm is rather hard to get information from. This is very well reflected by the Linux kernel support for the respective chips. The question is how would it affect continued free software support and availability of information on NXP SOCs if Qualcomm acquires NXP?
First, it is unlikely that this deal will happen at all. Qualcomm had a pretty bad financial year in 2017 so they might not be in the financial position to buy another company. Second, there is a rumor that Broadcom might acquire Qualcomm first. Third, international monopoly control organizations are still investigating if they can allow such a merger at all. Just a few days ago the EU monopoly control agreed to allow the merge but with substantial constraints, for example Qualcomm would have to license several patents free of charge, etc. Finally, there are industry obligations that NXP cannot drop easily: the way NXP works with small and medium sized customers is a cornerstone of many products and customers; changing this would severely hamper all of those businesses involved, and these changes might cause bad reputation, bad marketing and loss of market share.
So all in all, this merger is not really likely to happen soon and there would probably not be changes for existing products like the i.MX 8 family. If the merger happens it might affect future/unreleased products.
In addition to working on obtaining i.MX6QuadPlus development boards to be able to work properly, the phone team is also intensively researching and evaluating software that we will base our development efforts on during the next few months. We are well aware of the huge amount of work ahead of us and the great responsibility that we have committed to. As part of this research, we reached out to the GNOME human interface design team with whom we began discussions on design as well as implementation. For example, we started to implement a proof of concept widget that would make it much easier to adapt existing desktop applications to a phone or even other style of user interface. What we would like to achieve is a convergence of devices so that a single application can adapt to the user interface it is currently being used with. This is still a long way ahead of us, but we are working on it now. We will meet up also with some GNOME team members at FOSDEM to discuss possible development and design goals as well as collaboration possibilities.
The mobile development work for KDE/Plasma will primarily be performed by their own human interface teams. Purism will be supporting their efforts through supplying hardware and documentation about our phone development progress as it is happening. This will help ensure that that KDE/Plasma will function properly on the Librem 5 right from the factory. To understand better where we’re headed with GNOME and KDE together, take a look at this blog post.
We also reviewed and evaluated compositing managers and desktop shells that we could use for a phone UI. We aim to use only Wayland, trying to get rid of as much X11 legacy as we possibly can, for performance issues and for better security. From our discussions with GNOME maintainers of existing compositors and shells, we may be better off igniting a new compositor (upstreamed and backed by GNOME) in order to avoid the X11 baggage.
On the application and middleware side of things, we have generated an impressive list of applications we could start to modify for the phone to reach the campaign goals and we have further narrowed down middleware stacks. We are still evaluating so I do not want to go into too much detail here, in order not set any expectation. We will of course talk about this in more detail in some later blog posts.
Meeting with Chip Makers
As the CPU choice is pretty clear lately, we are going to have a meeting with NXP and some other chip makers at Embedded World in Nürnberg, Germany, at the end of the month. This is very encouraging since we worked for months on getting a direct contact to NXP, which we now finally have and who we will meet in person at the conference. The search for design and manufacturing partners is taking longer than expected though. Our own hardware engineering team together with the software team, especially our low level and kernel engineers, started to create a hardware BOM (bill of material) and also a “floor plan” for a potential PCB (printed circuit board) layout, but it turns out that many manufacturers are reluctant to work with the i.MX 8M since it is a new CPU/SOC. We have, however, some promising leads and good contacts so we will work on that.
Purism Librem 5 team members attending FOSDEM
By the way, many Purism staff members will be at FOSDEM this week-end, on the 3rd and 4th of February. In addition to the design and marketing team, PureOS and Librem 5 team members will be there and we would love to get in touch with you! Purism representatives dedicated to answering your questions will be wearing this polo shirt so you can easily recognize them: