Mobile NixOS [progress thread]

Announcements
13

Currently, it boots up until init. I only have a stage-1 implemented.

I had a preliminary look at how I’ll first handle switching roots, since I can’t really handle generations yet. During this 3-days week-end (holiday here) I’ll be implementing switching root.

Though, I have to say, I don’t know why systemd wouldn’t be right for mobile. Are there particular known reasons for saying that? Why would runit work better?

For now, I am focusing into using as-stock-as-possible NixOS, with added fixes and quirks for the environment. As there is no support for an alternative init yet, I’ll probably not support it yet. That is, unless it really doesn’t work well. If it doesn’t, then I’ll flesh out plans to manage an alternative init.

I, personally, wouldn’t be surprised if systemd manages fine on mobile. After all, it manages fine on SBCs with less powerful hardware, and less available memory.

1 Like
14

Cross should be fairly stable right now. You just need a line like this in your config:

nixpkgs.crossSystem = lib.systems.examples.aarch64-multiplatform;

15

Hi, there are a couple issues I am facing with cross-compiling, but only one which I really don’t know how to even begin tackling.

The kernel I build is old, and possibly bad code from a downstream OEM source dump. That kernel, on native AArch64, builds with gcc6 and gcc7, but only the gcc6 build boots.

With native (AArch64) compilation, no issues, gcc6 is already built and I can build the kernel.

With cross-compilation, it seems gcc6 needs to be built. It seems that gcc6 won’t build as it is. This is probably since gcc6 is being built with gcc7 due to warnings/errors [-Werror] (clever on IRC seems to think so, I thought so too). gcc6 probably needs to be built with gcc6 or gcc5. Building with gcc5 seems a non-starter as it itself needs to be built (I think). Building with gcc6 seems to always turn out to cause infinite recursion. My feeling is that simply overriding the compiler from gcc6 to be gcc6 is not the right solution; it would need to be built with a host-system(?) gcc6 and not whatever it is trying to be building it with.

Once I have gcc6 figured out, I’m probably fine to at least make it work, I hope.

Any pointer, @matthewbauer? I have this branch (wip/cross) where I have currently set it to always build with cross-compilation. I gisted the log, but github (un)helpfully truncates it *sighs*. The relevant error as a comment.

1 Like
16

2018-06-25

Thanks to the help from @matthewbauer I was able to get cross-compiling working right. At the top of wip/cross, I can built for my device and boot it (fbv for splash screens currently segfaults).

I still have to entirely grok the whole nativeBuildInputs, buildInputs, buildPackages, etc… I do know about 3.3. Specifying dependencies and Chapter 5. Cross-compilation. It’s more of a matter of really understanding rather than kinda understanding.

I believe my issues with fbv are mostly caused by its non-standard build system. I’ll have to figure out how to properly pass it libraries so it builds right. This’ll be fun to debug :).

Following steps should probably be adding a QEMU AArch64 target, this should help figure out some of the issues with cross-compiling. I also should look into making it automatic; when building something that’s non-native, automatically use the right platform. Then: finish up stage-2 boots.

2 Likes
17

2018-07-04

Some updates!

I have been working on this off and on, making some progress, though there’s still the elusive root switching to stage-2 to implement.

New device

I have added support for asus-flo, otherwise known as Nexus 7 2013 (WiFi), thus strengthening the boot.img build system.

It fully builds using the downstream android kernel, the mainline kernel is yet to be implemented. Why the downstream kernel? Multiple reasons:

  • Hardware support in mainline: I don’t know how it compares to downstream.
  • Allows testing a 3.4 downstream kernel with armv7.

I will eventually also add the mainline kernel, as it’s always better to have mainline support when possible.

Improvements / enhancements

BGRA / RGBA

One major nitpick I had was with how the framebuffer configuration was seemingly wrong. I may have done something wrong elsewhere, but I believe everything I did was right. What’s happening is that both my devices seem to default to a BGR(A) framebuffer format, while seemingly presenting themselves as RGB(A) framebuffers. This meant that the red channel and blue channels were inverted.

For asus-z00t it wasn’t as much an issue, as I could use fbset to change the parameters to the framebuffer. It seems that asus-flo’s parameters cannot handle being changed to BGR(A)[1]. I dove into the kernel sources and “fixed”(opinions may differ) the drivers so they (1) could switch to BGR(A) (2) defaulted to BGR(A). When a config option existed to set the defaulf framebuffer format, I added another one, otherwise I simply overruled the defaults.

I would love anyone knowing about framebuffer and/or kernel development to take a look at the patches, I don’t think they could cause issues, but I don’t actually know.

I’d like to know as soon as possible if I did something bad (wrt/ framebuffers) as I otherwise will recommend this approach to “fixing” RGBA/BGRA, and making all supported devices work as initialized in-kernel, instead of fixing them during boot.

Splash screen

