[Testannounce] Librem Mini Sale

Wed Sep 23 10:28:03 PDT 2020

Librem Mini Sale

  Librem Mini Sale

You can grab the *Librem Mini for $100* off until the end of September!

Pre-orders for the all-new Librem 14 are $100 off and the Librem 15 is
currently $200 off. So many options!

Librem Mini See All Sales <https://shop.puri.sm/>
------------------------------------------------------------------------

    In This Issue

In today's newsletter we cover a large range of topics from privacy
concerns, GPS tuning and Anbox on the Librem 5, porting postmarketOS to
the Librem 5, making 3D graphics with open software, and Librem 14
shipping updates.

    Your Phone Is Your Castle

Castle

      A Brief History Lesson

There is a saying “A man’s home is his castle” that derives from an even
older British saying “an Englishman’s home is his castle” from hundreds
of years before. Putting aside the history of male and female ownership
of property for the past few hundred years, this statement came about as
a matter of common law in the 17th century that enforced the right that
no one–even the King–may enter a British person’s home without their
invitation. As stated famously by Prime Minister William Pitt in 1763:

    "The poorest man may in his cottage bid defiance to all the forces
    of the crown. It may be frail – its roof may shake – the wind may
    blow through it – the storm may enter – the rain may enter – but the
    King of England cannot enter."

This right influenced the United States founding fathers and became a
right against unreasonable search and seizure enshrined in the fourth
amendment in the US Bill of Rights.

Ultimately this statement is one about personal sovereignty over your
property: that you should be able to control what happens with your
property, should be able to control who is allowed to enter it, and
should be allowed to defend it from intrusion.

      Your Phone Is Your Castle

If your home is your physical castle, your phone is your digital castle.
More than any other computer, your phone has become *the most personal
of personal computers* and holds the most sensitive digital property a
person has, including:

  * Detailed contact lists of friends and colleagues
  * The contents of private communications
  * Personal photos (sometimes including very intimate ones)
  * Personal files (sometimes including financial documents)
  * Health and biometric information (sometimes including personal heart
    rate, blood pressure and exercise regiment)
  * Passwords to online accounts
  * Often even a database (if not multiple databases) of everywhere the
    phone has (and therefore you have) been.

So to extend the metaphor, if your phone is your digital castle, it
means you should be able to control what happens with it, who is allowed
to enter it, and should be allowed to defend it from intrusion.

      Well, Maybe Not /Your/ Phone

The unfortunate fact is, for most of the people reading this article,
*/your/ phone is /not/ your castle*. In many ways, your phone isn’t
yours at all, at least if we are using these same traditional
definitions of property. Instead, you happen to live in a castle owned
by your phone’s vendor. It’s Apple or Google, not you, who decides what
is allowed to enter the castle, and what happens inside its walls. They
are the ones who are allowed to defend it from intrusion, and more
importantly they are the ones who define what counts as intrusion to
begin with. *Your phone is /their/ castle*, you just happen to live
inside their walls subject to their rules.

Therecent epic battle between Apple and Epic
<https://arstechnica.com/gaming/2020/09/apple-accuses-epic-of-theft-in-countersuit-over-ios-fortnite/>
over the tariff Apple charges for merchants to sell goods inside the
castle walls illustrates how Apple markets their castle’s defenses as
protecting the castle residents when in reality it’s about controlling
all that goes on inside the castle.

If you haven’t been following the case, Epic is objecting to the 30% cut
of their revenue that Apple gets from processing payments within the App
Store. Epic has added an alternate payment processor within their
popular game Fortnite that competes with Apple’s App Store payment
processor by charging a lower price for purchases made through the game
since Epic avoids Apple’s 30% processing fee. Apple has responded by
threatening to remove Epic’s software from the App Store as well as
revoking their ability to use Apple’s development infrastructure.

A customer can only install apps that are in the App Store, so by
removing Epic’s app from the App Store, Apple removes them from the full
iOS ecosystem. Customers who own iPhones and who have paid for and
installed Fortnite would then have the application removed from their
phones. In a court filing, Apple argues that the requirement that
customers may only install software through the App Store is needed “for
security and privacy.”

There is some truth to this statement. Because iOS software, backed by
iPhone hardware, actively prevents a customer from installing /any/
software on an iPhone outside of the App Store, it does also prevent
attackers from installing /malicious/ software. Because the App Store
has rules about how applications (outside of their own) can access
customer data, if Apple discovers a competitor like Google or Facebook
is violating its privacy rules it can remotely remove their software
<https://www.macrumors.com/2019/01/30/apple-disables-facebook-internal-apps/>
from iPhones, even internal corporate versions of software owned by
Google or Facebook employees.

In all of these examples, though, the “security and privacy” of
customers happens to also coincide with restricting a competitor. While
Apple markets themselves as welcoming competition on the App Store,
Apple has a long history of resisting competition with their own
products from the App Store such as when it banned parental control apps
around the same time it released its own, only to remove the ban a few
months later after its own app had sufficient market share
<https://www.nytimes.com/2019/06/03/technology/apple-parental-control-apps.html>.

