nixos / mobile-nixos Goto Github PK
View Code? Open in Web Editor NEWHome Page: https://mobile.nixos.org/
License: MIT License
Home Page: https://mobile.nixos.org/
License: MIT License
Please add the support level to the devices documentation.
https://mobile.nixos.org/devices/index.html
I like the structure of the list here organized by brand:
https://wiki.lineageos.org/devices/
There could be the overall support level like "basic" or "full". At the bottom could be a list of tested devices that are known not to work.
Then a page for every device can get generated with the README content and support level.
The support of specific features can be saved as structured data (Nix/JSON/?).
Good presentation example from https://wiki.postmarketos.org/wiki/Xiaomi_Redmi_Note_4_(xiaomi-mido)
I'm not sure if it is helpful to have the device specification there also, but if that is wanted, it an get scraped from https://github.com/LineageOS/lineage_wiki/blob/master/_data/devices/mido.yml
(that's the device i currently use)
$ nix-build -A all -I nixpkgs\=channel:nixpkgs-unstable --argstr device asus-z00t
these derivations will be built:
/nix/store/kyqkgiima57fczglk8a98vzmij46jg6x-fbv-aarch64-unknown-linux-gnu.drv
/nix/store/g5y10hfw6jmwky4afzk9k02njn1j4hfh-extra-utils-asus-z00t-aarch64-unknown-linux-gnu.drv
/nix/store/2vgz1vjfzfr7y6lcpil28nafkif4hgqc-stage1-aarch64-unknown-linux-gnu.drv
/nix/store/kbmr35hqa1rhg347gi5yv201g80l7pxv-initrd-aarch64-unknown-linux-gnu.drv
/nix/store/0ss3hdkxf9pc89yx87zljn5z2mqgambq-initrd-asus-z00t-aarch64-unknown-linux-gnu.drv
/nix/store/pa79lwbzdg189ap37zp5zx9ydyhs3hk9-nixos-mobile_asus-z00t_boot.img-aarch64-unknown-linux-gnu.drv
building '/nix/store/kyqkgiima57fczglk8a98vzmij46jg6x-fbv-aarch64-unknown-linux-gnu.drv'...
unpacking sources
unpacking source archive /nix/store/b3pi8ygkpj4xzkd5s45gfwsj1043hjir-fbv-1.0b.tar.gz
source root is fbv-1.0b
setting SOURCE_DATE_EPOCH to timestamp 1094566655 of file fbv-1.0b/Make.conf
patching sources
updateAutotoolsGnuConfigScriptsPhase
configuring
configure flags: --prefix=/nix/store/biskykra79jgz034w58v5mpvh3kbil2b-fbv-aarch64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --host=aarch64-unknown-linux-gnu
./configure: line 57: getopt: not found
Usage: ./configure [options]
Options: [defaults in brackets after descriptions]
If a long option shows an argument as mandatory, then it is mandatory
for the equivalent short option also. Similarly for optional arguments.
General:
--help print this message
--libs=LIBS additional libraries required (try -lX11 for ungif, -lz for PNG)
Directory and file names:
--prefix=PREFIX install files in PREFIX [/usr/local]
--bindir=DIR binary executable in DIR [PREFIX/lib]
--infodir=DIR info documentation in DIR [PREFIX/info]
--mandir=DIR man documentation in DIR [PREFIX/man]
Features and packages:
--without-libungif disable libungif support even if found
--without-libjpeg disable libjpeg support even if found
--without-libpng disable libpng support even if found
--without-bmp disable bmp support
builder for '/nix/store/kyqkgiima57fczglk8a98vzmij46jg6x-fbv-aarch64-unknown-linux-gnu.drv' failed with exit code 1
cannot build derivation '/nix/store/g5y10hfw6jmwky4afzk9k02njn1j4hfh-extra-utils-asus-z00t-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/2vgz1vjfzfr7y6lcpil28nafkif4hgqc-stage1-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/kbmr35hqa1rhg347gi5yv201g80l7pxv-initrd-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/0ss3hdkxf9pc89yx87zljn5z2mqgambq-initrd-asus-z00t-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/pa79lwbzdg189ap37zp5zx9ydyhs3hk9-nixos-mobile_asus-z00t_boot.img-aarch64-unknown-linux-gnu.drv': 1 dependencies couldn't be built
error: build of '/nix/store/pa79lwbzdg189ap37zp5zx9ydyhs3hk9-nixos-mobile_asus-z00t_boot.img-aarch64-unknown-linux-gnu.drv' failed
This is caused by its non-standard ./configure
script.
Work will need to be done to figure out why it has issues.
It would be useful to have the stage-1 work as a tertiary bootloader, which would in turn load initrd+kernel from an installed NixOS system on-device.
Follow-up to #71.
Not sure what I want, yet, but most likely make if fall in line with the kind of README in the Nixpkgs repo.
This will be moved to a new task, to be done outside this PR.
Right now, all dependencies are expected to resolve at some point. This means that any failure in a dependency to be fulfilled means it will be stuck in an infinite loop.
We might need to add timed delays and tries delays for dependencies.
Then, we need to transmit the error for a dependency to resolve to the tasks that depend on it. In turn, that function will be able to handle it.
After I managed to build and flash an image of mobile-nixos I'm now wondering what is the intended way to write the /etc/nixos/configuration.nix
on the device to include the mobile-nixos
repo.
I cannot really figure out how to transform the local.nix
that I used to build the image to a configuration.nix
.
From #80.
ply-image
is pretty redundant at this point.
LVGL allows us to do much more. Additionally, we gain SVG support, which allows us to have scalable graphics during boot.
Additionally, LVGL is much more than a tool to throw pictures in the framebuffer. We can use its ability to show text to show details about the errors!
Finally, we can also make the boot GUI aware of the current status of the boot process. We could do it in a simple manner and show x/y tasks done
with a progress bar. We could also show the task name in there so a task that is "sticking" is more obvious.
Oh, and LVGL has some animation support in it. This could be used to "juice up" the boot GUI if desired.
A picture says more than a thousand words.
It may happen that you have a "sad phone" screen when booting.
How should i expect that to look? Just show it with a screenshot.
https://mobile.nixos.org/in-depth/stage-1.html#_about_sad_phone_screens
That is, make it possible to use a device withtout wayland nor X, when there are no framebuffer VT in the kernel.
This is related to acting as a tertiary bootloader, and related to selecting NixOS configurations.
Find out existing work, either android-specific or other framebuffer-using samples. This is good for libraries and full applications.
Find documentation about the framebuffer, and how to use it.
Some notes:
The process looks a bit like that:
Especially, with regards to the kernel. I haven't yet figured out the minimum required configuration options, but their check
utility seems to make valid kernels for our purposes.
I just ported a new device, so the things I had to do are still fresh.
I was still using postmarketos
simply for the fact that it is a valuable asset here: they have checks and some automation we don't have for that.
I followed the guide up until the kernel compiled. Once it compiled, I took the config
file, the patches and got them into mobile-nixos
.
Once added (5624723) it all just worked™.
Let's make this as close to what upstream does.
Let's use /dev/kmsg
when it exists as well; we won't need to use a file if /dev/kmsg
is present.
From #80.
Implement
Keyboard input should, in addition to basic keyboard input, map:
(LEFT/RIGHT and not PREV/NEXT, otherwise changing number values would fail.)
See: https://docs.littlevgl.com/en/html/overview/indev.html#keypad-and-encoder
This is required for it to work in QEMU and for it to work on non-touch devices e.g. pinebook pro.
Do you plan on supporting Android's Project Treble with this? It would instantly give you support for many newer Android phones, though I'm unsure what support for it would entail implementation-wise. Or maybe I'm misunderstanding the meaning of Project Treble?
Also, this project is awesome! I'm in the process of building my own distro that sits on top of (a pretty stock) NixOS, and I'd love to get it running on a mobile device at some point!
Edit: It looks like PostmarketOS say that treble will not impact them, since it needs to be updated by the vendor. What are your thoughts on this?
This seems like it will be a harder issue to handle.
Looking at TWRP, it looks like they hardcode this as a device-specific build option. It seems true for at least asus-flo
.
From experience, asus-z00t
's framebuffer can be configured using fbset
from busybox
.
This fix doesn't seem to work for asus-flo
; I get fbset: FBIOPUT_VSCREENINFO: Invalid argument
. (This error doesn't happen when the colours are ordered RGBA in fb.modes, while the panel shows BGRA.) (This may not happen with the mainline kernel, which I'll need to package next.)
This may cause issues for Xorg support, unless composition with libhybris + vendor EGL fixes that.
I would assume that anything using vendor libraries will be handled properly (e.g. OpenGL) as they probably do the dirty work themselves.
This looks like it's related, on the android side:
I do wonder how to get this HAL data.
Have you considered building the website with Antora?
While i like the current design, Antora might offer some interesting features.
Their website is build by the tool too, so a landing page can be designed with it.
The default documentation layout looks like this: https://docs.antora.org/antora/2.2/
There are two sides to this:
make menuconfig
working right and documented.devices/.../kernel/config.___
file.The first part may be trivial enough. That alone is a good and probably simple improvement.
The second part is probably more tricky. Though it would make the development cycle easier.
I'm trying to build images for the Pinephone and I feel like I'm missing something in my stack, as I'm getting these errors:
$ nix-build --argstr device pine64-pinephone-braveheart -A build.disk-image
trace: Building with crossSystem?: aarch64-linux != x86_64-linux → we are.
trace: crossSystem: config: aarch64-unknown-linux-gnu
error: undefined variable 'lazyAttrsOf' at /home/craige/source/NixOS/mobile-nixos/modules/initrd.nix:33:8
(use '--show-trace' to show detailed location information)
I'm building on branch device/pine64-pinephone-braveheart
(patched with PR #91) and the nixpkgs directory is cloned from github.com:samueldr/nixpkgs.git
on branch mobile-nixos-wip
.
As best as I can tell, lazyAttrsOf
is only being called from initrd.nix
which is not part of either PR #91 or PR #97.
I've been unable to determine how it should be defined correctly and suspect I'm missing something in my local setup.
First of all, i'm very excited about this project. But it's also not clear what it will offer.
It would be great to have a section on the website that explains it in more detail.
What is it?
NixOS on my phone
OK, that's great. Like it's great to boot linux on a Playstation. But can it actually replace Android for daily usage? Can i install android apps? Can we package every F-Droid app automatically in nixpkgs? Do i have a touch UI? (the previous video shows Xfce with a cursor and desktop software which is not optimized for mobile devices)
The README has some information about the goals and previous work that should be added to the homepage.
https://github.com/NixOS/mobile-nixos/blob/master/README.adoc#goals
https://postmarketos.org/ has an excellent project description. You can use that as an example.
all proprietary components (even the WLAN, cellular modem and bluetooth firmware) are optional and you are asked whether you want to include them in your installation.
is that supported here as well?
I suggest to also add an FAQ where all this questions that come up can be answered.
Even if the answer is "that should be possible, but nobody has worked on it yet..."
My dream would be to be able to configure my phone like i configure my other systems (with NixOS :))! But be able to use it as before with all features and apps.
Update: More questions
Should in some way provide a framebuffer and serial console.
Should be configured as close as possible to the postmarketOS ones.
This depends on cross-compiling (#5).
The problem:
A user wants to compile using nix-build
on their x86_64
system, when an aarch64-linux
machine is configured as a builder.
Currently, it doesn't end up being used as the system detects it may need cross-compilation.
Not sure exactly how.
The easy way right now would be to configure nixpkgs.crossSystem = lib.mkForce null
in the system's configuration.
Another way would be to add a setting so that --arg crossCompile false
forcibly disables the check.
I dislike both options, as I would like it to be transparent, but detecting the ability to build natively through other machines is probably not detectable.
That is, to use mobile-nixos
on a personal computer of mine as the stage-1 to what would be a more normal nixos installation.
To check:
The first goal would be to make any closed-source .so
work with libhybris, as simple it is.
Then, with the knowledge gained, document the next steps.
Resources:
According to my device tree the kernel is built with clang:
It would be nice to have a working clang cross-compiler and the kernel-builder.
I tried to add it myself, but compiler-rt fails to cross-compile: https://daten.reisen/fbahg1
Also better document the attrs available on direct nix-build
, for the main default.nix, not only for the demo system.
As a follow-up to #46,
Hard-mode: could we get a real usable console attached so that an attached keyboard can work with it? Thinking about breaking to a shell in initrd, allowing keyboard input on-device, in case there's issues with adb and rndis.
I have a feeling it may be necessary. Maybe it's only because the android system boots, then reboots to my system, then reboots to android, then reboots to my system, but it feels like the phone's getting a bit hot.
This is not necessarily make thermal/power management work 100%, but mainly figure out if it is an issue, and document where to look for for more information.
From #80.
The big idea is to properly define the spec for the file format.
Then, use a unix socket to wait for a boot selection, rather than read a specific file.
Inspired from:
The documented build method ./bin/build qemu-x86_64
initially fails with:
$ env -i nix-build -A all -I nixpkgs\=/home/craige/git/NixOS/mobile-nixos/nixpkgs --argstr device qemu-x86_64
warning: Nix search path entry '/home/craige/git/NixOS/mobile-nixos/nixpkgs' does not exist, ignoring
error: file 'nixpkgs/lib' was not found in the Nix search path (add it using $NIX_PATH or -I), at /home/craige/git/NixOS/mobile-nixos/lib/eval-config.nix:20:16
(use '--show-trace' to show detailed location information)
When placing a copy of nixpkgs locally, it then fails with:
$ env -i nix-build -A all -I nixpkgs\=/home/craige/git/NixOS/mobile-nixos/nixpkgs --argstr device qemu-x86_64
error: The option `sdImage.populateBootCommands' defined in `/home/craige/git/NixOS/mobile-nixos/system-image.nix' does not exist.
(use '--show-trace' to show detailed location information)
When building with nix-build --argstr device qemu-x86_64 -A all
this first boot with ./bin/boot-qemu
runs out of disk space and fails.
When you reboot that image, init panics and fails due to the state of the disk.
This is reproducible via the steps taken above. Happy to provide logs and console output if it will help.
Thanks!
fastboot getlog
boot/init/tasks/switch_root.rb
It would be better if we logged using the default logger why it decided to boot in recovery mode. Was it because the image is built to always boot in recovery mode (as configured)? Was it because it saw the lack of _kip_initramfs
?
Seeing that @ashkitten was having an issue with always booting into recovery (#104), I was reminded of this diagram from the following document: https://source.android.com/devices/tech/ota/ab/ab_implement
This might suggest that @ashkitten's partitions had been marked invalid, and as a result, it would always boot into recovery. This could also explain why I had not encountered this problem yet with a freshly flashed phone.
I've only spent a few minutes looking into how this system operates, but I think to make this system operate properly for us, we would also need to mark the partition as having successfully booted at some point.
There is an existing bootctl
utility available in android here: https://android.googlesource.com/platform/system/extras/+/master/bootctl/
It, among other things, has the ability to run bootctl mark-boot-successful
.
Since this operates through a HAL, the underlying implementation (for qualcomm), appears to be here:
https://android.googlesource.com/platform/hardware/qcom/bootctrl/+/refs/heads/master
And briefly skimming this it appears to hold the BOOT_SUCCESSFUL
status in the attributes field of the GPT partition entry.
I can take a stab at working on this (maybe this weekend), but figured I should post this first in case there is any feedback. Is anyone aware if other projects implement this?
Follow-up to #80.
Additionally
Notes
There are some repeat libraries, e.g. the one handling adding "File.write".
We could also bundle them as "trivial" mrbgems. Explore making a "trivialMrbgem" builder that automatically creates the structure of a gem to shove given .rb
files into mrblib
.
Right now it's a kludge. We have /loader
that is globally available, and copy some "applets" in /applets/
so it's globally available.
It would be better, keeping mkExtraUtils
in mind, if we could simply add a package with a .mrb
in $out/share/script-loader/XXX.mrb
or something like that, and use an invocation like script-loader XXX
to load the right script.
Part of this also includes a "builder" to trivially build an applet. Not sure what shape this would have.
(Now documented as a known issue.)
It seems that ply-image
cannot always use the framebuffer. In those instances it fails with a Segmentation Fault. It happens for all calls to ply-image
, when it fails during that boot, but does not seem to be a global issue, considering X11 can start.
/nix/store/8r56dnr007zd8q2wjgx4j8wanh5nvrd2-local-cmds: line 25: 769 Segmentation fault /nix/store/w6b2gfiq270iglmx1fs8vsmy52597b9g-ply-image/bin/ply-image --clear=0x000000 /nix/store/y7l20cby57rbq56crjkrs0rz3awhwadd-splash.stage-2.png > /dev/null 2>&1
The documented build method:
nix-build -I --argstr device qemu-x86_64 -A build.vm
Fails with:
$ nix-build -I --argstr device qemu-x86_64 -A build.vm
error: getting status of '/path/to/source/mobile-nixos/device': No such file or directory
It's possible the documentation assumes some prerequisites I don't have. I was however able to build successfully with:
nix-build '<nixpkgs/nixos>' -A vm --arg device ./devices/qemu-x86_64
From the root of repo.
I've tried hacking on the currently WIP pinephone branch today. I could only make a little progress by identifying that I fail to build against most recent nixpkgs-20.03 branch.
(It seems to me in some way mobile-nixos wants a static python build for u-boot. However nixpkgs u-boot by now builds against python37 which currently doesn't build statically mainly because of the forced link to "-lgcc_s": knedlsepp/nixpkgs@b1298d9).
Anyways, I was wondering if there was some way of having some means of communicating which version of nixpkgs we can expect to build against. A known good version might have gotten me a little further here, so I'm wondering if there was a feasible way to do this.
I'm not sure if pinning nixpkgs would be a good idea. Some CI setup against nixos-unstable could also help identifying breakage.
Are there any plans in that regard?
maybe also to README
also a proper description. support and communication belongs in the readme and on the website
right now it links to the outdated forum post
(I have local notes I need to file)
They have manifests with repositories:
They are for repo
AFAIUI, the android tool to manage repositories. With some massaging and/or scripting, it may be possible to automate something with nix/nixpkgs and those XML files.
Their website seems to indicate they want to standardize some useful hardware. Though, there is a scary "android chroot" thing. I'm not sure whether it means full apps or only the minimal services to make the hardware work.
I've tried creating an SD Image for the PinePhone based on your pine64-dont-be-evil branch using my x86_64-linux box over the weekend. Sadly the result failed to boot. Since I've read that the issue might come from the fact that it has been cross compiled, I've been setting up a remote aarch64-linux builder on a Raspberry Pi.
However I'm currently having a little trouble to do distributed builds with it. With the nixpkgs
repo, I've successfully launched a remote builder by just calling:
nix-build -A hello --system aarch64-linux
However when I try to build the mentioned SD image using:
nix-build --argstr device pine64-dont-be-evil -j0 -A build.diskImage --system aarch64-linux
I get the following error:
building '/nix/store/ylsbkyxw1kirbdzrylvgh2zxr98n4p5a-builder.pl.drv'...
while setting up the build environment: executing '/nix/store/59nin1ij2x7772l467m2b2glmyscs26y-bash-4.4-p23/bin/bash': Exec format error
builder for '/nix/store/ylsbkyxw1kirbdzrylvgh2zxr98n4p5a-builder.pl.drv' failed with exit code 1
The called bash is in fact an aarch64 binary:
file /nix/store/59nin1ij2x7772l467m2b2glmyscs26y-bash-4.4-p23/bin/bash
/nix/store/59nin1ij2x7772l467m2b2glmyscs26y-bash-4.4-p23/bin/bash: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /nix/store/1ygglqib3lg0wywg95rk2kmxvl97zp08-glibc-2.30/lib/ld-linux-aarch64.so.1, for GNU/Linux 2.6.32, not stripped
So the --system
option seems to be respected, which can also be seen in the lines coming from modules/system-target.nix
:
trace: ******************************************
trace: * Evaluating device: pine64-dont-be-evil *
trace: ******************************************
trace: Building with crossSystem?: aarch64-linux != aarch64-linux → we're not.
I however don't understand why this build is being run locally on my x86 machine instead of being forwarded to the Raspberry Pi.
Some files are concatenated together in the hardware trees to build the /system/build.prop
file. We may as well try and build build.prop
too. Some of its information may be useful.
There are a couple issues:
The first point is a question of time, as ElvishJerricco/cross-nixos-aarch64 makes it possible to compile even mode stuff.
This will be a bit harder. The asus-z00t
kernel needs gcc6. It will seemingly build fine with gcc7, but will not boot.
Simply relying on what's currently in nixos will not work, as gcc6 apparently cannot build using gcc7 (which is partially expected). I do not know how to make it compile with gcc6, as depending it on a gcc6 stdenv causes recursiveness (expectedly).
Even though this might be probably up to desktop environment to decide, I'll still leave this as an issue here. Feel free to close it if it doesn't really apply here.
My phone, Xiaomi Mi A3 (codename laurel_sprout, based on Xiaomi Mi CC 9e, codename laurus), has a display cutout. I'm currently contemplating making a NixOS port to this phone and thinking how should I deal with display cutouts. They probably should be dealt with on desktop environment level, but how? or maybe one could patch the kernel to ignore the area that results from cutout being present so the screen would emulate absence of the cutout...
The image-builder infrastructure should be made aware of compression, rather than manually post-processing it.
Outputs cannot be bigger than 2.2GiB on the foundation's Hydra instance.
My main idea right now is to save some metadata next to the filesystem images, $filename
, something like $filename.meta
where we save the final size of the uncompressed file, the compression scheme used, if compressed, and maybe some other useful data points.
This, in turn, would be used by the disk image bits to decompress on the fly the compressed parts.
The idea being that we shouldn't require all parts of to be compressed, we should be able to say that only the rootfs and the final disk image are compressed, not the other bits. Doing this will also allow users to refer to pre-built store paths for the rootfs in their local.nix
to make complete images.
As discovered today, this may cause issue during the boot process
The symptoms are init being killed quickly (as discovered in a console ramoops)
[ 2.713781] c1 1 Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
The exit code may or may not be relevant here.
The solution would be to have an option to enable/disable this at build time, rather than editing the console cmdline.
This affects: (but not exhaustively)
This may affect:
If this can be reproduced by disabling UART in fastboot on walleye, this will be trivial to work on an appropriate solution.
The current workaround for users without serial enabled is to remove console=
from the boot params.
Additional notes: It may be crashing even before the custom init. It may be bootlogd that is unable to set itself up.
This includes
That is, going to stage-2
.
The first step is to manage it like lxc containers, where an omnipresent init
points to the last generation marked to boot. This will make it possible to do stage-2 without having to manage existing generations.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.