PinePhone Pro support

[tomfitzhenry]

I intend to work on PinePhone Pro support, which will involve at least:

• figuring out how much to reuse from the PinePhone support
• bootloader: existing u-boot support for Pinebook Pro might be sufficient. @samueldr reports Tow-Boot support is WIP.
• firmware: some might be reusable on https://megous.com/git/linux-firmware. Crust is not needed for Rockchip SoCs.
• kernel: https://wiki.pine64.org/wiki/PinePhone_Pro_Development#Linux_kernel suggests Megi's as expected. See https://mainline.space/ too for cross-distro mainlining effort.
• modem: can reuse the Pinephone
• sound: ?

Resources:

• https://wiki.pine64.org/wiki/PinePhone_Pro
• https://wiki.pine64.org/wiki/PinePhone_Pro_Development
• https://wiki.pine64.org/wiki/PinePhone_Pro_Developer_Edition
• https://xnux.eu/log/

[samueldr]

@tomfitzhenry: are you getting a developer batch unit? Anyway, I am waiting for mine to get to the correct continent.

As far as the platform firmware and early boot stages go, I have already got something cooking for Tow-Boot, which will also affect the Pinephone (A64). Something markedly universally better.

As far as the kernel goes, there is a new working group of different mobile distro maintainers coordinating into better "owning" the development and maintenance of the kernel changes so they get upstreamed.

crust is an Allwinner-ism, there's no such thing for Rockchip. Everything that we need from crust, AFAIK, is available directly in TF-A (Arm Trusted Firmware). I kinda assume whatever @theotherjimmy did for suspend on the PBP is going to help (hopefully).

Anything else, I consider non-issues. Modem is the same hardware, so other than how it's connected, it should work just as well. Relatedly, sound will be a chore, like it is/was for the Pinephone (A64) and the Pinebook Pro... But that's expected, sadly. Firmware should be a non-issue too.

[theotherjimmy]

Oh, uh, I don't have any plans to help ATM. Though I read it works, from one of the dev blogs. Let me find a link. I was thinking of this: https://xnux.eu/log/#048

With interrupts being calmed down from milions per a few minutes to barely any, I was able to use mainline TF-A from the master to achieve suspend to RAM on Pinephone Pro with no closed source binary blobs. It seems to just work, though the power savings are not as high as with the Android factory image I tested previously. Android factory 160mW in suspend. Mainline Linux/TF-A 400–600mW.

[samueldr]

Sorry, I was only saying that I assumed the existing suspend work for PBP would help. Without any new involvement :).

And giving credits where credits is due, involvement by someone involved in the NixOS community :)

[theotherjimmy]

My mistake. I agree, it should work, as the thing I quoted indicated. Thanks for the credit.

[samueldr]

See: #445

[mhuesch]

@tomfitzhenry cheering you on with this effort! and also interested in contributing once I get my PPP (just ordered an Explorer edition one yesterday).

ideally, I would like to set up a "dev phone" with the PPP and keyboard case, where I can e.g. take notes, retrieve / add documents in my git-annex store, run arbitrary aarch64 software, etc. I currently have a version of this on an Android phone using nix-on-droid, which works decently well but is of course limited and non-libre.

so I am interested in helping to move things towards "daily driver" status.

next actions for me are probably to adapt my Pinephone mobile-nixos setup, flash & boot the PPP once I get it. and then see what current status is as of then.

[samueldr]

My experience currently is that my custom config for the Pinephone (A64) basically ports over as-is on the Pinephone Pro, since the device config from Mobile NixOS abstracts things correctly.

To be fair, I'm not using any of the "made for mobile" environments, and am porting my desktop config to be "convergent", so it's possible some of the "made for mobile" environments have issues.

The only issue I've encountered with my custom environment is actually a bug in my implementation for the battery widget (or a slight oversight in the power supply driver). The battery widget always shows 0% because it uses the first "valid" entry it finds, but it's not a valid battery.

I have yet to test and possibly fix these:

• Modem
• Sound
• actual suspend

But otherwise these work:

• IIO drivers (light sensor, orientation sensor)
• Brightness control
• Wi-Fi (works better than the Pinephone A64 Wi-Fi)
• Bluetooth (IIRC, now that I write it I'm not sure I validated exhaustively)

Make sure to check #445, where the (not so much of) development is happening, @mhuesch.

[mhuesch]

thanks for the context @samueldr (and for everything you've done on mobile-nixos and Nix community generally).

sounds good overall!

curious about suspend, which would be nice for day to day usability.

also, it looks like LUKS decryption is operational but support for setting it up is not there (based on #234 / #237). wonder if I could help out there, since it would be nice to have LUKS on the PinephonePro if I were taking it out into the world routinely.

[samueldr]

@mhuesch the main problem with LUKS right now is setting it up on the device, the initial formatting of the partition.

With the current state of master, this is extremely difficult. "Nothing" is setup correctly to make it easy. Though one can use the TDM (Target Disk Mode) example system to mount the eMMC on their computer, and manipulate the device in an ad-hoc manner.

With the WIP branch with the installer scripts, it's much easier. One can use the USB Mass Storage mode from Tow-Boot, use the installer script to make the partitions, then format the last partition with LUKS after the fact, open the luks volume, dd a rootfs image.

Note that if you do so, you will need to have a boot partition that is configured for your LUKS filesystem UUID, filesystem label, partition label or partition UUID.

The actual expected implementation will be an installer system. The WIP installer script is a temporary measure to be used until the installer is done. The installer system will guide the user into selecting whether they want full disk encryption or not, and provide a few default options to start from. But this is content for another discussion.

[tomfitzhenry]

@tomfitzhenry cheering you on with this effort! and also interested in contributing once I get my PPP (just ordered an Explorer edition one yesterday).

Thanks for the cheers, but my words have been empty. I've not had time to work on this, though I'm pleased to see Samuel did this, and with Tow-Boot too! #445

so I am interested in helping to move things towards "daily driver" status.

next actions for me are probably to adapt my Pinephone mobile-nixos setup, flash & boot the PPP once I get it. and then see what current status is as of then.

You might be interested in https://nixos.wiki/wiki/PinePhone , which discusses a few of the commonly used pieces of software for the Pinephone.

[mhuesch]

thanks @samueldr @tomfitzhenry (& sorry for delay - was on a trip).

my PinePhone Pro arrives soon. I'll see how the mobile-nixos setup process goes and go from there.

[clay53]

I've recently received a PinePhone Pro (Explorer Edition). I have been able to get NixOS to install. I've got most apps, including Waydroid, working (except my own lol) on Phosh. Not really sure how to get caught up so I can contribute to development. I still need an adapter for my sim card to test if SMS, calls, 4G, or GPS work, but from what I've read, SMS doesn't work/isn't reliable, so I would want to try to get that working. I know the camera doesn't work, but that would be second priority for me.