I should note that Apple isn’t the only company that does this, it’s
just that their control is a bit more advanced than Google’s. In my
Consent Matters series
<https://puri.sm/posts/consent-matters-when-tech-takes-remote-control-without-your-permission/>
I elaborate on a number of different companies that take remote control
of customer computers including the now-famous example where Google was
forced by the US Government to remove Huawei’s ability to update Android
on their own hardware
<https://www.techradar.com/news/huawei-suffers-major-android-setback-as-google-pulls-access-to-core-apps-and-services>.
Huawei has since responded by building their own OS
<https://www.cnbc.com/2020/09/10/huawei-opens-harmonyos-to-third-party-smartphone-makers-after-google-ban.html>
so they have control over their own castle (and subjects).

      Well, Maybe Not Their /Castle/

If you live inside a strong, secure fortification where someone else
writes the rules, decides who can enter, can force anyone to leave,
decides what things you’re allowed to have, and can take things away if
they decide it’s contraband, *are you living in a castle or a prison*?
There is a reason that bypassing phone security so you can install your
own software is called /jailbreaking/.

These companies have built very sophisticated and secure defenses all in
the name of protecting you from the world outside their walls, yet in
reality the walls are designed to keep you inside much more than they
are designed to keep attackers out. The security community often gets so
excited about the sophistication of these defenses backed by secure
enclaves
<https://puri.sm/posts/your-own-personal-enclave-the-smart-card-reader-on-the-librem-5/>
and strong cryptography that their singular focus on what those defenses
mean for attackers blinds them from thinking about what they mean for
everyone else.

The biggest threat to most people ends up not being from uninvited
hackers, it’s from the apps Apple and Google /do/ invite in that capture
and sell your data. This has resulted in a multi-billion-dollar app
ecosystem built around capturing and selling your data
<https://puri.sm/posts/mobile-app-stores-and-the-power-of-incentives/>.
If Apple or Google let someone in you didn’t invite, whether through
pre-installed applications or new features embedded in an OS update, you
can’t tell them to leave. Your security and privacy aren’t really
protected inside these walls because the main point of these security
measures is to enforce control, security against attackers and
protecting your privacy is mostly marketing spin.

      Make Your Phone Your Castle

It doesn’t have to be this way. We believe your phone should be /your/
castle and that you should be in control
<https://puri.sm/posts/with-purism-products-you-are-in-control/> of your
own computer, not us and not any other vendor. This doesn’t mean
sacrificing security or privacy, on the contrary it means putting your
security and privacy in your own hands by building a strong foundation
of trustworthy free software anyone can audit, while rejecting security
measures that build a stronger cage around you than attackers. It means
controlling your hardware with hardware kill switches so you can disable
your camera and microphone, your WiFi and Bluetooth, and even your
cellular modem and all of the sensors on your phone
<https://puri.sm/posts/lockdown-mode-on-the-librem-5-beyond-hardware-kill-switches/>
and know they are truly off.

You should decide which software is allowed on your system, not Purism.
While other vendors often are paid to bundle third-party applications
you aren’t allowed to remove, all of the software on the Librem 5
including pre-installed software is fully under your control. There’s no
“rooting” or “jailbreaking” required to install or remove the software
of your choice or even to install a different OS. While we will provide
you with a list of trusted, curated free software in our PureOS Store
<https://puri.sm/posts/purism-announces-pureos-store/>, if you want to
invite some other software into your home, even software that violates
Purism’s Social Purpose <https://puri.sm/about/social-purpose/>, you can.

The current phone market is centered on vendor control and is only
getting worse with each iteration and advancement. We had to design and
build the Librem 5 from scratch
<https://puri.sm/posts/breaking-ground/>, because no other combination
of hardware and software on the market met our high standards for
freedom, security, privacy, and user control. What we have built with
the Librem 5 <https://puri.sm/products/librem-5/> is a phone that works
the way your most personal of personal computers /should/ work–your own
digital castle where you can store your most sensitive digital property,
control what happens with it, and decide who’s invited in.

    GPS Tuning the Librem 5 Hardware

Space

      Phone Hardware debugging in a duopoly

Society is getting pretty used to the idea that the data and
applications on phones are completely controlled by large corporations.

Purism is working hard to change that with the Librem 5.

Because of the market capitalization and duopoly control of the phone OS
vendors, the hardware tool vendors use are trapped into one of those two
OSes (Android or iOS).

      GPS debugging as a case example

We’ve been working on antenna tuning in the Librem 5 for awhile to get
the best possible reception. The GPS antennas are especially important
because their signal level is so close to the noise floor.

The available GPS antenna tuning procedure is a GPS simulator
<http://www.generaltest.com/en/ProductDetail/2517909.html>, but the
simulator requires feedback from the phone OS to help tune the antenna.
If you are on Android the simulator vendor provides an apk that converts
the NMEA to a format that the tools can use to do the tuning.

So now we have a tool to do the tuning but no way to use it.

      Option 1 get anbox running

So I did seriously consider trying to use anbox to get the apk running
on the Librem 5. I didn’t think this would be workable for a couple of
reasons.

 1. The GNSS chip doesn’t use a /dev/ttyS0 device but a /dev/gnss0 so I
    had no idea how well Android or anbox would deal with that.
 2. There are a lot of moving parts to get anbox running smoothly enough
    for productive development and my todo list is already pretty lengthy.

      Option 2 RE the apk

So the next thing I figured I’d reverse engineer the apk so that I could
provide the feedback tool. I didn’t have a lot of faith that this would
work as reverse engineering a protocol can be very time-consuming.

