a.k.a. Building Mobian Images for PinePhone

Why am I writing this? It’s not like those that care most don’t already know, right?

Mobian has stated intentions to align as closely as possible with Debian, which is good for the community. I do wonder sometimes about things like Movuan, though.

After playing with the PinePhone for a bit, my interest in Pine64’s other offerings grew substantially: mainly products built around the Rockchip RK3399 SoC and related family and friends.

Today I try resolving Months later, you can now read here about some annoying irritations with my Pine64 PinePhone and related hardware. Some of the below is probably outdated, so take care with the tone and specific inquisitions. Feedback is of course appreciated.

Stay tuned; I look forward to seeing where these efforts go. RISC-V is on the horizon, too.

Begin

Naturally I’ve been using Debian on the system; Mobian has been good so far and seems the fastest way to get there. I’m always shy to run these kind of projects as they’re removed from Debian, so I’m anxious beginning under the hood with mobian-recipes.git.

If I can improve the Firefox load time and general sluggish experience1 I’m much more likely to use the phone. I’m interested to see what zram backed swap and tmp directories yields, and to learn more about Mobian and these modern SoC platforms

Mobian uses debos, which was trivial to pick up and extend to configure my additions. First, I improved the Mobian build script to support arbitrary debos arguments. Second, I plumbed support to build with Debian’s contrib distribution enabled. These two tasks were a great way to familiarize with this portion of the project and debos itself2.

Continue

Then (months later; now; today), I did a bunch more. Mobian’s automated build had broken, due to upstream Debian removing some dead weight causing packaging issues3.

mobian-recipes.git now has support for:

Development in mobian-recipes.git is hampered by long apt-get install time; on the order of 1000 packages in rootfs alone. I’m not confident this bottle-neck can be removed, as it is all behind apt-get, and seemingly mostly not transfer related, though I believe utilities like apt-cacher-ng and possibly even apt-fast may help some.

Get:950 http://deb.debian.org/debian bookworm/main arm64 xterm arm64 370-1 [816 kB]
Fetched 578 MB in 29s (20.0 MB/s)

Action `overlay` failed at stage Run, error: lstat /recipes/rootfs-pinephonepro-phosh-20220130.sqfs: no such file or directory
Powering off.

real	35m2.990s

(Reset …) TL;DR

Ultimately, invoking the script as such produces working images with my desired changes:

time ARGS='-v' ./build.sh -d -b -t pinephone -S bookworm -C -s -u nmschulte -p 1234

… à la (note -Z for zram-based tmp/ dirs; though presently produces unworking images):

git clone https://gitlab.com/mobian1/mobian-recipes.git && cd mobian-recipes
git checkout -b zram
vim build.sh && git add . && git commit && git push # and so on
git clean -dxf
time ARGS='-v' ./build.sh -d -b -t pinephone -S bookworm -C -Z -s -u nmschulte -p 1234
# real    32m25.188s
dd if=mobian-pinephone-phosh-20210816.img of=/dev/mmcblk0 bs=4M status=progress conv=sync && sync

Gotchas

One thing to note about Mobian is that while it supports an “unstable” distribution, this does not correspond to the Debian distribution of the same name and instead builds upon Debian stable explicitly4.

Another noteworthy bit is that the unlock screen for Phosh is numeric only, meaning your password will need to follow suit if you want to unlock the phone.

Finally, disk encryption setup is supported only via the “installer” image; use the ./build.sh -o option to produce this image if you wish for automated setup of boot-integrated full-disk encryption.

zram

I’ve added a zram configuration for some small /tmp and /var/tmp file systems (default compression: LZO-RLE). Debian’s zram support is minimal; zram-tools provides a reasonable swap abstraction but ends there. I based my configuration from other project guides and others’ real-world-use feedback5: Gentoo, ArchLinux.

Results; Phosh

After 15 minutes spent resizing the partition on the 64 GB SanDisk Ultra SD card the phone loaded the Phosh shell and presents with a well polished setup application on first unlock. WiFi and 3G+4G cellular data work6, SMS and outgoing calls, front and rear cameras, etc.

