[WIP] pine64-pinephonepro: Init

[samueldr]

---

TODO

• [ ] Try building a "normal" and modular NixOS-flavoured kernel
• [ ] Write instructions

---

Outdated instructions...

Quick install guide

This will overwrite anything on the target eMMC and SD cards.

First, neuter the pre-installed system on the eMMC of the Pinephone Pro.

This will use the temporary installer script, here's the command to build the "hello" example system.

 $ nix-build --argstr device pine64-pinephonepro -A outputs.temp-tow-boot-install-script examples/hello/

1. Build Tow-Boot from https://github.com/Tow-Boot/Tow-Boot/pull/67

    $ nix-build -A pine64-pinephonePro
   

2. Write Tow-Boot to an SD card (via e.g. dd)

   sudo dd if=result/shared.disk-image.img of=/dev/sdXXX bs=8M oflag=direct,sync
   

3. Insert the SD card in the Pinephone Pro, and boot it while holding Volume Up, making sure your Pinephone Pro is connected via USB to your computer. The LED will turn blue when in USB Mass Storage mode.
4. Write Tow-Boot to the eMMC (via e.g. dd)

    $ sudo dd if=result/shared.disk-image.img of=/dev/sdXXX bs=8M oflag=direct,sync
   

5. Remove the SD card. We will make sure the installation to eMMC is successful.
6. Reboot the Pinephone Pro by holding power, press Volume Up when it's booting back up so it boots again in USB Mass Storage mode.
7. "Install" to the eMMC via the installer script:

    $ sudo /nix/store/[...]-temp-tow-boot-install/install.sh /dev/sdXXX
   

Once the script is done, you can reboot the device by holding the power button. You don't need to hold any of the volume keys to continue booting in the Mobile NixOS system.

Updating the boot partition

Simple!

1. Boot the device to USB Mass Storage by holding Volume Up.
2. Write (dd) the boot partition to what should be the fourth partition in a "normal" setup.

NAQ (never asked questions)

Why's this so damned hard?

Actually this is not much harder than "just" using dd to write an SD card with, let's say, Target Disk Mode, and then "just" using dd to write to the eMMC now attached via USB.

The main added weirdness is managing the platform firmware separately.

This is done to better exercise planning for a better NixOS on ARM. If it can work on "complex" devices like a phone, surely it'll be trivial on a "boring" SBC!

Additionally, some of the steps outlined here are universal for any distribution that will not distribute the platform firmware bundled into their system images.

Finally, this is a temporary measure.

The permanent solution will be an installer system. The user will write Tow-Boot to the eMMC, and boot from a universal SD card that holds an installer system that will guide the user through some questions about partitioning (e.g. ask about FDE and filesystems), the preferred graphical environment, and then do a "classic" opinionated nixos-install under the covers.

[telent]

I believe that

$ nix-build --argstr device pine64-pinephonepro -A outputs.temp-tow-boot-install-script examples/hello/

in these instructions should be

$ nix-build --argstr device pine64-pinephonepro -A outputs.u-boot.temp-tow-boot-install-script examples/hello/

(there's a u-boot in the attribute path)

[samueldr]

The system type's outputs are copied into the main outputs attrset.

https://github.com/NixOS/mobile-nixos/blob/796040d35e38507e8a9ed97c760cba6e923a8ca9/lib/eval-with-configuration.nix#L48-L49

So while you're right that the attribute exists under the outputs.u-boot namespace, it also exists at the root level. This is because of backward compatibility.

[tomfitzhenry]

This works great for me, thanks!

I like the idea and execution of Tow-Boot.

[samueldr]

Thank you @wentam for some of the changes.

Rebased, dropped needless changes from the history. Still WIP.

[wentam]

Perhaps we should run this patch as well? I've been running that patch for a couple of days and it makes the charging situation much better.

[samueldr]

Perhaps we should run this patch as well? I've been running that patch for a couple of days and it makes the charging situation much better.

Probably!

[samueldr]

Two changes:

• Added the suggested change set for charging, and I'm observing that indeed it won't get stuck in a state where it's stating it's charging, but actually drawing 0A (from a USB power monitor).
• Added a workaround for what I consider a bug/regression in mainline Linux and CONFIG_LOGO

---

What's that about CONFIG_LOGO? I've found that upstream seems intent on making sure the kernel logo is never used anymore at all. I don't know where in the stack it happens, but display init is being deferred in a way that is detrimental to user experience in my opinion.

I assume the goal is that, with blinders on, you'll see it makes sense to defer changing the display mode until needed as it prevents needless flickers during boot, e.g. your normal UEFI x86_64 laptop will continue showing its splash until some userspace component draws to the display.

Here this is not ideal since there is no display init done by the platform firmware. Having some sort of feedback early on that things are happening is good.

Though even if we had feedback from the platform firmware, I would argue that being able to control this behaviour would be beneficial here as we would want to show it ASAP to actually show "yes the kernel is booting"; otherwise if it crashes really early it will look like the platform firmware is hanging, when in reality it's happening somewhere between kernel init and userspace init.

This is probably a change that we want to investigate into applying overall to all platforms.

[tomfitzhenry]

Perhaps we should run this patch as well? I've been running that patch for a couple of days and it makes the charging situation much better.

@wentam It's good to hear that that MR improves things. Consider leaving a comment on that MR with your experiences, to allow a reviewer to have confidence in the change.