Loading up the apk on an Android device the first thing it asks for is
an IP and port. Ok, this might be workable. I whipped up a little python
program to try and capture the apk output.

|#!/usr/bin/python import socket UDP_IP = "192.168.0.2" UDP_PORT = 8080
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT)) while True: data, addr =
sock.recvfrom(1024) print("received message: %s" % data)|

Immediately I started receiving GPS location and satellite S/N ratio
numbers. Perfect so now I just need to figure out what each of the
fields meant.

      Writing a GPS test tool

I began by capturing all of the JSON strings output by gpsd and trying
to fit them into the correct fields for the GTS 1800 test tool. Almost
immediately I started hitting some kind of mismatch between the gpsd
output and the json libraries installed on the phone. I’m not
sufficiently pythonic to understand what the issue was.

Ok, I really don’t need that additional abstraction that gpsd provides
so I installed the python-nmea2 library and started working directly
with the NMEA strings. In short order, I had a script that would take
the NMEA and convert it into something I thought the GTS 1800 could
digest. I’d guessed at a couple of the fields but I hoped it was close
enough to start the GPS antenna tuning.

Unfortunately, it wasn’t until a few screens captures from the antenna
testing engineer running a Windows tool that I was able to refine the
test tool to a point that the GTS 1800 would accept the strings. The
biggest problem was that I guessed wrong about the first field which
turned out to be a message length. Ooops, should have figured that one.

Once I reformatted the fields the GTS tool would accept the strings but
it still wasn’t running the tuning algorithm so there was still some
kind of error in the fields. This is when the test tool vendor figured
out what I was trying to accomplish and sent me a protocol
specification. Better late than never. So 2 more minor fixes and we now
have a tool
<https://source.puri.sm/Librem5/librem5-devkit-tools/-/merge_requests/166/diffs?commit_id=1d0e26a0d0a8ff986ad26c383f3960d8c33db378>
that can be used on any box that runs python to tune GPS antennas.

So duopolies aren’t just bad for software, they aren’t any good for
hardware development either.

    Tourists on Tech's Toll Roads

Walking up stairs

When I read Shira Ovide's piece “Apple Watch Is a Private Road
<https://www.nytimes.com/2020/09/15/technology/apple-watch-is-a-private-road.html>”
in the New York Times, I was reminded of my honeymoon in Cancun. Like
many people who honeymoon in Cancun, we stayed at an all-inclusive
resort along the ocean. In addition to enjoying the resort, we also
rented a car so we could visit some of the surrounding areas, in
particular the famous Mayan ruin Chichen Itza.

When we set off to visit Chichen Itza, the map featured a main route via
a toll road and an indirect route that winded through the jungle and
passed through a number of villages. I didn’t want to get lost, so I
opted for the direct route through the toll road. The road was wide,
freshly paved, no stop signs, and almost entirely empty–it was a smooth
trip with the only stop being the toll booth we hit when we got on the
road.

I had assumed the toll would be $1 or so–everything else up to that
point had been relatively affordable in Cancun–but was shocked when I
slowed down and discovered *the toll was $10*! This was about three
times what the Golden Gate Bridge charged back then! I felt taken
advantage of, yet once we got to the toll booth, there was no easy way
to turn around or avoid it, so we just paid the fee and I blamed myself
for being a dumb tourist who should have researched things better.

We spent the day in Chichen Itza and on the way back I vowed I would not
be taken advantage of again. This time we would take the indirect, free
route through the jungle. I was so glad I made that choice as I passed
through one village after another and saw local people living their
lives. While it wasn’t as fast or smooth a road as the toll road, I felt
like less of a tourist on a curated tour of someone else’s property and
more like I was seeing what “real” Cancun was like.

This was before GPS navigation was common so I carefully followed the
paper map and wooden road signs as I moved from one village to another,
always ensuring I would avoid the toll road. As I followed the signs to
the final road that would take me to the resort, I found myself back on
the toll road! I was infuriated but I realized I was so close to the
resort, perhaps the toll booth was already behind me. It didn’t matter
in any case because now that I was on this private road there was no way
to get off. Sure enough, a mile later there was the toll booth. With no
way to turn around and no way to get off the private road, *I had no
choice* but to pay another $10 to get back to my room.

      All Signs Point to Private Roads

The crux of Ovide’s article is that diversity and openness in computing
has brought us many tech advances, but today so many of tech’s most
recent advancements are closed and tightly controlled by the vendor:

    Think about the last quarter-century of computers and the internet
    like a highway. The companies that made gadgets and software systems
    controlled the roads, and cars made by other companies drove (with
    some restrictions) on those roads. Computer devices would be meh if
    we couldn’t have access to a diversity of apps, websites and
    software — and vice versa.

    But newer technologies for interacting online — smart watches like
    the Apple Watch, voice activated speakers, internet-connected
    televisions and robot-piloted cars — mostly pull us into digital
    features the device maker creates or tightly controls. They are more
    like private roads than the open highways of the smartphone and PC
    eras.

Ovide is right to point out that the recent trend is toward systems that
are increasingly more closed. Unfortunately it’s only the latest in an
ongoing cycle throughout the history of computing between open highways
and private roads. Each swing in the pendulum moves from public, open,
shared innovation that lays the open roads to private companies who use
those public roads to build their for-profit toll roads. Those companies
fight to ensure that no matter what signs you follow, you end up on
their private road.

      A Brief History of Open Computing

