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
Arguably the most critical functionality in a phone is the ability to make and receive calls through the Public Switched Telephone Network (PSTN), that is normal cellular calls using phone numbers. While at Purism we are eager to implement communication systems that enable much greater privacy and security than one can expect from PSTN calls, the PSTN is still the most ubiquitous network and for the time being we can’t very well go around selling a phone that isn’t able to make PSTN calls. Read more
Hello everyone! A lot has happened behind the scenes since my last design report. Until now, I have been reporting on our design work mainly on the software front, but our effort is obviously not limited to that. The experience that people can have with their physical device is also very important. So in this post I will summarize some recent design decisions we have made both on the software side and the hardware product “experience” design.
Thinking about the physical shell
Our goal with the Librem 5 is to improve the visual identity of the Librem line while staying close to the minimalist and humble look that characterize the existing Librem line.
The main challenge of case design is the need to balance aesthetics, ergonomics, convenience, and technical limitations.
As you know, the Librem 5 is a special phone that will not integrate the same CPU and chipsets as usually implemented in the vast majority of smartphones in the market. Power consumption is a very important factor to take into account, but so is battery capacity and printed circuit board arrangements, and we don’t want to sacrifice battery life for a few millimeters of thickness. Therefore:
We are now aiming for a 5.5″ to 5.7″ screen with a 18:9 ratio that would let us incorporate a larger battery without affecting the shape of the phone.
We are also opting for a shape with chamfered edges (as pictured below), instead of the usual rounded ones. Not only do we think it looks elegant, the general shape would provide a better grip and it give us a bit more room inside for components.
Simplifying the UI shell
As the implementation of the Librem 5 goes on, we are quite aware that time is limited given our January 2019 target, and we are therefore focusing on robustness and efficiency for the first version of the mobile UI shell (“phosh”), which we wish to push upstream to become the GNOME mobile shell. As you may recall from our technical report from early March, we had discussed with GNOME Shell maintainers, who recommended this clean-slate approach.
We revisited the shell features and decided to split the design and implementation into several phases.
Phase 1 defines a shell that is at its simplest state in term of features and usability. This is the shell that should ship with the Librem 5 in January 2019.
This shell includes :
A lock screen.
A PIN-based unlock screen for protecting the session.
A home screen that displays a paginated list of installed applications.
A top bar that displays useful information such as the time, battery level, audio level, network status…
A bottom bar that simulates a home button (only visible when opening an application).
A virtual keyboard.
Incoming call notifications.
The “call” app is indeed a special case application on a phone, and that’s why we’re prioritizing it for the notifications feature: it has to work from day one, and it has some requirements like the ability to interact directly on the lock screen (to answer an incoming call, or to place an emergency services call).
Multitasking UI workflows, search and more flexible app notification features/APIs should be implemented during phase 2, available a bit later.
While “phase 1” might not be the all-you-can-eat features buffet some may be accustomed to, we think that this minimalist shell will be extremely simple to learn, use and will favor a quick and painless adoption. And it’ll be a great starting point.
Designing the Contacts application
The Contacts application will be at the center of the communication features. It is the application that will handle the contacts management that other applications such as Calls or Messages will rely on.
For that matter, we are adapting the existing Contacts application by designing its mobile layout and adding extra fields that will be required by the different communication applications.
Librem 5 & Fractal team hackfest in Strasbourg
This week, a few members of the Librem 5 team (including myself) are attending the 2018 Fractal design hackfest in Strasbourg, with the goal of helping the Fractal team to make a beautiful and secure Matrix-based IM application to be used on both the desktop and mobile platform. I hope to do a report on the communication features of the Librem 5 in a future post where I will talk about what happened at the Fractal hackfest.
At Purism, we are just as excited as you are about the the development boards that will be distributed this summer. Once a person receives their development board, their first thought will be “This is great! Now, what do I do with it?” In anticipation of the technical guidance that will be needed, the developer documentation effort has begun. You can already see the current state of the documentation at developer.puri.sm
Goal of the Docs
The developer documentation is there as a guide for getting a new developer setup and ready to start having fun! This will include plenty of examples that will help you along towards whatever your goal with the development board may be.
There will be technical step-by-step instructions that are suitable for both newbies and experienced Debian developers alike. The goal of the docs is to openly welcome you and light your path along the way with examples and links to external documentation. These examples will aid you from the start of unpacking your development board to building and deploying flatpak applications to it—and eventually including your package into PureOS. Included, you can expect examples on how to use certain tools like flatpak, the IDEs used to build flatpak applications, and UI tools to help you design apps. The design of the Librem 5 phone interface will also be outlined in detail to provide insight into the human interface guidelines that will be followed by the core applications. Use the design section to learn about gestures you can expect on the phone. Apps you design or port to the board can use these gestures too!
Please note that the docs are not a complete tutorial on how to use all of the development tools required. There are existing documentations available for each specific tool so there’s no need to reinvent the wheel. Instead, you will be directed to those locations online so you can research further on a specific tool.
We welcome all test and development efforts that volunteers have to give, so there will also be information on volunteering and how to become a Purism community member in general.
Work in progress
The documentation is in a constant state of flux. Content is being added daily and reorganization still occurs from time-to-time. If you no longer see a page there, just search for it because chances are it has been moved to somewhere else within the site instead of removed. The aim is to write documentation that is helpful and intuitive so it is important that an intuitive path is laid out. This developer documentation is still pretty new but is filling out quickly so that you are ready to hit the ground running with your new development board in June!
There will be a separate announcement in the next few weeks on this same blog to call for volunteers so get ready!
Purism’s long-term goal has always been to make computers that are as convenient as they are respectful to the people that use them. The Librem products are an ethical platform and therefore should not be discriminating anyone; instead, they are meant to be inclusive of all human beings. In other words, everyone should find in their Librem a convenient and secure platform for their daily usage, and therefore accessibility should also be an important part of our ethical design roadmap.
We are aware that the road is long and that the Librem 5 is a challenging project, so we need some design foundations that favor convenience as much as it can lighten the development effort to get there.
Apps on existing platforms compete for your attention
With today’s smartphones, you usually get a minimal set of functionalities out of the box and go through installing diverse applications for your different needs. Usually those applications are proprietary and are designed around their own unethical business model; hence they compete against each other for your attention and have their own set of features to be used within the scope of the application only.
This can lead to a lot of redundancy and confusion in terms of functionality. A particularly blatant case is communication applications, where we see each application handling their own contacts logic, their own locked down and isolated protocol, and where a ton of applications will implement the same things for the same purpose (making calls and sending messages), with the focus typically being the flashiest application to attract and retain the most users. Let’s illustrate how ridiculous this is, conceptually:
Envisioning a harmonious app ecosystem
In the real, natural world, sustainable ecosystems are made of biological entities interacting together in harmony or symbiosis. This is what makes life possible over the long term.
The digital world of Free/Libre & open-source software, particularly in operating systems, is highly similar to the natural ecosystem. In this world, there is no such thing as isolating off or protecting a technology if you want to be part of the system. Business models and interests are completely different from the world of proprietary software. Best practices favor reuse and integration, improving user experience, reducing technical debt, increasing software quality and lowering development costs, with a “collaborative” system where different applications from different authors are made to work together.
The Purpose is the Feature
The idea behind the PureOS design guidelines is to replace the concept of standalone, independent and feature-competing applications with a concept of small, single-purpose, cross-integrated applications—that would interact between each other to provide a unified experience across the device (and beyond). Those small applications can be seen as “features” of the system. 1 purpose = 1 feature.
Therefore, the Human Interface Guidelines’ main principles regarding “features” development would be :
Don’t see applications as independent programs but as “features” that have a single purpose and that interact with each other.
One “feature” application is guarantor of the security of the data flow going through it. Only make your “feature” application share data with “trusted” features or networks and in a secure way.
Make a “feature” application focused on one single purpose (an email client is not an address book nor a calendar)
Make your “feature” application rely on existing features (an email client should rely on the existing address book and the existing calendar “features”)
Avoid redundancy. Don’t try to reinvent existing applications. Improve them instead.
Setup your “feature” application by default. Make it work out of the box.
Advantages
On the user’s side, the features of the device are easy to spot as they are made available through single-purpose applications displaying an obvious name. For example, the “Call” application is made to make calls, no matter the technology used behind that (e.g. Matrix, phone, voip). The “Messaging” application is used to send instant messages, no matter the technology used behind that (e.g. Matrix, SMS, XMPP). The “Contacts” application is used to manipulate and store the contacts information to be used by the “Call” and “Messaging” applications.
On the developer’s side, applications are as simple as they can be, the use cases are limited, all the logic that is not related to the main purpose of the application is delegated to other programs, which makes the application easier to design, implement and maintain.
Data belongs to the user, not the application
In this collaborative application system, where applications can interact with each other in harmony, data is not limited to the application’s logic anymore. Applications are acting as services, or “data providers”, to each other. Data can flow from one application to the other, from one device to another, from one network to another.
This concept implies the separation between data and functionality where the data belongs to the user only. The application that manipulates it is guarantor of its integrity and security.
Please note: these are guidelines, representing an overall vision. Guidelines are there simply as a way to guide application design, and to suggest best practices for application developers in general. Given that a GNU+Linux distribution like PureOS is an open platform where thousands of applications are available independently (as long as they are freedom-respecting!), you are not obligated to conform to these design guidelines to be able to distribute your application through Debian and PureOS. Furthermore, these design plans represent a broad long-term plan, not necessarily a guarantee of what will be happening “immediately” in the first released version of the platform that ships, your mileage may vary, etc.
The Librem 5 is a big project. And like a lot of big projects, as you probably know, it can appear overwhelming, until you can break the parts down into logical steps. Like a large puzzle scattered on a table, our team has been organizing and beginning to assemble all the pieces. This is very exciting to progress through the initial daunting scope, accepting the tasks, start working and then… after some time, solutions emerge and almost magically align.
In our previous blog posts we described what we were starting to work on, and these efforts began to prove themselves out significantly during our week-long hackfest where part of our software phone team gathered last week in Siegen, Germany. Read more
Peter has been quite busy thinking about the most ergonomic mobile gestures and came up with a complete UI shell design. While the last design report was describing the design of the lock screen and the home screen, we will discuss here about navigating within the different features of the shell.
The mock-up on the right describes the main navigation principles. It shows the basic gestures that can be used to navigate through the different features of the shell.
From top to bottom:
(N) – Pulls down the full list of notifications.
(S) – Pulls down the full list of system settings.
(Q) – Reveals the most frequently used settings.
(W) – Quick launcher (to quickly access the communication features).
(A) – (3 seconds) Reveals the list of running applications.
(H) – Navigate back to the home screen.
And below are a few more mockups illustrating additional planned features of the Shell:
The multitasking overview screen that is revealed through the gesture (A) shows a carousel of all running apps along with their icons to make them easier to spot and access in a touch.
Swiping up from the bottom of the screen, from gesture (H), brings back the home screen
The “quick launcher” from gesture (W), in this example, is launching a list of (favorite) contacts for a quick access to the communications features.
An experience for people first, not just “app stores”
Now that we have defined the main features and gestures of the shell, it should be time to take care of the applications’ interfaces next.
If the Librem 5 was “Yet Another Android phone,” I would say “Go! Let’s make a bunch of apps!” But the Librem 5 is not just a regular phone, and Purism is very different from Apple and Google in term of philosophy and business model—they have been focusing on having the “biggest” app stores, selling apps, and mining data… and we don’t do that.
Therefore, before hastily moving forward with designing applications interfaces “like the other platforms”, not only must we study the current state of the mobile industry in term of User Experience, we must also try to think on how to improve it with a user-centric paradigm instead of necessarily app-centric. I think that, in some ways, there are many areas where the Librem 5 can bring greater simplicity, making iOS and Android look over-complicated in comparison. It may sound crazy to say that, but bear with me for a moment, we’ll get back to this later on.
By understanding a few concepts, we can try to define some human interface guidelines that will help getting a better user experience by default. This won’t prevent the phone to remain a highly customizable FLOSS platform—it will just help making the Librem 5’s “out of the box” experience more useful for everyone.
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!
Software Work
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:
Click to enlarge
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:
Click to enlarge
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:
Wi-Fi
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 is always great to have the opportunity to discuss face to face with community members to get the pulse of what their thoughts are and suggestions they might have for the Librem 5 project. As such, I was happy to spend time discussing at length with people attending FOSDEM this week-end. Comments from the many supporters made me realize that there are some points regarding goals and vision, in terms of design for the entire Librem line, that needed to be expanded upon and clarified. Keep in mind that although the vision for our short and long-term design goals for the Librem 5 is becoming increasingly clearer, it is of course still “work in progress” from a design perspective; things are not set in stone and therefore we are listening (and responding) to the community’s feedback.
Convergence, for Purism, is a long-term goal to unify the human experience across different devices.
A user interface is made of a layout and interactive elements. Different devices using different input and output technologies will have different requirements for layout and interaction. In this case, our approach will consist in designing “responsive” (adaptative) layouts and interaction patterns that will allow modern apps to adapt themselves to the device that it is running on. We don’t have to port/adapt every single existing desktop app under the sun to achieve that goal though, and our partners in the GNU+Linux community have aligned goals with this direction.
That approach of convergence is also about the simplicity of accessing the same data and services between different devices, transparently.
Part of our plan for convergence is about helping define some consistent Human Interface Guidelines and optimizing the development tools & documentation, in order to help developers create a great experience across devices.
The implementation of our design involves the use of existing technologies, and the UI+UX design itself is not made with a specific technology in mind. Our design work is an attempt to define a set of Human Interface Guidelines that rely on the Ethical Design manifesto and our requirements for security and privacy. The technical details of its implementation are out of the scope of this design report and should be discussed with the development team.
Designing a Mobile Experience
Over the last two weeks, we have been thinking about general human interaction principles for the Librem 5. Our idea is to define the best possible mobile interaction design principles and combine it with an “optimal” mobile shell experience. While what you will see below is simply a high-level overview of work in progress that may change before final public versions, it is setting the stage, and is a good starting point for our upcoming work, such as the communications features that I’ll soon write about in a separate blog post.
Some Basic Principles
We think that a good mobile experience should define convenience and comfort when using the device. It should take into account the hardware in all its aspects along with the many different use cases. In that regard, it is important to define principles that are adapted to the physical device. One of these principles is that one-handed usage of a phone is frequent, and so our interaction design should take this fact into account.
One should be able to easily access the most important features of the phone when holding it with one hand; it supposes touching the screen with the thumb only. That doesn’t necessarily mean that all the screen surface and features must be accessible by the thumb (given the planned 5.5″ screen size, that would not be physically possible), but that the lower area is preferable to access the most useful phone features by default. Those features would include answering an audio or video call, reviewing notifications, unlocking the phone, accessing the home screen, requesting a search or launching the most frequently used applications.
To remain useful for both right and left-handed persons, the optimal area should favor the bottom half of the screen while also avoiding going too far towards the edges (that may be more difficult to access).
The size of the touch (tap) area is also something to take into account in order to give the user the best precision when interacting with the user interface.
Action targets like links, buttons, sliders and other interactive UI elements should take into consideration a sufficient surface size to be used with comfort and precision.
A First Look at the Shell
Peter K., our lead UI/UX designer, has been working on adapting these basic principles to the overall UI shell experience :
The main navigation happens at the bottom half of the screen, and similarly the majority of the interaction with the Lock Screen would happen in the lower half of the screen. When unlocked, the phone would reveal the Home Screen and show the most frequently used applications (or features) of the phone by default. Some useful widgets may use the remaining space (our example is showing music controls and web search widgets). Swiping up the frequently used applications icons reveals the full list of applications as well as the “main” search field, that is also accessible at the bottom of the screen. Less recurrent gestures, like accessing the settings or the detailed list of notifications, are available in the upper part of the screen.
More to Come
This was a quick appetizer regarding the ongoing design effort. Upcoming work will be about finalizing the shell experience and designing privacy-respecting communication features, so stay tuned!
