NixOS on my phone?

It’s quickly becoming a reality! Look at the devices list to see if your device is already supported. Otherwise, read about the porting process to understand if you can get NixOS on your phone.

News Items

July 2020 round-up

August 4th 2020

This update is the ninth in a series of regular updates on the state of the project.

Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There’s always more work currently in-progress.

Notable changes

As with last month, a big part of the 10 pull requests merged were bug fixes or minor changes. Though some valuable work was also finished.

Asus Zenfone Max Plus (M1)

The port for asus-x018d is mainly notable for being the only alternative system to the OEM-provided Android system, with the exception to a TWRP that is using the OEM-built kernel.

This means that, for the first time, Mobile NixOS this is the only alternative system for a device, including other Android-based systems.

Finishing with a last note, this device has an older Mediatek SoC, compared to the other ported Mediatek device. There is not much to say, except that it was found that older Mediatek devices may exhibit a similar quirk to Qualcomm devices, where the framebuffer has to be refreshed explicitly for the display to be updated.

External device definitions

I hesitate to openly discuss about this pull request, as it might make contributors think they should not contribute their devices back. #162 adds a mechanism to maintain and build external device definitions.

These external definitions should only be used for devices that are not welcome to the main project. The main reason a device would not be welcome is if it is not a “Mobile device”. An example of such a device is the Pinebook Pro, which is a laptop. Another example would be porting to SBCs like a Raspberry Pi.

Updates for the boot GUI

This change, #189, is where most if this month’s development time was spent. The toolkit used for the boot GUI has been forked and adapted to serve the goal of providing a GUI for mobile devices better.

As part of the changes, some minor UX (User eXperience) changes have been made, but more importantly, major changes like properly supporting mouse and touch screens in an independent manner, and providing keyboard-driven input. This also adds support to navigate the GUI with the volume keys and the power button, which is a common scheme used to provide a fall-back navigation when touchscreen support is possible.

Except for the new way added to interact with the GUI, there are no major changes to how the GUI is used. Though the work is a first step to provide more in-depth options during the boot process, like tracking progress, and required user input for actions during boot like passphrase input.

New ports

One new device was merged this month.

Bringing the total of devices to 13.

June 2020 round-up

July 7th 2020

This update is the eighth in a series of regular updates on the state of the project.

Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There’s always more work currently in-progress.

Notable changes

Most of the 9 pull requests merged were trivial or minor changes. Though there’s still some notable changes.

Pinephone bluetooth support

It turns out all it needed was a trivial fix. Giving it the firmware it wanted adds proper support for bluetooth on the Pinephone.

If you are using the examples/demo rootfs, its configuration does not currently configure the system for audio with bluetooth. The instructions to configure audio for bluetooth are the same as usual, as Mobile NixOS is composed on top of NixOS.

Redmi Note 8 Pro

The port for xiaomi-begonia is mainly notable for being the first port for a Mediatek SoC.

I am singling out this port as a proof that the breadth-first development style is working well. Since Mobile NixOS had many abstractions needed for the existing different platforms, this new platform, and device, was ported without a sweat.

This also paves the way for other Mediatek ports by providing a working example. Coupled with #175, another, older, Mediatek device (merged in early July), there is enough material to give clues for future ports by community members.

New ports

One new device was merged this month.

Bringing the total of devices to 12.

May 2020 round-up

June 2nd 2020

This update is the seventh in a series of regular updates on the state of the project.

Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There’s always more work currently in-progress.

Notable changes

11 PRs were merged during the month. Changes are mostly cleanup and documentation related.

Documentation changes