You can find many examples of this pendulum swing in the history of
computing. Open software development in the late 1960s and early 1970s
led to closed development on proprietary UNIX operating systems by the
late 1970s. This spawned the GNU project to forward the goals of Free
Software along with the advent of free BSD UNIX operating system
variants. UNIX systems were among the first nodes on the Internet as it
was being created with open protocols and standards in a collaborate
academic environment. Because of this, even though Microsoft would come
to dominate the home PC market in the 1990s, it didn’t share the same
dominance on the server side, so when Windows PCs finally connected to
the Internet, they had to do so with open protocols like DNS and TCP/IP
instead of Microsoft’s proprietary NetBIOS protocol. Eventually even
local Microsoft-dominated networks began to speak the open protocols of
the Internet.

As more PCs got on the Internet in the late 1990s, many Internet Service
Providers (ISPs) such as AOL fought to gain private control over this
public network in the form of *private roads to the Internet called
“portals”*–a custom web browser that provided a curated view of the
Internet along with proprietary chat clients and games. Customers could
chat and play games with each other as long as they used the same ISP.
Fortunately outside of these ISPs, email and other web protocols were
open, so you could use alternative ISPs and see a complete, unfiltered
view of the web and use open protocols to chat and game with whomever
you chose regardless of what ISP they used.

This open Internet accelerated collaboration on free software as well,
resulting in the full set of GNU tools that led to the Linux kernel and
the Apache web server, among other prominent free software applications.
This spawned a new golden era of open software development and
collaboration throughout the early aughts that laid the foundation of
free software libraries and utilities that a majority of our web
frameworks and cloud software is based on today. Many startups used
these open libraries as a jumping off point for their own tools (even
Google used Jabber/XMPP technology in initial versions of Google chat
applications) .

As the aughts progressed, because the new tech giants were making their
money by selling user data, the focus shifted back into creating
portals. This time Google and Facebook were the dominant players and set
out to ensure that you saw the rest of the web curated through their
websites and chatted with your friends using their proprietary services.
This “portalization” got worse as people shifted to using smartphones as
their primary computers so that *most apps became in essence a closed,
mini-portal* into the wider Internet you’d otherwise access from an open
web browser. Now you have five different incompatible apps on your phone
you use to chat with different people. Big tech companies can’t even
manage to be compatible with themselves: Facebook alone owns three
different incompatible chat apps– Google owns six
<https://arstechnica.com/gadgets/2020/05/google-unifies-messenger-teams-plans-more-coherent-vision/>!

      Private Roads Paved With Bad Intentions

Smartphones provided tech companies with a blank slate to re-imagine how
they approached software. The iPhone in particular rewrote the rules for
how tightly a vendor can control a platform. While Apple has always held
tight control over their platforms, in the past it didn’t get as much
notice since they were a minority player compared to Microsoft’s
dominance of the home PC market. Even with Apple’s tight control over
MacOS, third parties could still write an application for a Mac without
Apple’s permission and Apple customers could install and run it outside
of Apple’s control.

The iPhone changed all of this. From the beginning, a developer must
have Apple’s approval before a customer is allowed to use their
application. To reinforce this control, Apple has advanced their
security restrictions on the phone itself so that with each generation
of iPhone and iOS, “jailbreaking” or “rooting” the phone so that you can
run the software of your choice becomes more and more challenging. With
the recent versions of the phone this is reinforced by custom,
proprietary hardware and strong cryptography. Even hardware accessories
for the iPhone require Apple’s approval or else you will get a warning
that the device is not certified
<https://www.howtogeek.com/240407/why-your-iphone-or-ipad-is-saying-this-cable-or-accessory-is-not-certified/>.
These measures are always marketed as being for security from hackers
and more recently also in the name of privacy, but from the beginning it
has always been about ensuring that Apple can control which applications
and accessories are allowed on the iPhone, in particular when those
applications compete with their own offerings.

Seeing Apple’s success, competitors followed their lead so that now
Android employs many of the same restrictions (again in the name of
security and privacy) so that they can control the software that runs on
Android devices. In the case of Android, this also ensures that
cellphone vendors can not only pre-install their own vendor software
that customers can’t remove, they have also made a side business out of
selling software placement on their phones to third parties who often
use the access to harvest customer data.

As Ovide’s article states, this closed approach has defined the next
generation of computers (smart watches, smart speakers, smart TVs)
already. There’s no attempt by these vendors to build open platforms
when they design new technology. It’s rare when these platforms play
well with each other. Will your smart watch work with your smart phone?
Can you control your smart TV with your smart speaker? The only way to
ensure technology is compatible is to *buy it all from the same vendor*.
That’s by design.

Traditional computers are on the same path. Google has already extended
this same approach–in the name of security–to Chromebooks to ensure that
the only applications allowed on their laptops are those Google
explicitly approves. Apple is moving quickly to extend these same
security measures to their laptops as well. The goal of each of these
vendors is to have no open highways, *only private toll roads*, leading
only to their tourist attractions.

      Where We’re Going, We Don’t Need (Private) Roads

Think about the future of computers over the next fifty years. Computers
will become even more ubiquitous, not just embedded in all of the things
around us, but /embedded inside us/. With advances in neural-computer
interfaces, there is a high likelihood that we will be connecting
computers directly to our brains within our lifetimes. *Which tech
company would you trust to control your neural implant*?

