Mobile NixOS Development Log (2)

I initially thought I would have a writeup of the image builder infrastructure I was working on, but it will have to wait still.

Instead, here's a progress report on the project.

Booting to display-manager

Here's what it looks like on the asus-z00t target. Note that this is not using an interface optimized for mobile. I am stating again the fact that the project does not aim to prescribe an interface; it provides tools for the end-user to build their own system.

I have had stage-2 working since late last week, on the less interesting (ChromeOS-based) asus-dumo target, but everything was so close to working on the Android-based phone that I just had to get it working before writing this up.

There has been one particular challenge that made this hard to debug for this particular device. The system image has to be built on native hardware (aarch64 on aarch64), meaning that the development loop was highly disrupted by latency. The build was quite quick on the community builder, though it required a download of the built image, which takes approximately 5 minutes, and then dd the image for an additional 5 minutes.

This was compounded by the fact that I had no way to peek in the device. The OEM kernel doesn't allow building with the usual linux framebuffer consoles, so no text output at boot. The device does not have (known) UART. Additionally, adbd doesn't work yet on stage-2 (unexplored) and ssh from the usb rndis interface didn't work at the time.

Luckily, I was able to get a feel of the success of the process by adding custom systemd services at the different targets to change the screen colour. This confirmed that the system achieved boot to the multi-user.target. Once confirmed, I shut the system down, extracted the journald logs, and took a look.

In the end, the solution was to rely on msm-fb-refresher, even though the framebuffer stuff in initrd worked fine with the handle "hack". That is, in addition to relying on the fbdev video driver. A future solution may be to customize the fbdev driver so it does the same "flipping" magic that was I added to ply-image. Ideally, a qualcomm-specific driver would be used, rather than rely on fbdev (for X11). Wayland hasn't been tested yet.

As you can see, the touchscreen works. Not shown is that the hardware buttons are all recognized. The hard/soft touch buttons (back, home, recents) are implemented as the screen touch zone expanding beyond the display. What's not working as-is, are all form of wireless communications, and audio. Additionally the gadget mode support (adbd, rndis) hasn't been figured out for stage-2. Though an existing rndis setup from stage-1 will continue working within stage-2 most of the time as long as it's not disconnected.

I want to try it!

The code is available. There also are high level instructions to get started.

Though, it is still left vague, and I am not providing pre-built images. First of all, there is no training wheels. When "burning" this to the device, it may be possible to accidentally wipe required partitions. If this were to happen, your device is likely as good as bricked.

This also was only tested on one particular Android-based device. It should work on other Android device of the same vintage, and likely on newer and older devices too. Though there is no port yet.

Additionally, since it requires native build, armv7 devices have not been tested yet. It is assumed that if the build succeeds, it will likely run fine.

What's next?

Since my talk for NixCon 2019 has been approved, I may be a bit vague about the far future until then. This also means that some of my time in the next few weeks will be spent preparing for the conference.

Though, this doesn't mean I don't have any goals for the near future!

To get to stage-2, in a cohesive manner with a NixOS system build, I had to refactor a bit of how the mobile-nixos modules worked. It hasn't been cleaned up to my satisfaction. Cleaning this up, and preparing for on-device nixos-rebuild are the next steps. This should also help make the development cycle quicker if rebuilds can be achieved on-device.