The biggest change is the addition of an overview of the terms used to define a device (#148). This documentation section should help better understand how devices are composed.

The README (#138) as shown on GitHub has been reviewed to better guide users and contributors around the ecosystem, borrowing the organization of the main Nixpkgs README. Though the main reason for this change is that the README started to diverge with the documentation. Removing all examples and referring to the actual documentation files reduces the burden of maintaining multiple documentation fragments.

Code and architecture cleanup

Through some of the pull requests, a bunch of either dead, or ossified code was found and removed. The main user-facing change is the removal of device.info.

The device.info option was a mixed bag of misshapen, undefined options that were at the foundation of all device definitions. The replacement are discrete well-defined options that are defined in understandable categories. Systems define options that they use, making it easier to understand why an option is defined.

The main consequence of that change is that the current work-in-progress ports will need to be reviewed to use the new options.

As part of #155, additional cleanup was made in the first few commits.

New examples/hello system

While technically a new feature, the new examples/hello system (#155) is more of a first-user-experience "bugfix" than a useful new feature.

This introduces a new example system that can be cross-compiled entirely, and shows an interface to the end-user. This helps fix the biggest complaint about the project: the default build looks as if the system has stopped responding.

Though this is not actually fixing that complaint, it does not replace the default build output. Users making a new port, or testing an existing port, will rather be encouraged to first try building and using this example to confirm the port works.

 $ nix-build examples/hello --argstr device DEVICE-NAME -A build.default

A planned addition to this feature will be more features to test and validate support for different subsystems of the device. Currently this only tests the touchscreen (through requiring it for navigation) and validates the display shows the colours appropriately.

Additional highlights

Ports

No new port were made in May. There is still a total of 11 devices you can build for.

April 2020 round-up

May 6th 2020

This update is the sixth in a series of regular updates on the state of the project.

Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There’s always more work currently in-progress.

Notable changes

11 PRs were merged during the month. Not an exciting month with fun and visible progress, but let’s point out interesting changes

Device specific website pages

The Devices List section is now formatted as a table, and links to one page per device.

This page can contain device-specific notes, and generally contains generic instructions depending on the device type. The side-bar uses generated content, but the page will use the README.adoc file when found in the device directory.

All of this is part of PR #120.

Supported way to include from system configuration

In PR #123 a supported way to include a device configuration to the system configuration was added. The Getting Started page explains the details.

This is useful when combined with the next higlighted changes. The device specific configuration doesn’t have to be handled by the end-user, the Mobile NixOS configuration handles it.

WCNSS WLAN quirk

PR #126 adds support for WCNSS WLAN in Mobile NixOS, while enabling it for the only device that supports it.

This is the simplest Wi-Fi setup for Qualcomm-based hardware. Sadly, for other devices it’s much more involved.

Though, this does mean that we now have Wi-Fi support for one more device!

Bonus change: Buried in that same PR, we now use boot.initrd.enable = false rather than using isContainer. This fixes a couple of weird and annoying issues with the running system.

Device-specific polishing

These start implementing some polishing, in what I hope becomes the gold standard for device ports.

First, we configure the LEDs so the Linux kernel controls it during boot (z00t, oneplus3). This provides a tangible proof to the end-user that the kernel is currently in control and running.

Then, for asus-z00t, some kernel cleanup patches have been added. The first kind of change is to remove idiotic behaviour from the OEM kernel, like trampling over the kernel module load path. The second is more subtle, but welcomed when reading dmesg: reduce the useless logging present in some modules. The amount of logging is useless.

Finally, for oneplus-oneplus3, there’s a quirk to fix USB OTG support during boot. I don’t think any other device will need it, from a quick glance, but it’s still a good example of how to implement a quirk.

Ports

No new port were made in April. There is still a total of 11 devices you can build for.

March 2020 round-up

April 7th 2020

This update is the fifth in a series of regular updates on the state of the project.

Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There’s always more work currently in-progress.

Notable changes

17 PRs were merged during the month. (The link says 18, but one of them was, to me, late in February, read the previous news item).

Let’s look at some of these.

Pine64 Pinephone “Braveheart”

This was teased about on the author’s twitter account. The inexpensive Pinephone is the latest new device added to Mobile NixOS.

This brings a bit more than only a new device. This is the fourth system type added to Mobile NixOS. The added system type (U-Boot) in theory will give us the ability to support any U-Boot-based system in a common way. In practice the still unmerged and WIP #94 shows how this is true by using U-Boot with another Pine64 device, the Pinebook Pro.

A nice thing that was verified again with this new device port is that the stage-2 image (the rootfs, the system.img) is indeed universal. It is using the same AArch64 build of the system image as Android-based devices, and Depthcharge-based devices.

Our build for the Pinephone relies on the downstream kernel from the Pine64 community, with only one added patch. The same is done for the U-Boot build.

The added patches are user-experience-focused patches that are using the RGB LED of the phone to show the boot status.

Other than that, the hardware support is not complete, but it is supported at the same level as other devices, plus Wi-Fi working.

See PR #96 for all the details.

Hydra builds

This is not entirely an in-repository change. There’s #97 and #133 that are relevant to this. The mobile-nixos:unstable jobset on Hydra is the other part of the puzzle.

What this gives us is automatic continuous builds of Mobile NixOS against the nixos-unstable NixOS channel. From this, we can track changes that break the Mobile NixOS builds, and track internal breakage to some parts of Mobile NixOS.

This is not even the best part. As can be seen in #133, we are now delivering up-to-date stage-2 rootfs, which allows end-users without the required hardware to bootstrap themselves using a pre-built image. The requirement to have a native AArch64 machine to build the system image is no more. While not ideal, users could make use of their phone to build a customized image, or simply, do a nixos-rebuild on it.

It already paid its worth in gold, as by the time this was developed, two regressions were spotted and quickly fixed. And furthermore, I hope that the exercising of the cross-compilation framework will help the NixOS developers working on making cross-compilation better in NixOS.

Other mentions

  • Using GitHub Actions, #112 checks new PRs for some simple breakage.

  • Developers can now use nconfig to configure their kernel using the “porcelain” bin/menuconfig, as added in #109.

Ports

One new device has been merged during March.

  • Pine64 Pinephone “Braveheart” (pine64-pinephone-braveheart) [@samueldr] (#96)

Bringing the total of devices to 11.

February 2020 round-up

March 3rd 2020

This update is the fourth in a series of regular updates on the state of the project.

Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There’s always more work currently in-progress.

Notable changes

3 PRs were merged during the month. This is not cheating, the last merged PR was merged late on the 29th.

This is not development slowing down. Far from it. Four new projects were added to the Mobile NixOS GitHub organization related to this month’s work. Keep on reading.

Graphical boot selection

Hot on the heels of the re-written init, and as teased, a working graphical boot selection is now available for Mobile NixOS platforms.

There is more than meets the eye in pull request #80.

To make this possible, a GUI toolkit of relatively small weight has to be found. After some research, it was found in the LittlevGL library. While it is geared more towards actual embedded development, it does have a Linux framebuffer backend, support for evdev input. This is all standard stuff that is well supported on all targets. What is really nice with that library is it also supports a “simulator” target, which is basically an SDL window.

With that said, I personally don’t want to write C, especially in complex use cases. I already worked on mruby integration for the Mobile NixOS stage-1. It was only natural to write mruby bindings for LittleVGL.

With all the exposition done. What does this look like? The header image of this news post is composed of four devices running the GUI. An actual screenshot of the GUI follows, for better clarity.

Screenshot of generation selection

This is not a feature complete generic replacement for a bootloader. Though, it can become one when kexec support is added in the future.

Additionally, as touched upon in the pull request, these bindings will allow us to improve the graphical boot process. In a future improvement we’ll be able to add information about the current running step, and better failure state reporting.

Ports

No new port were made in February. There is still a total of 10 devices you can build for.

January 2020 round-up

February 4th 2020

This update is the third in a series of regular updates on the state of the project.

Usually, only changes that have been accepted and merged in Mobile NixOS in the given month are chronicled here. There’s always more work currently in-progress.

Notable changes

Only 1 PR was merged during the month. Though, keep on reading, as one of the biggest PR, started in mid-December, was the main focus of the month.

New Stage-1 init

This is quite the misnomer, while true, that the PR mainly introduced a completely re-done init, it brought much more.

  • "New-style" USB gadget (gadgetfs) handling.

  • USB Networking for newer devices.

  • Vendor partition firmware loading.

  • Logs multiplexing and saving in stage-1.

  • Proper reboot and poweroff in stage-1.

  • Actual handling of NixOS-configured specialFileSystems.

This new init is built using a dependencies-based system, reducing the complexities from the inflexible "big script" approach of the previous init. With this new approach, we can simply dump all of the things we need to happen in the init, tell them how they’re linked, and boot. The current implementation is naïve, but even with a naïve approach, the benefits are apparent. First, the developer does not need to care about the ordering of things, only describing what has to be, and what to do. Then, the relatively surprising part: this made things a bit quicker to boot.

This reduced reliance on sleep and wait times during the boot to provide assurance that things were ready, meaning that steps happen much quicker in succession. To the annoyance of the author, this means that the well-choreographed boot images whizz by too quickly, reducing their meaningfulness.

In the end, this is a hidden change, that serves mainly to ensure a rock-solid foundation for what’s coming soon.

See the PR for more details.

Upcoming changes

Speaking of coming soon, As previewed in a tweet, work is in progress to provide a graphical interface that can be used in early boot. This can be used to make a "recovery" system tailored to the project’s need, and more importantly, allow interaction in the boot process.

The main focus of early interaction is to allow selecting a generation to boot into. This is part of the NixOS experience, and is currently missing. Another benefit to an early UI is that it will give us the opportunity to enter a passphrase to unlock an eventually coming encrypted system.

Keep your eyes peeled for the coming PR!

Ports

No new port were made in January. There is still a total of 10 devices you can build for.

December 2019 round-up

January 8th 2020

This update is the second in a series of regular updates on the state of the project.

Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There’s always more work currently in-progress.

Notable changes

Among the changes, and the 10 PRs merged, these changes are highlighted.

Make the demo more useful on a touch device

These are changes to the "example" system. This is a finalized version of the demo system that was running on the devices during NixCon 2019.

The main difference is that this is not a raw XFCE desktop, but a pre-configured system that is more accessible on touch devices. The onboard on-screen keyboard is configured to be of a useful height. Additionally, XFWM has been replaced with Awesome WM configured to maximize all windows.

This is still not an appropriate mobile environment, only a collection of configuration that makes it work well enough to test things up.

Read more in pull request #63.

Enhance QEMU Device

The x86_64 based QEMU VM has seen fixes to, first, make it actually work right.

What’s more interesting in this PR is the patched VGA BIOS that rotates the expected resolutions (720p, 1080p) on their side in portrait mode. This is especially helpful when working on purely software things like improving the example system.

These changes are part of pull request #59.

Different stage-1 fixes

The root filesystem is configured to expand to the size of its backing partition during boot. Part of pull request #61.

Critical failure states are graphically reported. As documented, a full-screen color-coded "sad phone" gives a general idea of the error encountered. Part of pull request #58.

Ports

One new device has been merged during December.

Bringing the total of devices to 10.

November 2019 round-up

December 3rd 2019

This update is the first of a series of regular updates on the state of the project.

Only changes that have been accepted and merged in Mobile NixOS are chronicled here. There’s always more work currently in-progress.

Notable changes

Among the changes, and the 10 PRs merged, these changes are highlighted.

initrd: add fbterm modules

When the new mobile.boot.stage-1.fbterm options are enabled, a userspace implementation of a console is started, attached to the output of tty1. As of right now, this is a read-only view of the console.

This is still extremely useful on targets where the kernel-based virtual consoles will not work. As long as the framebuffer is setup, you can use the console to observe what is going on.

Documentation and website framework

This was briefly highlighted in the last news item, though let’s describe how the documentation and website generation ticks.

The generated documentation in the repository is always built using the same exact tooling as the website. In fact, the website is only adding files to the documentation directory to build itself.

This gives us the advantage of the documentation being trivial to build locally.

~/.../mobile-nixos $ nix-build ./doc/
these derivations will be built:
  /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-mobile-nixos-docs.drv
[...]
/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-mobile-nixos-docs

~/.../mobile-nixos $ ls -l result/index.html
-r--r--r-- 4 root root 1541 Dec 31  1969 result/index.html

~/.../mobile-nixos/mobile-nixos-website $ xdg-open result/index.html
[...]

The documentation, minus the news items, will open in your web browser, and work just like this website. The styles, the site map, everything is generated 1:1 compared to the website.

The mobile-nixos-website repository holds the machinery that updates the site, in addition to the news items. This is where content specific for the website is written.

You may also want to subscribe to the new RSS feed.

New ports

Three new devices were merged this month.

The Pixel devices should be trivial to adapt to their respective non-XL and XL variants.

NixCon Wrap-Up and Website

November 15th 2019

This past October, on the 25th, a talk about Mobile NixOS was held at NixCon 2019, in Brno, Czechia. The talk was recorded and is on the NixCon YouTube page.

Bringing us to the next point: this new and shiny website. This is was described as the next step for the project. This website is built by blurring the difference between the documentation of the project and the website. This means that, hopefully, neither the website or the documentation will lag behind in relevance. Additionally, building the site and contributing should be as simple as contributing to the documentation. Hopefully simple enough.

Last, but not least, a few notes about the Hackday at the 2019 NixCon. I was left with approximately no time to work on things myself, but instead was found surrounded by bright individuals contributing neat stuff to the project. Those pull requests are a good sample of what was done, though early work on the OnePlus 5 was not advanced enough to be contributed back.

Wrapping this all nicely, I found that the main issue contributors around me had was the lack of documentation about the porting process. I knew it was an issue, hopefully this new website and progressing documentation helps.