If a computer can read and write directly to your brain, does it change
how you feel about vendors controlling which software you can use or
whether you can see the code? Does it change how you feel about vendors
subsidizing hardware and software with ads or selling data they access
through your computer? Does it change how you feel about government
regulation of technology?

One promise of neural technology is to supplement humans with apps that
provide instant skills and knowledge. Imagine Apple and an app company
get in a dispute
<https://arstechnica.com/gaming/2020/09/apple-accuses-epic-of-theft-in-countersuit-over-ios-fortnite/>,
Apple removes the apps from that company from their neural implant OS,
and you lose the ability to speak Mandarin, drive, cook, play guitar, or
write software?

We can’t accept being a tourist on tech’s toll road, the future demands
open highways accessible by everyone, where you can freely go where you
want, how you want. Now is the time to disrupt these closed platforms
locked to and controlled by a single vendor. Openness and diversity are
advantages, not weaknesses, and the future demands more openness, more
collaboration, and more freedom and control given to individuals over
their own computers.

The solution is to invest in technologies and companies that are
building the open highways we need for the future. With Librem computers
<https://puri.sm/products/> and the Librem 5 phone
<https://puri.sm/products/librem-5/> running PureOS
<https://pureos.net/>, we are working to build platforms founded on free
software and open standards that put users back in control
<https://puri.sm/posts/with-purism-products-you-are-in-control/>. Help
us build the future we all want to see.

    Anbox on the Librem 5

Anbox now runs on the Librem 5, getting you access to many additional
free software apps that are packaged only for Android. We are also
working on streamlining the install process. Soon you’ll just need to:

  * Install Anbox
  * Put android.img into /var/lib/anbox/
  * Reboot

Sorry, your browser doesn’t support embedded videos.

In addition to simplifying the install process, while testing Anbox we
also identified and fixed a few bugs such as how maximized X11
applications <https://source.puri.sm/Librem5/phoc/-/merge_requests/189>
(such as Anbox) displayed on the Librem 5.

xwayland auto-maximization test.

With Android emulation unlocked on the Librem 5, the number of usable
mobile apps has once again jumped. It’s time to start thinking about
which apps you have to keep for now, and which apps could use the
ad-free respectful PureOS touch.

    Adventures of porting postmarketOS to the Librem 5

I’ve been longing to drop the shackles of Android ever since I made the
decision to stop using my Nokia N900. Nokia had given up on Linux
phones, and it was clear that there would be no further security patches
for my favorite smartphone of all time. Shaking Google out of Android
had been my mission for years, and I had resorted to running my own
builds of “de-Googled <https://en.wikipedia.org/wiki/DeGoogle>”
LineageOS. I was longing for something better. I was out of the country
when I first read about postmarketOS
<https://postmarketos.org/blog/2017/05/26/intro/> (“pmOS”) in May 2017.
postmarketOS is a Linux distribution based on Alpine Linux
<https://alpinelinux.org/>, that strives to provide a Linux distribution
running the mainline Linux kernel, as a means to revive old smartphones
long forgotten by their manufacturers. My beloved N900 was one device
with (rough) support! I quickly jumped on eBay to order a second N900 to
meet me at home when I arrived back, because obviously two are needed.
Obviously… Thus began my relationship with postmarketOS, one that
continues to this day.

Things were not all rosy though… After some time it became clear that
the older N900 CPU wasn’t going to get any faster for running “modern”
applications and that there would never be a free userspace graphics
driver for its GPU, so I was quite excited when I first learned about
the Librem 5. Sure, it didn’t have a physical slide-out keyboard, but
the promise of a device from a company that would treat Linux support as
a first-class citizen was too good to pass up. I promptly pre-ordered a
developer kit (“devkit”) and phone, with the full intention of porting
postmarketOS to the device and eventually using it full time to replace
the heaping pile of Android in my pocket.

      Some assembly required

Photo showing the Librem 5 devkit

The devkit couldn’t have arrived at a better time (sarcasm); right
before the holiday season! After spending the first few days still in
the box due to my “other obligations,” it was rapidly de-boxed and I
started planning my next move. Some cursory research told me that the
devkit used an SoC from NXP, used the bootloader u-boot, and was flashed
with a utility called |uuu|. Since I wasn’t completely sure how |uuu|
worked, and expected trouble once I started to experiment with using it
to flash pmOS, the first task was to solder on headers for using the UART.

This, as I suspected, proved to be a very worthwhile step. Purism should
consider just adding the header next time, though it was very simple to
DIY at any rate. The only other modification I made to the devkit
(completed a few days later) was adding an external 40mm fan right over
the SoC’s heatsink. It wasn’t necessary, but I did cause the device to
reboot at least once compiling Mesa, so I figured it couldn’t hurt. A
photo of this fan (shown later on) ended up causing some angst on the
Internet <https://latenightlinux.com/late-night-linux-episode-57/>.
Oops. After adding a battery, per Purism’s recommendation, I was now
ready to get some work done!

      “Don’t reinvent the wheel, just realign it” (Anthony J. D’Angelo)