Other than that, and partially related, I have decided to forget about fbv and instead use ply-image; I initially didn’t use ply-image because of an error printed on the CLI, but after reading the source, and testing, it looks like it’s a warning and doesn’t affect its used for splash screen purposes.

What’s good with ply-image is that it’s an actively (not much is needed) maintained program expressly used for boot splashes. It is maintained by the chromium team. It even has support for basic animations, which will definitely help spruce up the boot.

Soon I’ll switch the temporary splashes and make some more permanent ones.

Next

Stage-2! I’m itching since I basically have a hacky stage-2 working with qemu. I need to figure out a cleaner approach that will work better for android devices.

Then, once stage-2 is working, work on making this useful, so porting stuff for nixos, trying to make it usable.

1: It may be that my patch fixes setting the framebuffer config through fbset. I haven’t tested if I change the CONFIG option back to its previous default and apply fbset instead.

5 Likes
18

2018-11-19

Some updates, months later.

I have been busy with other things lately, but was just starting to look back at this.

Sadly, I have lost the use of my main development device. The Zenfone 2 Laser I was using, and keeping aside for that work, is still fine. It still works as it should, and probably would be a fine device for a couple years, but sadly, the battery isn’t. It has puffed-up a bit too much to my tastes. I’m waiting on word back from Asus as to whether I can get a genuine part. This slows down my progress as I now have zero dedicated AArch64 devices for this project.

New device

Well, I still have an AArch64 device, it’s simply not dedicated.

I have added preliminary support for the Moto Z Play, codenamed motorola-addison. Model number XT1635-02.

I say preliminary since the support isn’t quite there. First of all, the device ships stock with a 32 bit system image, and thus, Lineage OS supports it as a 32 bit system.

There is a branch in the Lineage OS kernel tree which adds support for AArch64, but it has two issues. First, it barfs in the dmesg logs an awful amount of trace logs; this may not be a big issue, mainly annoying. What’s a real issue, though, is that it will not detect the SD card. This means that working on stage-2 can’t really be done, unless I want to wipe the device.

I have some ideas to figure out things, but not much. If anyone with deep knowledge with these kind of devices can help, I’d gladly pick their brain.

Next

Not really useful to you all, but the next step here is to figure out what to do with the whole hardware situation. Maybe try some ideas. Hopefully get something figured out hardware-wise. I think it’s possible to run most android device without a battery by supplying the power directly to the pins the battery connects to, depending on the response from Asus, I might as well try that.

8 Likes
19

please give this man an award ! while I am no heavy smartphone by any means, I am still pretty excited by the librem thing and this. Being able to run a nixos there would be fantastic. Keep up the excellent work

20

I’m following the progress with interest. Unfortunately I know nothing about the inner workings of phones, so can’t really help. I just would like to see a Nixos phone.

1 Like
21

An update on the Mobile NixOS project:

I figure most of the people watching this thread will be interested in that update.

16 Likes
22

Fantastic news ! How long can you work fulltime on this ? There has been some efforts to port nixos for the librem phone. Exciting times.

1 Like
23

If everything goes well, more than a year, maybe two full years. Though by “the end” I’ll look into ways to continue working. At least for now I can focus on producing results.

Yes, hopefully some of the work (especially the software) will allow more choice to end-users, “for free” :slight_smile:

4 Likes
24

Fantastic! I would love a NixOS phone!

You could talk to the Purism people and see if they give you a devkit of the Librem5.

25

It worked well enough for the last post, I’ll continue sharing them here, unless you are not interested in updates :wink:.

In which I answer some general questions I’ve been asked, online and in real life.

10 Likes
26

Actually, systemd does work fine on mobile phones: Sailfish OS uses systemd as its init system. Hardware that depends on Android-specific drivers first initialises hardware with the Android init system, before handing over control to systemd.
The rpm packaging for systemd in Sailfish can be found here.

3 Likes
27

Yes, systemd does work fine on mobile phones! I was writing defensively, since I hadn’t done it yet, though I was 99.99% sure it was fine.

Why do I say it’s fine? Because it’s fine! Read more here:

Maybe watch it happen here if you do not want to read anything, but note that there’s no narration. It’s only a piece to accompany the write-up.

17 Likes
28

Oh, I should have been updating this thread, too.

Now that we have a website, I’ve been doing the updates over there.

4 Likes
29

Love the website, its lightweight, adaptive and beautiful! And it has rss!

4 Likes
30

Is it February already? Yes it is! Look at what happened in January.

4 Likes
31

And another monthly update

In which the boot gets graphic[al]!

10 Likes
32

Hi, any plans to write the Porting guide (step by step guide)?
The more idiot-proof, the lower the bar for others to help you out!
So writing a really comprehensive porting guide is probably of the best investments of time (given the possible high return)

Due to lockdown I have time left, and I want to port my old Samsung Galaxy S5 (for which a LineageOS port exists).

If the step by step porting guide assumes the phone is already supported by Lineage (thus has kernel) then great!

2 Likes