Overall, most of the questions and gripe I’m left with come from the Purism/PureOS/Phosh realm:

  • How do I “gracefully” exit an application? Swiping it up/away closes it, but does this gracefully exit the application?
  • Automatic brightness doesn’t work well at all, with the factory plastic screen protector. The brightness level eventually trims to near-zero in my lighting environments.
  • Promote (or kill off) the “background.” For me, the only way to see the beautiful background in practice is when the system performs poorly: showing the background while the first application loads.
  • I crashed the Settings application while setting a background. The application and system was very sluggish and unresponsive when first looking through the images. Subsequent attempts were much smoother, as seems to be the case generally when issues like this arise. I’m guessing this is an I/O bottleneck/stall, and the system-wide-stall could be resolved with code tweaks.
  • Many areas of applications are difficult/impossible to use in the mobile form without orientation dances and/or scaling adjustment. This is obviously the well understood challenge, but I wonder how projects are setup to receive and address these concerns.
  • The battery seems to drain exceptionally quickly; even more so than my very early trials with the device. I believe it’s understood that this is an area needing improvement: I hope it’s being received7.
  • I really miss Android’s “back” navigation/button near my thumb at all times. That the launcher is always at the bottom of the screen, I find myself choosing it when I want to “go back.” With Gnome/Phosh’s choice to put the application navigations at the top of the screen (completely opposed my thumb), navigating them is a chore.

Last, the very prominent lock screen exhibits some less-than-desirable behavior. If locked in landscape mode, when the unlock UI first renders, a glitch occurs and the locked/sensitive content flickers through/around the unlock UI as it works to only support unlocking in portrait orientation. Interestingly, if locked in upside-down orientation, the unlock UI tracks this and only displays oriented upside-down. An open Phosh issue aims to revamp these behaviors: Make the lockscreen adaptive/work in landscape orientation.

Video Codec Acceleration

I haven’t grasped the video processing engine on the sunxi SoC yet, but I believe the acceleration situation is presently suboptimal on the system. I’d like to investigate this more, though I expect the community will improve or iron this aspect out before I need to. As well, it is unfortunate to be stuck with the Mali GPU, but I am grateful for what the Lima driver provides, and have no complaints if the minimal investment and pain helps to push things in a better direction.

I’m hopeful utilizing all of the available hardware will aid responsiveness and afford efficiency and resource tuning, improving the power management situation and battery life concerns. Solutions to this kind of process management and scheduling problem are foreign to me, so as well this will be interesting to uncover as part of this complex issue.

Parting Thoughts: ROCKPro64

Another project I have targets the Pine64 ROCKPro64, powered by the (big.LITTLE) 2+4-core Rockchip RK3399 SoC. I think newer kernels have mainline support for hardware accelerated video codec, which is a requirement for this project. Cross-building and building and packaging kernels for Debian are on the menu.

  1. Opening Mozilla Firefox for the first time was a horrid experience. After choosing Firefox, the launcher closes and the wallpaper is displayed, and then nothing happens for a solid 10+ seconds before the Firefox window displays, after which point you’ve already summized that something went awry and started another interaction. ↩

  2. Now merged upstream: mobian-recipes!34 ↩

  3. Fixes to mobian-base, due to removed crda; swap for wireless-regdb, though this needs active management (insmod, IICU …). ↩

  4. The Mobian project’s blog has useful, interesting articles from time to time, like this one: The unstable Mobian distro.

    The Mobian Wiki has good information as well. ↩

  5. I find that while Debian’s wiki and resources usually have great technical information, it’s typically outdated for my use-cases on non-stable releases. Sometimes the documentation is almost comical: ZRam.

    There are plenty of gems too: Guide for Debian Maintainers ↩

  6. I had to configure the access point for my provider: PinePhone Carrier Support. However, while this worked to flow cellular data, checking the setting later shows that my changes are not active, and somehow the system knows about my carrier already – cellular data continues to work. ↩

  7. From Mobian Wiki: System-wide desired features:

    Optimize power consumption, highest priority. - Upgrade to Megi’s kernel 5.12 or 5.13?

    And from Mobian Development Roadmap:

    better power management to improve battery life

    ↩