Being new to using NXP (and Emcraft) devices, a large part of the first
day was spent trying to gather as much information as possible about how
this device boots, how to push images to it for booting, where in the
image it expects a bootloader (u-boot) to be “installed,” and the
required format and locations for the kernel and device tree file.
Emcraft had a surprising amount of information on their website, along
with some examples in the form of out-of-tree kernel patches and
pre-compiled binaries. By far the greatest breakthrough was discovering
Purism’s Jenkins CI instance. Being familiar with picking apart Jenkins
output because of $daily_job, I was able to figure out how Purism was
building all the major components. By searching Purism’s Gitlab instance
for the script names run in CI, I could locate the appropriate
repositories and source code for those scripts to use as a model for the
Alpine Linux packages I’d have to create for supporting the devkit and
phone in pmOS.

Armed with a basic idea of what I’d need to make an attempt at booting a
custom u-boot and kernel, I started looking in-depth at |uuu|. This was
a completely new tool to me, but it was very easy to package for
pmOS/Alpine Linux. The |uuu| utility can be passed a script with
arbitrary commands to execute, and once again, Purism’s prior work on
this provided me with a helpful template to use later on when I had
created a pmOS image for flashing to the device. I was able to use the
u-boot image from Purism’s devkit artifacts to verify that my packaged
|uuu| worked

The next step was to look at building/packaging the u-boot, the Arm
Trusted Firmware (ATF), and the Cortex M4 firmware for DDR training.
These were generally fairly straightforward to create an Alpine Linux
package for, though, since none of these components used
upstream/mainline source, the packages had to diverge from any that may
already exist in Alpine Linux (e.g., can’t use their u-boot) in order to
use the sources with any patches from Purism/Emcraft/NXP/etc. The
biggest hurdle here was that the M4 firmware needed to be a 32-bit ARM
binary, while everything else was compiled for AArch64. The package
repository specific to pmOS (pmaports) includes cross compilers, so I
was able to compile/assemble the single image bootloader into one Alpine
Linux package. Not exactly ideal, and would almost certainly be rejected
by upstream Alpine, but it was quick/easy, and simple to debug. Purism’s
CI and supporting scripts were heavily utilized in order to figure out
the right sequence of steps to build things, where to “install”
resulting binaries, and how to generate a correct image with them all
included.

Getting to the point of having a working u-boot/firmware image required
some trial and error, some of which was no fault but my own, and having
that UART header on the devkit was absolutely required for me to resolve
all of those early, pre-Linux kernel boot issues.

      Anatomy of a mobile device in postmarketOS

Devices in postmarketOS are supported by device-specific Alpine Linux
packages that are responsible for installing any additional
configuration unique to the device, and providing parameters to the tool
(|pmbootstrap|) responsible for building pmOS images for flashing to the
device. Common components of a device package in pmOS include things
like configuration files for setting up audio, and parameters for
specifying where to “install” u-boot in the image that is generated.
|pmbootstrap| makes it very easy to create a skeleton device package, by
just specifying the new device when running |pmbootstrap init|. The hard
part is collecting all of the various configuration files that help
enable and set up hardware for the device. Once again, Purism’s public
repositories to the rescue! By grepping my way around their public repos
(e.g.,librem5-base <https://source.puri.sm/Librem5/librem5-base>), most
functionality on the Librem5 present in PureOS could be enabled in pmOS
early on. Most devices in pmOS, unfortunately, require downstream
kernels. The devkit and phone (as of today) are no exception, though it
is close enough to mainline that I didn’t have to apply any of the
various hacks that pmOS includes for dealing with ancient, abandoned
downstream kernels. As a result, it was relatively straightforward to
create an Alpine Linux package for building/installing Purism’s kernel
fork. The last major piece was graphics. I could have ignored this if I
only wanted to boot to a console using the framebuffer, but that’s no
way to use a smartphone in 2020! (/troll)

I wanted to run Plasma Mobile and Phosh, and the only way I could do
that was with a version of Mesa that supported the GPU on the devkit. At
the time, support for this GPU was upstream in Mesa, but it had lots of
issues. If I wanted to have a decent chance of running a hardware
accelerated graphical environment, I would have to package Purism’s Mesa
fork. This would end up creating all sorts of issues later with package
dependency resolution in Alpine Linux (conflicts with Alpine’s Mesa
package and subpackages were frequent), so thankfully this was only
temporary until Purism landed all of their patches in upstream Mesa.

      Going the extra mile

I now had everything needed to generate my first bootable postmarketOS
image for the devkit, and flash it to the device!

The Librem 5 devkit (and phone) require two firmware files for booting,
as mentioned previously: u-boot and M4 firmware. |pmbootstrap| knows how
to deal with embedding u-boot firmware (used by some devices supported
in pmOS), but did not know how to embed two separate firmware into the
flashable pmOS image. Another patch adding this functionality, and some
more device package config parameters were all it took. /Now/ I was
ready for…

      First boot!

Photo showing first boot of postmarketOS on the Librem 5 devkit

At the time, the devkit’s onboard display was not functional, so I had
to make do with HDMI to an external display which, fortunately, worked
perfectly. XFCE is a fairly lightweight desktop environment with (most)
Batteries Included by default, so it’s a favorite of mine for the first
boot of pmOS on a device.

Plasma Mobile largely worked out of the box too, though I did get some
help from KDE developer Bhushan Shah. Nothing says success like a dark,
slightly blurry photo taken at 1:49am.

Photo showing Plasma Mobile on the Librem 5 Birch

A lot of folks in the Purism Matrix channels are excited about “device
convergence,” in particular using your phone with an external
keyboard/mouse/monitor as you would a desktop PC. Not to be the one left
out, I thought it might be fun to play Elder Scrolls 3: Morrowind (via
OpenMW <https://openmw.org/en/>), which basically requires a
keyboard/mouse to use. After packaging OpenMW in Alpine Linux, I was now
able to play one of the best RPGs ever made on the devkit. Albeit, not
at a super smooth frame rate, but that was to be expected given how
early this hardware was and the current state of its support in Mesa.

      A Linux distribution meets a Linux phone

Photo showing first boot of postmarketOS on the Librem 5 phone

Fast forward a few weeks, and Purism is starting to ship their first
phones to the general public. I deferred receiving the phone I ordered
until the “Evergreen” batch, because I wanted a higher quality device to
use for years. I was bummed that I was stuck using a devkit with pmOS,
and was starting to regret my decision when Purism was kind enough to
lend me a Birch phone to play with. No time was wasted deleting the
PureOS image on it (sorry Purism!) to make room for pmOS. Luckily the
same SoC was chosen for the phone, so only minor changes were needed to
the device package in postmarketOS since the phone shared the same
kernel and u-boot source code as the devkit. The u-boot configuration
was different, but that was just a matter of selecting the appropriate
defconfig at compile time.

        UARTs UARTs everywhere, but not enough to use

One thing that was worrisome from the start was the lack of readily
accessible UART on the phone for debugging issues pre-Linux boot. Now,
this wasn’t something most users of the phone would care about, but I
had relied on this extensively on the devkit to find the right
combination of configuration parameters for booting pmOS. The schematics
for the phone show there are 4 UARTs, but none of them have headers
pre-installed, and 2 of them are available in the super tiny test point
pads under the back cover. A few devices that we’ve used with
postmarketOS support serial console out via a 3.5mm headphone jack. That
would have been a nice feature for the Librem 5, but wishing for it
wouldn’t help my current situation.

Eric Kuzmenko from Purism pointed me to an M.2 debug breakout board that
apparently Purism was using in-house at one point, and provided me with
a version of the layout that exposed only UART. I had this board fabbed,
but still (as of today) have not succeeded in getting u-boot to output a
serial console over it. So, if there are pre-Linux u-boot-related
issues, I’ve had to fall back to using the devkit to debug them. Luckily
I haven’t yet had any pre-Linux boot issues specific to the phone.

It’s worth noting that this is largely a problem for me and anyone else
who wants to port an OS to run on this device. The vast, /vast/ majority
of users won’t miss having easy UART serial console access.

Fortunately for my first attempt at booting on the phone, the only issue
I ran into was accidentally using the u-boot image built for the devkit.
Oops. And, fortunately, that didn’t result in any magic smoke being
released!

      If it looks like a phone and acts like a phone, it must be a phone

Photo showing SMS on a Librem 5 phone running postmarketOS

It wasn’t long after this that Purism was demonstrating the modem work
they had enabled in their PureOS distribution. Enabling the phone’s
modem with ModemManager was easy, but audio was not being routed
correctly during a phone call. Purism released a small application
called |wys| that handles audio routing during phone calls, so after
packaging this application for Alpine Linux (so it was then available in
pmOS), I was able to make and receive phone calls to some degree. Audio
quality and proximity sensor support still needed a little work, but the
makings of this being an actual phone were already there. SMS just
worked on pmOS with no changes at all, which was a very pleasant
surprise after having spent a lot of time in the past figuring out how
to send and receive an SMS using ofono test scripts on the N900. Mobile
data connections also just worked in pmOS with Phosh and ModemManager;
another very pleasant surprise!
Photo showing postmarketOS running on a Librem 5 Dogwood

      So…what now?

postmarketOS on the Librem 5 is off to a great start but there’s still
much more work to be done (both upstream in PureOS and postmarketOS)
before I’m comfortable depending on the Librem 5 full time to replace my
current mobile phone. For those interested in playing along, the current
status of postmarketOS support on the Librem 5 can be seen on this
Gitlab milestone
<https://gitlab.com/groups/postmarketOS/-/milestones/5>, and you can
drop by our IRC/Matrix channels here
<https://wiki.postmarketos.org/wiki/Matrix_and_IRC>.

While there’s always room for improvement, working with the Librem 5
devkit/phone and Purism has been super refreshing. I would not have been
able to move as quickly to port postmarketOS to the Librem 5 without the
tremendous amount of help from Purism; both implicit by way of public
repos and CI, and explicit from Purism employees responding to my
queries. Many devices booting postmarketOS are largely ignored or
forgotten by the manufacturers that made them, and use some super old
downstream kernel originally meant to run with Android, so the effort to
get pmOS working on them is a much larger hill to climb. I welcome this
new age of devices with first class Linux support!

    Making a 3D graphics video for the Librem 5

At Purism, we do all our videos and other promotional material
internally, with Librem hardware and free software only. This is part of
our policy and I think it’s important, when I believe in something, to
act in accordance with it.

A few days after releasing the video of the Librem 5 hardware design, I
was asked by a few people to publish an article describing the process
of making this video.

In early 2019, we shot a funny commercial for Librem One and I made a
blog post <https://puri.sm/posts/see-your-junk-behind-the-scenes/>,
along with a video, to explain the process of making this kind of
commercial with Librem hardware and free software. I was not going to do
a “behind the scenes” blog post again but the Librem 5 video is entirely
made with 3D graphics and the workflow is quite different so I think
that it is interesting to describe that process in a new post.

Sorry, your browser doesn’t support embedded videos.

      Making the 3D model

The goal of this video is to show the design and features of Librem 5
hardware. So, in other words, to disassemble the phone and to show
what’s inside it in terms of hardware.

In order to achieve that in a visually elegant way, I decided to go
through a 3D model and do the entire video with computer graphics.

Modeling the phone and all its electronic components was a long task,
that, done in parallel with other projects, took me a few months to
complete. I started just after the release of the Chestnut batch and
completed it a few weeks before the release of the Dogwood batch that
had a slightly different design. The key points being the same between
Chestnut and Dogwood, I decided to release the video anyway, without
going through the long process of modeling again.

I used Blender and as I am not a proper 3D modeler, I had to learn while
I was advancing the 3D model. Blender and its community are so great,
that it is not difficult to find the right information. I learned a lot
during this project.

      Animating the model

Once modeling was done, came the fun part of animating! I love animating
because it feels like giving life to something. There is something
magical in animations in general.

To do so, I put the 3D model in its own Blender file, in order to reuse
it whenever I need to, and linked it into another file that would hold
my animation’s main scene. I am not sure if that is the best approach
for this particular animation but it worked for me. From there, I put up
a simple scene with a few lights, a touch of color, and I started
animating.

Even though, I divided the video into several scenes in the script, I
ended up animating the whole sequence in a single timeline, as a unique
sequence shot.

I ended up rendering the animation as a PNG image sequence with the new
EEVEE render engine from Blender, which is very fast on my Librem 13
while producing a pretty realistic output.

      Adding the audio

Although we do visual art internally at Purism, we don’t do music.
Therefore, I had to find an existing track for this project. Finding the
right music is always pretty difficult. I know that music tastes are
subjective and I usually try to find a track that matches the rhythm and
the mood of the video. I also look for music that is released under a
free license in order not to be in conflict with the free license of the
video itself (all the website’s visual material is released under a
CC-BY-SA 4.0 license).

Thankfully, there are some amazing artists in the world of free art and
I ended up using the beautiful track “Sphere” by Creo, which is modern,
full of energy and happiness.

I used Kdenlive to edit the music with the image sequence that I
generated from Blender. I didn’t know which music I would use while
doing the animation so I had to slightly edit the image sequence for it
to nicely match the rhythm of the music track.

      Conclusion

I love working on this kind of video project. It makes me put my head in
my dreams, my creativity, like when I was a kid, but this time with the
tools to bring this creativity to life.

Lately, I have been working on another project that was very special to
me. It is a traditional hand made animation, that is not for Purism but
that I made with both my Librem 13 and Librem 15 along with two graphics
tablets, free software and lots of love. I will come through the details
of making this project in a future blog post. Stay tuned!

    Librem 14 Shipping in December

Librem 14

We set out to build our dream laptop
<https://puri.sm/posts/librem-14-thoughts-from-a-librem-13-early-adopter/>
with the Librem 14 <https://puri.sm/products/librem-14/> and that meant
adding new features such as:

  * Two SO-DIMM slots with up to 64GB RAM
    <https://puri.sm/posts/librem-14-launch-faq/>
  * Write-protected BIOS and EC chips with an internal switch
    <https://puri.sm/posts/librem-14-features-bios-and-ec-write-protection/>
  * Microphone kill switches that extend protections to the headphone
    jack
    <https://puri.sm/posts/librem-14-adds-microphone-kill-switch-enhancements/>
  * Enhanced WiFi M.2 slots for hardware hacking
    <https://puri.sm/posts/librem-14-features-enhanced-wifi-m-2-key-e-slot/>
  * Extra control over the embedded controller, and a new
    user-controlled notification LED
    <https://puri.sm/posts/librem-14-enhancements/>

The Librem 14 is going to be a powerhouse with a six core, twelve
thread, 4.70Ghz i7-10710U tenth generation Intel CPU. When we first
announced the Librem 14 pre-order, we estimated shipping would begin in
early Q4 2020 but unfortunately Intel has industry-wide supply issues
with the i7-10th gen CPUs which has moved the ship date for the Librem
14 to December 2020.

That’s the bad news. The good news is that the current $100 pre-order
sale <https://shop.puri.sm/shop/librem-14/> will continue for a bit
longer. We also hope to finish some fresh Librem 14 prototypes in about
a week, so we can share new pictures of the design.

    Pre-Order Your Librem 14 Today!

Get Purism's powerful, private, secure Librem 14 laptop.

/Currently $100 off!/

Pre-Order Librem 14 <https://shop.puri.sm/shop/librem-14/>
Purism

Thanking you for your support,
— the Purism team (feedback at puri.sm)

------------------------------------------------------------------------

Note: contents of this email are CC-by-SA; feel free to forward it to
friends!

/To remove yourself from our announcements list, simply email
announce-leave at announce.puri.sm <mailto:announce-leave at announce.puri.sm>
and you will automatically be instructed how to unsubscribe./

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://announce.puri.sm/pipermail/testannounce/attachments/20200923/af3b8308/attachment-0001.html>