segments: Yifei Zhan's blog

CommBank hardware MFA token

Sat, 18 Apr 2026 00:00:00 +0000

A while ago, CommBank started asking for MFA confirmation on its mobile app for every NetBank login on a browser. Previously, there was an option to use SMS for MFA, which isn’t as secure as I would like, but it was at least usable. Since I’m switching away from Android to Mobian and won’t be able to use the CommBank app for much longer, I applied for a physical NetCode token.

The hardware is made by Digipass and looks disposable. It is a small, battery powered gadget with a screen and a button. When pressed, it shows a temporary NetCode for authentication. Such a NetCode is required both for NetBank logins and approving online transactions.

The letter that came with it has the wrong link for activation, the correct link is under NetBank -> Settings -> NetCode (under the Security section)

To apply for a physical token, call the NetBank team, mention you can’t use the app and need a physical NetCode token, and make sure they actually submit your request for a token. It took me 2 calls to get them to ship me a token. The hardware is free of charge but can only be applied for via phone call; unfortunately staff members at my local branch are unable to do anything in relation to NetBank. I was told privately by a CommBank employee that they are deprecating the hardware token in favor of the mobile app, I hope that won’t happen anytime soon, or that they add support for passkeys before they do. The last time I checked, the CommBank app was LineageOS-friendly, but I don’t want to configure WayDroid just to do online banking.

PayID, the thing that allows you to receive payment via a phone number or email address, is not compatible with the hardware token, and existing PayID will be silently deactivated if you use hardware token. This looks to be an artificial restriction; I don’t see why it has to be this way.

Regular CommBank mobile app sessions will also be de-activated once the hardware token is activated (I was told so but my sessions weren’t deactivated until I wiped my Android phone), and you won’t be able to sign into mobile app again until you manually disable the NetCode token.

Online banking has been getting progressively more invasive and anti-user over the last decade, from demanding remote attestation to requiring real time location data, each time locking certain features when those demands are not satisfied; all based on the flawed assumptions that everyone owns a phone running a certain flavor of iOS or Android, and has it ready all the time. I’m not sure what can be done to reverse this trend, but on the personal level I will use NetBank less and go back to cash.

Fix Pixel 3A XL Screen Unresponsiveness After First Lock

Fri, 29 Nov 2024 00:00:00 +0000

I recently replaced the screen of a Google Pixel 3A XL, the new panel is made by tianma and worked well under Andoird, until it doesn’t. On every boot up the screen will work until the phone went to sleep, and then the screen will stop responding to touch, until another reboot. After the screen became unresponsive, the rest of the phone would remain responsive during the locked state and it’s possible to unlock the screen with fingerprint, but there is no way to make the touchscreen responsive again without reboot.

To fix this, go to Settings -> System -> Gestures and disable Double-tap to check phone. After which the screen should no longer stuck into unresponsive state. This seems to be a common problem affecting many phones with replaced screen.

Google will surely shutdown their support forum one day and I encourage everyone to put their notes somewhere reliable, like a selfhosted blog :)

Don't buy a Kindle

Sat, 05 Oct 2024 00:00:00 +0000

I believe buying a Kindle in 2024 is a bad idea, even if you only intend to use it for reading DRM-free locally stored ebooks. Basic functions such as organizing books into folders/collections are locked until the device is registered and with each system update the interface has became slower and more bloated.

Initially I purchased this device because Amazon book store isn’t too bad and it’s one of the easier way to buy Japanese books outside of Japan, but with all the anti-features Amazon add in I don’t think it’s still worth using.

Using a recent exploit and with this downgrader thread on the mobileread forum, I’m able to downgrade my paperwhite to an older 5.11.2 firmware which has a simpler interface while being much more responsive. If you already have a Kindle perhaps this is worth doing.

Alternatives? #

It’s possible to install alternative UI and custom OS to many Kindle models but they generally run slower than the default launcher. On the open hardware side Pine64 is making an e-ink tablet called the PineNote with an Rockchip RK3566 and 4G of RAM it should be fast enough to handle most documents/ebooks, but currently there is no usable Linux distribution for it.

Change or Set PIN for FIDO2 Token on Linux

Fri, 05 Jul 2024 00:00:00 +0000

The easiest way to change/set PIN for FIDO2 token seems to be with Chromium/Chrome:

Plug in the token
Launch Chromium, navigate to chrome://settings/securityKeys, or click Settings -> Privacy and Security -> Security -> Manage security keys
Click Create a PIN, if you don’t have a PIN set already, a new PIN will be created, otherwise you will be asked to change the existing pin
Alternatively you can also wipe the token with the Reset option

More than smartphone, not yet laptop: Swmo on the PinePhone Pro

Tue, 07 May 2024 00:00:00 +0000

I’ve been daily driving the PinePhone Pro with swmo for some times now, it’s not perfect but I still find it be one of the most enjoyable devices I’ve used. Probably only behind BlackBerry Q30/Passport which also has a decent keyboard and runs an unfortunately locked-down version of QNX. For me it’s less like a phone and more like a portable terminal for times when using a full size laptop is uncomfortable or impractical, and with the keyboard it’s possible to write lengthy articles on the go.

This isn’t the only portable Linux terminal I owned, before this I used a Nokia N900 which till this day is still being maintained by the maemo leste team, but the shutdown of 3G network in where I live made it significantly less usable as a phone and since it doesn’t have a proper USB port I cannot use it as a serial console easily.

The overall experience on the PPP now as of 2024 isn’t as polished as that of the BlackBerry Passport, and adhoc hacks are often required to get the system going, however as the ecosystem progress the experience will also improve with new revisions of hardware and better software.

Initial Setup #

I use sxmo and swmo interchangeably in this post, they refer to the same framework running under Xorg and wayland, the experience is pretty much the same.

Sxmo is packaged for Debian:

sudo apt install sway sxmo-util

Allow access to LED/brightness:

sudo usermod -aG feedbackd user

Scaling Under Wayland #

The default scaling of sxmo doesn’t allow the many desktop applications to display their window properly, especially when such application is written under the assumption of being used on a larger screen. To set the scaling to something more reasonable, add the following line to ~/.config/sxmo/sway:

exec wlr-randr --output DSI-1 --scale 1.3

When using swmo environment initialization is mostly done in ~/.config/sxmo/sway and ~/.config/sxmo/xinit is not used.

Scaling for Firefox needs to be adjusted separately by first enabling compact UI and then set settings -> default zoom to your liking.

Landscape Setup #

I used lightdm as my session manager, to launch lightdm in landscape mode, change the display-setup-script line in the [Seat:*] section of /etc/lightdm/lightdm.conf to:

display-setup-script=sh -c 'xrandr -o right; exit 0'

To rotate to swmo to landscape mode on start:

$ echo exec sxmo_rotate.sh >> ~/.config/sxmo/sway

To rotate Linux framebuffer, add fbcon=rotate:1 to the U_BOOT_PARAMETERS line in /usr/share/u-boot-menu/conf.d/mobian.conf and run u-boot-update to apply.

I also removed quiet splash from U_BOOT_PARAMETERS to disable polymouth animation as it isn’t very useful on landscape mode.

Password-Lockable Screen #

Swmo doesn’t come with a secure screen locker. but swaylock works fine and it can be bind to a key combination with sway’s configure file. To save some battery life, systemctl suspend can be triggered after swaylock, to bind that to Meta+L:

# .config/sxmo/sway
bindsym $mod+l exec 'swaylock -f -c 000000 && systemctl suspend'

In suspend mode, the battery discharge at a rate of about 1% per hour, I consider this to be more than acceptable.

To unlock from a shell, just kill swaylock.

Before you can suspend the system as a non-root user, the following polkit rule needs to be written to /etc/polkit-1/rules.d/85-suspend.rules:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.login1.suspend" &&
        subject.isInGroup("users")) {
        return polkit.Result.YES;
    }
});

It would be better if there can be a universal interactive user group which automatically grant such permission to the desktop/mobile user.

Extra Keymaps #

The default keymap for the PinePhone keyboard is missing a few useful keys, namely F11/F12 and PgUp/PgDown. To create those keys I used evremap(1) to make a custom keymap. Unfortunately the Fn key cannot be mapped as a layer switcher easily, so I opted to remap AltG and Esc as my primary modifiers.

I’m working on a Debian package for evremap and it will be made available for Debian/Mobian soon.

Isolate workload with incus containers #

Incus is a container/VM manager for Linux, it’s available for Debian from bookworm/backports and is a fork of LXD by the original maintainers behind LXD. It works well for creating isolated and unprivileged containers. I have multiple incus containers on the PinePhone Pro for Debian packaging and it’s a better experience than manually creating and managing chroots. In case there is a need for running another container inside an unprivileged incus container, it’s possible to configure incus to intercept certain safe system calls and forward them to the host, removing the need for using privileged container.

Convergence #

Sway is decently usable in convergence mode, in which the phone is connected to a dock that outputs to an external display and keyboard and mouse are used as primary controls instead of the touchscreen.

This isn’t surprising since sway always had great support for multi monitor, however another often overlooked convergence mode is with waypipe. In this mode another Linux machine (e.g. a laptop) can be used to interact with applications running on the phone and the phone will be kept charged by the laptop. This is particularly useful for debugging phone applications or for accessing resources on the phone (e.g. sending and receiving sms). One thing missing in this setup is that graphic applications cannot roam between the phone and the external system (e.g. move running applications from one machine to another). Xpra does this for Xorg but doesn’t work with wayland.

Security #

Due to the simplicity of the swmo environment it’s not too difficult to get the system running with SELinux in Enforcing mode, and I encourage everyone reading this to try it. If running debian/mobian a good starting point is the SELinux/Setup page on Debian wiki.

Note: selinux-activate won’t add the required security=selinux kernel option to u-boot (it only deals with GRUB) so you have to manually add it to the U_BOOT_PARAMETERS line in /usr/share/u-boot-menu/conf.d/mobian.conf and run u-boot-update after selinux-activate. The file labeling process can easily take 10 minutes and the progress won’t be displayed on the framebuffer (only visible via the serial console).

SELinux along with the reference policy aren’t enough for building a reasonably secure interactive system, but let’s leave that for a future post.

Troubles with the PinePhone Keyboard and a disappointing mitigation

Tue, 23 Apr 2024 10:00:00 +0000

The melting plastic and the smoke #

The PinePhone keyboard contains a battery, which will be used to charge the PinePhone when the keyboard is attached. Althrough there are existing warnings on the pine64 wiki which sums up to ‘don’t charge or connect anything to your pinephone’s type C interface when the keyboard is attached’, my two pinephone keyboards still managed to fry themselves, with one releasing stinky magic smoke and the other melting the plastic around the pogo pins on the pinephone backplate.

This all happened while the pinephone’s type C interface being physically block when attached to the keyboard. In the first case, the keyboard’s controller PCB blew up when I tried to charge it, in the latter case the keyboard somehow overheated and melted the plastic near the pogo interface on the phone side.

Pine64 provided me a free replacement keyboard after multiple emails back and forth, but according to Pine64 there will be no more free replacement for me in future, and there is no guarantee that this will not happen to my replacement keyboard.

The cost for replacing all the fried parts with spare parts from the Pine64 store is about 40 USD (pogo pins + backplate + keyboard PCB), and considering this problem is likely to happen again, I don’t think purchasing those parts is a wise decision.

Mitigation #

Both the melting plastic and the magic smoke originated from the fact that charges are constantly shuffled around when the keyboard is attached to the pinephone, and since the keyboard can function independently from the battery, we can disconnect and remove the battery from the keyboard case to make sure it will not blow up again. After such precedure the keyboard will keep functioning althrough the keyboard-attached pinephone might flip over much more easily due to the lightened keyboard base. Be aware that the keyboard isn’t designed to be taken apart, and doing so will likely result in scratches on the case. As for me, I’d much rather have a keyboard case without builtin battery than have something that can overheat or blow up.

Disable the ip5xxx kernel module #

To prevent the kernel module from flooding the dmesg and reporting bogus battery level after the battery removal, blacklist the ip5xxx_power module:

# echo blacklist ip5xxx_power > /etc/modprobe.d/blacklist.conf

Everything Open 2024 Quick Notes :: Day 2 and 3

Sat, 20 Apr 2024 11:00:00 +0000

I didn’t take as much notes on day 2 and 3, so I merged them into a single article.

Wednesday, 17 Apr 2024 #

Keynote: How Adversaries Use AI #

Adversaries:
- Nation States
- Ecrime
- Hactivism
  - Not always clearly separated
LLM can help eliminate common language mistakes, perform better social enginerring
Many adversaries are trying to integrate LLMs into their workflow, with varying results
Time frame from initial foothold to lateral movements is getting shorter, due to better toolings?

GoLang #

IDE setup / difference with C and other common language
Compile down to single binary for many arch/platforms

Rootless networking: From possible to practical #

libslirp is too slow
passt & pasta
- much faster than libslirp
- same binary, different command
- translate between layer 2 network interface and native layer 4 sockets on a host
- unprivileged, no capability needed, good fit for container & VM
- https://passt.top/passt/about/

Running a Particle Accelerator on Open Source #

One of the best talk!
Software design & activity planning
Synchrotron
- https://en.wikipedia.org/wiki/Synchrotron
- https://en.wikipedia.org/wiki/Australian_Synchrotron
What’s happening there
- https://www.ansto.gov.au/about/locations/visit-australian-synchrotron
No more open days for now :(
- maybe after mid 2024?

Thursday, 18 Apr 2024 #

Keynote: Intelligent Interfaces: Challenges and Opportunities #

Another great talk, we don’t get HID talk often unfortunately
Sensing: what can we sense more?
- Eye tracking: figure out when the user is not paying attention and then when the user look back, show a diff/changelog
- Change Blindness, proximity-based experience: change how detailed the UI is based on proximity
- RadarCat, Radar and Categorization: better privacy than having camera everywhere
  - obtain infomation via wave reflection and absorption (can this be abused…?)
  - use ML trainning for better accuracy
- MicroCam and SpeCam: placement based action: detect which surface is under/over the device

FOSS: From Building Websites to Changing Society #

Echo chamber: FOSS run on different social/economic structure than commercial proprietary software, it takes effort to convince people

Adventures in fuzzing the kernel on Power #

porting syzcaller to run on Power
general fuzzinng engines
- universal eginee: AFL++
- domain specific fuzzer: syzkaller
Unsupervised: no human input required
Coveraged-guided: fuzz and measures which codepath is fuzzed
Things to fuzz: syscalls/dxrivers/fs/ebpf/kvm/network stacks…
- KVM: guest-host / host-guest
Simple kernel fuzzers existed est. 1991
- but not coverage based
Hosted version on Google Cloud: https://syzkaller.appspot.com/upstream
Sanitisers: print errors on memory corruption/UB/concurrency problems etc
KMSAN isn’t on Power yet
Hardware:
- https://en.wikipedia.org/wiki/PowerPC
- many more modern Power system
New architecture enablement
- Parse arch-specific details of kernel error
- Enable kcov (but not everywhere)
Stack traces are printed differently across archs
- use regex, 2.5KLoC ;)
instruction fuzzing
- generate and mutate PPC64 PowerISA machine code
- More coverage for KVM related pathways
- Only for x86 and power at the moment
QEMU/KVM on bare metal Open Power systems
Bug found:
- KVM guests can crash/hang the host, race conditions?
- Bugs in KUAP
PowerVM
- Type 1 hypervisor
- Runs Linux/AIX/IBM I VMs
- Need a separate machine as management console
PowerVC
- Forked from openstack
- Mostly OpenStack API
- https://www.ibm.com/products/powervc

Lightning Talks #

FileSender
- https://github.com/filesender/filesender
- https://filesender.org/
- end-to-end encrypted data transter, from web.
radio::console
- https://github.com/gm-stack/radioconsole
- control radios, remotely, good fit for stations in remote areas.
AgOpenGPS
- https://github.com/farmerbriantee/AgOpenGPS
- self steering system (hardware, software, firmware) for tractors
- only on Windows…?

Everything Open 2024 Quick Notes :: Day 1

Tue, 16 Apr 2024 00:00:00 +0000

sched_ext - Write your own Linux thread scheduler in BPF #

BPF made creating new scheduler simpler
- with strong safety guarantee to not break the system, the side effects of bad scheduler are confined.
- run a binary to enable your scheduler, stop the binary to revert to default
Scheduling problem is now more complicated due to increasing complexity of workload/CPU design
BPF provides reliable access to critical data structures inside the kernel

Exploring mobile linux security with PinePhone Pro: OP-TEE sec enclave, Virtualization and beyond #

This is my talk ;)
See the readings page for slides/demos and more.

Presenting n3n - A simple Peer to Peer VPN #

Forked from n2n to avoid CLA
- Protocol level compatibility with n2n is maintained
Peer-to-peer VPN at network layer, acting like a distributed virtual switch
- Layer 2 over Layer 3
- Only route packets through a server/supernode when required, p2p by default
- Better latency due to being p2p
NAT piecing
Written in C, should have good cross-platform supports (more testing wanted on *BSD)
- Relatively small codebase for a VPN
TunTap interface support is expected from the OS side, shouldn’t be a problem for common Unix-likes
- Modern macOS is dropping support for TunTap, need to use NetworkExtension?
Packaging and distro submission are still WIP
- Framework for a debian package exists but not in an upstreamable shape
- OpenBSD?
Future roadmap
- n3n over IPv6
- Code cleanup
- Multiple network driver support (e.g. something other than TunTap)
- Better NAR piecing
- Mobile support?
Useful for
- LAN gaming with old/modern systems
- Remote access
Simpler than wireguard/openvpn but offers OK security (not for security-critical apps?)
Easier to configure, use INI style config files

Running your own Mailserver #

90% of all incoming mails are low-effort spams.
Setup DMARC/SPF records

Lions OS #

seL4 is bad at usability, Lions OS intends to solve this
Still in early stage of development
Composable components for build custom OS for a single task
- Runs on seL4 Microkernel
- For things like IoT, embedded, cars etc…
Focus on simplicity
0.1.0 just released, still in its early stage
high performance
Only for Arm64/aarch64 now, riscv64 in future?
Device Driver Model
Multi Language Support
A reference system called Kitty exists
- A Linux running inside VMM is used for framebuffer, but any OS should do

Links and Further Readings for My Everything Open 2024 Talk

Fri, 12 Apr 2024 00:00:00 +0000

Here you can find a list of links related to my topic which I find useful or just interesting.

Meta #

Info page https://2024.everythingopen.au/schedule/presentation/24/

Slides EO2024.Slides.exploring.mobile.linux.security.odp

Recording XXX to be processed

VerityMobile GitHub :: ZhanYF/veritymobile

Demo #

Access Measurements from Linux Userland

fTPM-backed SSH Identity

Disposable Web Session

OP-TEE #

Other TEEs #

Android Trusty #

https://source.android.com/docs/security/features/trusty

Apple Secure Enclave #

https://support.apple.com/en-sg/guide/security/sec59b0b31ff/web

TPM and Desktop/Mobile Linux #

What Can You Do with a TPM by Michael Peters #

This also covers Measured Boot and Secure Boot

https://next.redhat.com/2021/05/13/what-can-you-do-with-a-tpm/

A WebAuthn/U2F token protected by a TPM (Go/Linux) by Peter Sanford #

https://github.com/psanford/tpm-fido

Setup TPM-backed SSH identity #

https://www.ledger.com/blog/ssh-with-tpm

Secure Boot on embedded devices #

Secure boot in embedded Linux systems by Thomas Perrot #

https://bootlin.com/pub/conferences/2021/lee/perrot-secure-boot/perrot-secure-boot.pdf

Shadow-box #

Shadow-box for ARM using OP-TEE #

Highlevel description #

https://www.blackhat.com/asia-18/briefings.html#shadow-box-v2-the-practical-and-omnipotent-sandbox-for-arm

Source code and build instructions #

https://github.com/kkamagui/shadow-box-for-arm https://github.com/kkamagui/manifest

Older version of Shadow-box for x86 #

https://github.com/kkamagui/shadow-box-for-x86

RK3399 #

Enabling Secure Boot on RockChip SoCs by Artur Kowalski #

https://blog.3mdeb.com/2021/2021-12-03-rockchip-secure-boot/

RPMB #

RPMB, a secret place inside the eMMC by Sergio Prado #

https://sergioprado.blog/rpmb-a-secret-place-inside-the-emmc/

Virtualization #

Firecracker #

https://github.com/firecracker-microvm/firecracker

firectl(1) #

https://github.com/firecracker-microvm/firectl

Run general purpose arm64 VMs with KVM on RK3399 #

https://segments.zhan.science/posts/kvm_on_pinehone_pro/

Monitor Upstream Updates for OpenBSD Packages

Wed, 01 Nov 2023 00:00:00 +0000

As an OpenBSD package maintainer, I often need to watch for updates on packages I maintain. I used to do this using repology.org, which has the benefit of tracking package updates in many distros, but it can be unreliable for OpenBSD packages due to network delay and parsing problems.

One better way to watch for upstream update is using OpenBSD’s portroach service, it monitors new upstream release and provides a JSON API that can be combined with jq(1) to produce clear information.

Querying portroach #

To find all packages that can be updated for a given maintainer, first find the maintainer page on portroach, you can search by maintainer name and the page’s URL should be similar to the following:

https://portroach.openbsd.org/yifei%20zhan%20%3Copenbsd@zhan.science%3E.html

Now to get JSON output, add /json/ to the URL and change the suffix from .html to .json:

https://portroach.openbsd.org/json/yifei%20zhan%20%3Copenbsd@zhan.science%3E.json

This endpoint will return all the packages maintained by a given maintainer, regardless of having an update or not. To only show packaged that can be updated, jq(1) can be used as a powerful filter and formatter:

$ ftp -Vo - https://portroach.openbsd.org/json/yifei%20zhan%20%3Copenbsd@zhan.science%3E.json\
| jq -r '.[] | select(.newver!=null) | (.fullpkgpath)+": "+(.ver)+" -> "+(.newver)'

Which prints a nice list of package I need to work on:

converters/opencc: 1.1.6 -> er.1.1.7
inputmethods/fcitx: 5.0.23 -> 5.1.1
inputmethods/fcitx-chinese-addons: 5.0.17 -> 5.1.1
inputmethods/fcitx-config-qt: 5.0.17 -> 5.1.1
inputmethods/fcitx-gtk: 5.0.23 -> 5.1.0
inputmethods/fcitx-lua: 5.0.10 -> 5.0.11
inputmethods/fcitx-qt: 5.0.17 -> 5.1.1
inputmethods/fcitx-table-extra: 5.0.13 -> 5.1.0
inputmethods/libime: 1.0.17 -> 1.1.2

Closing note #

Please be mindful that portroach is not infaillible, it may produce inaccurate result for some upstreams. The hosted version is a community resource, so please don’t abuse it, If you want, you can selfhost it with source code from its GitHub repository.

Encrypted and Version Controlled File Sync with git-annex(1)

Sat, 21 Oct 2023 00:00:00 +0000

git-annex(1) is a versatile and cross-platform tool build on top of git, it can sync, backup, archive files and provides many useful primitives for building customized workflow and storage system, for example, by combining git-annex with gcrypt, it’s possible to fully encrypt data stored on a remote.

Partially due to its versatility, it has a steeper learning curve than some other tools in this field and it took me some time to figure out how to make it work for me, here is a quick guide that documents my journey.

Prerequisite and Installation #

git-annex and git-remote-gcrypt is available from many package manager, to install them on Debian:

# apt-get install git-annex git-remote-gcrypt

git-annex supports multiple encryption mode, I will be going with the default hybrid mode since it allows more keys to be added in future. In this mode, data is encrypted with gpg using a symmetric key generated during remote initialization, the key then is encrypted by a gpg public key specified during initremote. After that, the symmetric key is checked into the git repository. This is useful when multiple users wish to access the same encrypted repository, but doing so is outside the scope of this post, for doing that and other advanced operations, read git-annex’s gcrypt guide for more details.

I opt to create a new key for this use case, but any gpg key will do.

Setup Local Repository #

The first step is to create a local repository as base, which will then be synced to remotes:

laptop$ git init myrepo
laptop$ cd myrepo
laptop$ git annex init

To checkin and commit some file into it:

laptop$ touch example
laptop$ git annex .
laptop$ git commit -a -m 'test'

Setup Encrypted Remote #

First, create a bare repository on the server, it will hold encrypted data later:

server$ git init --bare myrepo-remote

Then, on the local machine, add the newly created repository on the server as an encrypted remote, it’s a good practice to give it a descriptive name:

(To find the KEYID, run gpg --list-key)

laptop$ git annex initremote homeserver type=gcrypt gitrepo=rsync://server_hostname/path/to/myrepo-remote keyid=$KEYID

gcrypt: Repository not found: rsync://server_hostname/path/to/myrepo-remote
gcrypt: Setting up new repository
gcrypt: Remote ID is :id:XXX
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Compressing objects: 100% (3/3), done.
Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
gcrypt: Encrypting to:  -r XXX
gcrypt: Requesting manifest signature
To gcrypt::rsync://server_hostname/path/to/myrepo-remote
 * [new branch]      git-annex -> git-annex
ok
(recording state in git...)

With this done, it should now be possible to sync local repository to the remote:

laptop$ git annex sync --content

Work with Multiple Local Machines #

To accecss this encrypted repository from another machine (e.g. a desktop PC), first setup the gpg key on such machine, then clone and decrypt the repository:

desktop$ git clone gcrypt::rsync://server_hostname/path/to/myrepo-remote myrepo
Cloning into 'myrepo'...
gcrypt: Decrypting manifest
gpg: Good signature from "omnirepo (annex)" [unknown]
gcrypt: Remote ID is :id:XXX
Receiving objects: 100% (5/5), done.

Sync command will also work on the new machine for sending modified files to the remote:

desktop$ git annex sync --content
commit 
[master cec51a4] git-annex in XXX
 1 file changed, 1 insertion(+)
ok
pull origin 
gcrypt: Decrypting manifest
ok
push origin 
gcrypt: Decrypting manifest
Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Compressing objects: 100% (4/4), done.
Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
gcrypt: Encrypting to: --throw-keyids --default-recipient-self
gcrypt: Requesting manifest signature
To gcrypt::rsync://server_hostname/path/to/myrepo-remote
   bbed528..cec51a4  master -> synced/master
   c387409..575869a  git-annex -> synced/git-annex
ok

Troubleshooting #

Cannot write to annex file #

Annexed file is set to readonly (locked) to prevent accidental modification, run git annex unlock locked_file to unlock the file first.

Remove Unwanted Remote #

git-annex manages its remotes via git, to delete a remote, run git remote remove oldremote

Make you own 3.5mm serial cable

Thu, 17 Aug 2023 00:00:00 +0000

Doing anything close to the kernel/bootloader on PinePhone almost always requires a serial cable, Pine64 store has premade serial cable available for 7$ USD, but making your own serial cable can be both cheaper and more flexible as a DIY cable can support multiple logic level and pinout configuration.

Parts Overview #

You will need:

A 3.5mm audio cable, I got mine from a pair of broken headphone
A multimeter for continuity test
A USB-Serial adapter, you can get one online for around 3$ USD, make sure it supports 3.3v logic level if you want to use it with PinePhone
3 jump wires, for TX/RX/GND. Make sure those cables have female endings for connecting to serial adapter
(Optional) Soldering iron, some flux core solder and heat shrink tubing for making proper connection. You can skip this and instead use twisted wires and electrical tape to make connection

Make Connection #

The serial pinout of PinePhone is available from this Pine64 Wiki wiki, to put it simply:

If your 3.5mm plug has 3 rings:

|=|=|=|)   <-Plug Tip 
 | | |_RX
 | |_Tx
 GND

Tip Ring (rightmost): Rx
Middle Ring: Tx
Last (Leftmost): GND

If your 3.5mm plug has 4 rings:

|=|=|=|=|)  <-Plug Tip
 | | | |_RX
 | | |_Tx
 | -GND
 ^---- Not used

Tip Ring (rightmost): Rx
Middle Ring: Tx
Second Middle Ring: GND
Last (leftmost): Unused

With the pinout in mind, cut the headphone cable open and split the wires inside, for a cable with 3 rings there should be 3 seperate wires, and 4 if that’s a 4 ring plug.

Next, remove about 1cm of the isolation layer for each wire, and then use multimeter’s continuity test mode to find out which wire corresponds to which serial pin, it’s likely a good idea to label each wire with pin name at this stage.

Then, cut a jump wire open, strip about 1cm of the isolation layer like with the headphone cable, and twist it together with a wire from the headphone cable, repeat this process 3 times for Tx/Rx/GND (There are many videos on YouTube on this topic). You can also use soldering iron to make stronger.

After finish, test continuity again with multimeter to ensure every wire is properly connected, then protect the joint with electrical tape or heat shrink tubing (which needs to be put on before making connection).

Now the only step left is connecting the jump wire to the serial adapter. Since the PinePhone and the serial adapter are both considered host device, a cross-over connection is required, so what is transmitted can be received on the other side:

---------------      ----------------
serial    Tx  |------| Rx   headphone
adapter   Rx  |------| Tx   cable
side      GND |------| GND  side          
---------------      ----------------

Connect to serial console #

Flip the DIP switch 6 (the rightmost, labeled Headphone) on the PinePhone to enable serial access, connect the newly made cable to the PinePhone and a computer, then use any serial console tool to open a session. The following example uses cu(1) on OpenBSD but screen(1) and minicom(1) should also work.

$ doas cu -s 115200 -l /dev/cuaU0

OpenBSD on PinePhone Pro: First Impression

Tue, 15 Aug 2023 00:00:00 +0000

Disclaimer #

OpenBSD does not support PinePhone Pro yet and there are real risks involved in running it on your PinePhone Pro now, as such, I do not recommand anyone to do that. You might fry your device due to unsupported power management IC and in a worse case the battery might catch fire due to unconfigured/untested charging safety features.

The purpose of this post is to document how to install OpenBSD on arm64 platforms not fully supported by OpenBSD, and much of this post is not PinePhone-specific, if you intend to follow what documented here, please be mindful about the risks and apply common sense.

Overview #

OpenBSD installer cannot be used on bare metal if you want to install OpenBSD to an sdcard, because of insufficiant hardware support. However, it’s possible to install OpenBSD to a virtual machine and then transfer the installed system to a SD card to boot from
This post assumes you have a PinePhone Pro running Mobian with KVM properly configured, and an sdcard to transfer the installed system to
As for now the only way to interact with the running system is via a serial console cable, wired and wireless network are not supported, same for screen, keyboard, and USB host mode
Jump to Support Status to see what work (not much)

Prepare Disk Image #

To make full use of the sdcard, we will create a disk image with size equal to our sdcard. We can find precise size of the sdcard with fdisk on Mobian:

mobian$ echo p | sudo fdisk /dev/mmcblk1

A line similar to above should appear, showing the size of sdcard in bytes:

Disk /dev/mmcblk1: 29.72 GiB, 31914983424 bytes, 62333952 sectors

We can now create our disk image:

mobian$ qemu-img create -f qcow2 openbsd.vm.qcow2 31914983424

Bootstrap via virtual machine #

Installing OpenBSD on VM is relatively strightforward, get the minirootXX.img from OpenBSD mirror (at the moment I’m using miniroot73.img), and follow instruction from my other post

Add support files #

A freshly installed OpenBSD/arm64 VM is not bootable on bare metal, to make it bootable, we will need:

Device Tree Blob (DTB) for PinePhone Pro, which describes the hardware environment
- OpenBSD’s dtb package is compiled from Linux source tree, you can see how it is compiled here
Support files for uboot, extracted from installer image

(I’m not sure if all the uboot files are needed, but it’s easy to extract them all)

This can be done from the VM we prepared:

Create mount point for operating on disk image #

vm# mkdir /mnt/{img,disk}

Prepare dtb and installer image #

vm# pkg_add dtb
vm# ftp https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot73.img

Prepare and mount boot partition of installer image #

vm# vnconfig vnd0 miniroot73.img

vm# mount /dev/vnd0i /mnt/img/

Mount VM boot partition #

vm# mount /dev/sd0i /mnt/disk/

Copy files from installer boot partition to VM boot partition #

vm# cp -r /mnt/img/* /mnt/disk/

Copy DTB #

vm# cp /usr/local/share/dtb/arm64/rockchip/rk3399-pinephone-pro.dtb /mnt/disk/

Clean up #

vm# umount /mnt/disk/
vm# umount /mnt/img/
vm# vnconfig -u vnd0

Disable ohci #

ohci controller is not yet supported by OpenBSD on this device, and the existing driver can prevent the kernel from booting, before the root problem is addressed, we can disable ohci driver in kernel to workaround this.

vm# config -ef /bsd

ukc> find ohci                                                                                                              
167 ohci* at pci* dev -1 function -1 flags 0x0                                                                              
236 ohci* at apldc*|agintc*|ampintc*|qcdwusb*|imxsrc*|imxdwusb*|mvmdio*|rktcphy*|rkpinctrl*|rkgrf*|rkdwusb*|hidwusb*|amldwus
b*|syscon*|sxisyscon*|simplebus*|mainbus0 early 0 flags 0x0                                                                 
413 ohci* at acpi0 addr -1 flags 0x0                                                                                        
ukc> disable 236                                                                                                            
236 ohci* disabled                                                                                                          
ukc> quit                                                     
Saving modified kernel.               

vm# shutdown -hp now

Write image to SD card #

Make sure you VM is properly shutdown, and your sdcard is at /dev/mmcblk1, then write the VM image to the sdcard.

mobian$ sudo qemu-img dd -f qcow2 -O raw if=openbsd.vm.qcow2 of=/dev/mmcblk1 bs=20M

Boot OpenBSD from Tow-boot #

To boot OpenBSD from the sdcard with Tow-boot:

Insert sdcard into PinePhone Pro
Then flip the DIP switch 6 (the rightmost, labeled Headphone) to enable serial access
Connect a serial cable and open a console session, the example uses cu(1) since I’m using OpenBSD, but minicom can also work, towboot uses 115200 as baudrate but other u-boot build might differ

$ doas cu -s 115200 -l /dev/cuaU0

Something similar to the following output can help you confirm your serial connection is working:

U-Boot TPL 2021.10 (Oct 04 2021 - 15:09:26)                                                         
Channel 0: LPDDR4, 50MHz                                                                            
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB                                  
Channel 1: LPDDR4, 50MHz                                                                            
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB                                  
256B stride                                                                                         
lpddr4_set_rate: change freq to 400000000 mhz 0, 1                                                  
lpddr4_set_rate: change freq to 800000000 mhz 1, 0                                                  
Trying to boot from BOOTROM                                                                         
Returning to boot ROM...

Repeatedly press ESC to trigger tow-boot’s boot menu, select Boot from SD

                          Boot from eMMC                                        
                          Boot from SD                                          
                          Boot from USB                                         
                          Boot from PXE                                         
                          Boot from DHCP                                        
                          Boot from (sf0)                                       
                                                                                
                          Rescan USB                                            
                          Firmware Console                                      
                                                                                
                          Reboot                                                
                          Shutdown                                              
                         _

Something silmilar to the following should indicate OpenBSD is booting, and a login prompt will appear soon

boot>                                                                                               
booting sd0a:/bsd: 10625552+2504232+292520+843464 [792195+91+1216848+729496]=0x13b2240
[ using 2739408 bytes of bsd ELF symbol table ]                                                     
Copyright (c) 1982, 1986, 1989, 1991, 1993                                                          
        The Regents of the University of California.  All rights reserved.                          
Copyright (c) 1995-2023 OpenBSD. All rights reserved.  https://www.OpenBSD.org                      
                                                  
OpenBSD 7.3-current (GENERIC.MP) #2182: Thu Jul  6 15:02:37 MDT 2023                                
    deraadt@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP                            
real mem  = 4088885248 (3899MB)                                                                     
avail mem = 3883520000 (3703MB)

Support status #

Feature	State	Note
Screen	No	Screen lights up but no signal
USB Host	No	USB port is not powered
Built-in EMMC	Yes	sd1 at scsibus1
SD Card	Yes	sd0 at scsibus0
WIFI	No	bwfm0 at sdmmc0 needs brcmfmac43455-sdio.pine64,pinephone-pro.bin, loading this can lead to kernel crash
Sensors	Partial	GPU/CPU temperature is reported by rktemp(4), no other sensor detected
CPU	Yes	All 6 CPU cores are detected and run fine with MP kernel
Power off	No	Cannot power down system
Reboot	Yes	Reboot from OpenBSD works
Modem/other usb devices	No	Internal USB bus doesn’t seem to work

dmesg #

Full dmesg and other hardware info is available from PinePhone Pro installation report

Virtualization with KVM on the PinePhone Pro

Fri, 23 Jun 2023 00:00:00 +0000

Basic Setup #

All the tools we need for running VM are already packaged on Mobian, to install them, run:

sudo apt install virt-manager

then add your user to the libvirt group:

sudo adduser mobian libvirt

Reboot and then run virt-host-validate, it should indicate /dev/kvm exists and is accessible.

Trouble with Heterogeneous Architecture #

Trying to start qemu-system-aarch64 with -enable-kvm flag can yield the following, rather unhelpfully worded error:

qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument

Turns out the RK3399s SoC used on this device is built around Arm’s heterogeneous big.Little architecture, and contains 4 slower Cortex A53 cores and 2 faster Cortex A72 cores, this allows the kernel to dynamically schedule tasks on different types of cores to improve performance and save energy. However, this configuration is not yet supported by KVM, and when the expected CPU type differs from the scheduled type (e.g. expecting A72 but kernel scheduled a process on an A53 core), it will panic.

Before KVM is able to work with this setup, we can workaround it by manually set the CPU affinity of qemu by launching it with taskset. To only use A72 cores:

taskset -c 4,5 qemu-system-aarch64 <qemu options>

To only use the slower A53 cores:

taskset -c 0,1,2,3 qemu-system-aarch64 <qemu options>

To apply this workaround globally, we need a wrapper.

dpkg-divert #

Simply replacing the qemu-system-aarch64 binary with a wrapper is not a great idea because upstream Debian package can override our warpper when upgrading qemu. To ensure Debian will not override it, we can divert package’s version of the binary to another location with dpkg-divert:

sudo dpkg-divert --rename /usr/bin/qemu-system-aarch64

The --rename option ensures the existing binary will be moved to a new name, which by default is qemu-system-aarch64.distrib. Finally, create the wrapper under usr/bin/qemu-system-aarch64 (I decide to only use faster cores, A53 cores are too slow for most workload):

#!/usr/bin/env sh
taskset -c 4,5 /usr/bin/qemu-system-aarch64.distrib "$@"

Launching VM #

The following scripts will launch VM of different BSD OS, doing the same for Linux distros is similar. I’m using [user networking (SLIRP)][1] as network backend which does not require root privileges. This backend has the drawback of lower performance compare to TAP or VDE, but still fast enough for me.

OpenBSD #

Setup

mkdir openbsd.vm
cd openbsd.vm
# create disk image
qemu-img create -f qcow2 openbsd.vm.qcow2 32G
# use arm64 uefi firmware from package qemu-efi-aarch64
cp /usr/share/AAVMF/AAVMF_CODE.fd ./

Boot to installer

Assume using miniroot73.img as installer, -smp is needed for installer to enable MP kernel.

qemu-system-aarch64 \
        -enable-kvm \
        -m 1024 \
        -cpu host -M virt \
        -nographic \
        -drive if=pflash,file=aavmf_code.fd,format=raw \
        -drive if=virtio,file=miniroot73.img,format=raw \
        -drive if=virtio,file=openbsd.vm.qcow2,format=qcow2 \
        -netdev user,id=obsd \
        -device virtio-net,netdev=obsd \
        -smp 2

Launch VM

qemu-system-aarch64 \
        -enable-kvm \
        -m 1024 \
        -cpu host -M virt \
        -nographic \
        -drive if=pflash,file=aavmf_code.fd,format=raw \
        -drive if=virtio,file=openbsd.vm.qcow2,format=qcow2 \
        -netdev user,id=obsd \
        -device virtio-net,netdev=obsd \
        -smp 2

NetBSD #

Setup

mkdir netbsd.vm
cd netbsd.vm
# use arm64 uefi firmware from package qemu-efi-aarch64
cp /usr/share/AAVMF/AAVMF_CODE.fd ./

Launch VM

NetBSD provides ready to boot image for arm64, the daily snapshot is available at:

https://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/latest/evbarm-aarch64/binary/gzimg/arm64mbr.img.gz

qemu-system-aarch64 \
        -enable-kvm \
        -m 1024 \
        -cpu host -M virt \
        -nographic \
        -drive if=pflash,file=aavmf_code.fd,format=raw \
        -drive if=virtio,file=arm64mbr.img,format=raw \
        -netdev user,id=nbsd \
        -device virtio-net,netdev=nbsd \
        -smp 2

virt-manager and arm64 UEFI secure boot #

Virt-manager seems to use secure boot enabled firmware by default when creating new VM, this might not work for your prefered system (It certainly does not work with OpenBSD) and will yield a Script Error Status: Access Denied error for unsupported install media. To disable secure boot, select Customize configuration before install during the last step of creating new VM, go to Overview section, and change the firmware from AAVMF_CODE.ms.fd to UEFI aarch64: /usr/share/AAVMF/AAVMF_CODE.fd. This cannot be changed easily after VM is created.

A week with Mobian on PinePhone Pro

Thu, 15 Jun 2023 00:00:00 +0000

It’s been a bit more than a week since I start daily driving the PinePhone Pro with Mobian, some parts of my journey are documented here.

IME and Keyboard #

Both Phosh and Plasma provide their own work flow for setting up IME and adding extra language support, but so far I’m unable to get Phosh’s ibus-based input system to work with PinYin when using on-screen keyboard. I’m able to install PinYin and Anthy from Phosh’s software center, but those methods only work when used with external keyboard, switching to either of those from on-screen keyboard makes no difference when typing.

Plasma Mobile uses Maliit framework for on-screen keyboard, a small set of additional input methods including Chinese (PinYin) can be configured from Mobile Plasma Settings -> On-Screen Keyboard -> Configure Languages, then run im-config to make sure maliit is selected. After doing so it works mostly as expected.

Battery Life #

A fully charged battery provides around 1.5 hours of use time consisting of light web browsering via LTE network and messaging, anything intense like watching Youtube via Firefox can drain the battery within 30 minutes. In order to daily drive it, I always attach it to the PinePhone Keyboard which triples the battery life, combining with power saving tweaks (lowering screen brightness, disable wireless when not in use…), it’s possible to get 8 hours of run time, which is good enough for me.

At the moment of writing, Pine64 does not sell battery pack, but someone at Reddit finds out it’s possible to use Samsung’s EB-BJ700BBC battery pack (designed for Galaxy J7) on PinePhone, as PinePhone Pro uses the same battery as PinePhone, it should also work on my device, but I haven’t tested it. Pine64 is also said to be exploring a case with extended battery in 2020, but I haven’t heard any update on that.

I also experienced a few cases of battery not charging despite being connected to the power supply, in such cases the phone will display a very small current draw from the battery. Maybe that’s due to a bug between the OS and the RK818 PMIC chip but I haven’t dive deep enough to find the root cause.

Scale #

The default display scale is set to 200% under Phosh and similarly high under Plasma Mobile, which might be optimal for touch-focused usage, but is certainly not usable with most desktop applications in landscape mode, for example, Firefox won’t display application manu unless I lower the scale to 125%. Many application (e.g. Mumble) would not function correctly with anything higher than 125%, with most controls outside of display area and overflowing text. As such, I set both Phosh and Plasma Mobile to use 125% scale.

Messaging #

Install fluffychat via Flatpak #

I hardly use instant messaging, even less so on mobile devices because I find laptop to perform much better for reading and writing, but maybe the existence of Matrix can change this. As for now, I use fluffychat as my Matrix client. It’s not packaged for debian yet, so I decide to install it via flatpak, which seems to be the least intrusive method:

# setup flatpak
apt install flatpak

# optional: use flatpak plugin for Gnome Software manager
apt install gnome-software-plugin-flatpak

# setup flatpak repository
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

# install fluffychat
flatpak install im.fluffychat.Fluffychat

After using it for a few days I think it’s by far the most usable messaging software I tried on mobile.

SMS and MMS APN Setting #

SMS works out of the box, bidirectional messaging is possible and no configuration is required. On the other hand, Mobian doesn’t seem to autoconfigure the APN (Access Point Name) for MMS (Multimedia Messaging Service) globally, but both Spacebar (chat client from Plasma Mobile) and Gnome Chatty allow users to set custom MMS APN manually. Most mobile service provides will provide this information on their website, I find mine by searching Provider Name + MMS APN.

With the same correct APN setup for Spacebar and Gnome Chatty, only Chatty seems to work properly in terms of bidirectional image transfer, Spacebar would attempt to download the media file then fail instantly.

The mobile LTE connection can be shared to other devices either wirelessly or via USB cable.

Setup Wireless Hotspot from GUI #

Hotspot management is inside Settings -> Hotspot under Plasma mobile and Settings -> WiFi -> “Turn on WiFi Hotspot” under dots menu. Plasma’s wizard default to using WEP encryption with no way of changing it to more secure WPA2/3 but Gnome’s wizard does the right thing and default to WPA2. You might want to turn off auto sleep under Phosh Settings -> Power -> Automatic Suspend, otherwise your hotspot will be turn off after a 5 minutes timeout.

Setup Wireless Hotspot with nmcli(1) #

Doing things from GUI is not always desirable, and if you prefer cli, there is nmcli(1) available:

# setup hotspot
nmcli device wifi hotspot

# show password and SSID
nmcli dev wifi show-password

USB Ethernet #

PinePhone supports USB Host-to-Host bridges with ethernet subclass, it attaches to my OpenBSD laptop as a cede(4) device and my Debian laptop as an usb0 network interface using cdc_ether driver. To enable routing through it:

# turn on frame forward
sysctl net.ipv4.ip_forward=1

# install and enable nftables for forwarding
apt install nftables
systemctl enable nftables.service

# create a table
nft add table nat

# add the prerouting and postrouting chains
# this is required by the nftables framework for NAT
nft -- add chain nat prerouting { type nat hook prerouting priority -100 \; }
nft add chain nat postrouting { type nat hook postrouting priority 100 \; }

# enable masquerade NAT with upstream being wwan0
nft add rule nat postrouting oifname "wwan0" masquerade

You can replace wwan0 with other upstream you wish to use. (e.g. wg0)

Then set the default gateway of your client device to PinePhone’s usb0 IP address and traffic should start to flow, in my case:

ip route add default via 10.66.0.1

See this article from RedHat for setting up different type of NAT with nftables.

For adhoc network sharing, socks proxy over ssh might be simpler to setup than NAT.

Bluetooth Audio #

Bluetooth audio connections mostly work fine with Phosh’s setting panel with the exception of bluetooth low-energy protocol, which doesn’t seem to pair properly, I’m not sure if this is hardware issue or a software one. After the audio device is connected, it’s necessary to manually select it as the default output device, otherwise audio stream will continue to play with the internal speaker. Multiple codecs/profiles exist and can be switched on the fly, SBC/SBC-XQ/LDAC all work reasonably well with no difference in sound quality compare to Android devices as far as I can tell, however any profile making use of microphone will cause extremely bad audio play back quality.

If you cannot, or don’t want to run a bluetooth stack, it’s also possible to use a bluetooth audio adapter (like the Creative BT-W3 I used on my OpenBSD laptop, since OpenBSD doesn’t support bluetooth), such adapter can handle bluetooth codec logic in a dedicate hardware and present a generic audio output device to the OS, which also seems to help with audio jitter under high system load.

Epilogue #

There are many things to be explored and wrote about, from virtualization (KVM for aarch64 should just work) to LoRa backplate, I’m not sure what the future of this device would look like, but it’s certainly an interesting one.

Mobian and Plasma Mobile on the PinePhone Pro

Tue, 06 Jun 2023 00:00:00 +0000

Setup Tow-boot #

Mobian as of now requires Tow-boot bootloader to be installed first, u-boot is no longer supported. To install Tow-boot, see this document, I find it easier to plug in a usb cable to start the phone while holding down the RE button. Be mindful that there will be no graphical boot menu after installation, at the moment tow-boot menu is only available via serial connection.

It’s also possible you can skip this step, according to the PinePhone Pro wiki:

The batches bought after July 2022 come with Tow-Boot flashed to the SPI, which offers additional functionality over U-Boot as bootloader.

Setup Mobian #

Since I want to have full disk encrytion (FDE) for all my devices including this, I went with the Mobian installer image that gives me an option to enable FDE. The installation is fairly simple and smooth, taking only around 20 minutes start to finish with very few configure options, if you want to know what the process is like, Mobian wiki has an article with an overview of the installation process as well as links to different images.

Install KDE Plasma Mobile #

By default Mobian ships with Phosh, a wayland shell for GNOME designed for mobile devices, it works OK, but I prefer KDE Plasma Mobile. Fortunately, Plasma mobile is packaged for Debian and can be installed via:

sudo apt update
sudo apt install plasma-mobile plasma-mobile-tweaks plasma-settings plasma-phonebook plasma-dialer spacebar angelfish okular-mobile

The password for user mobian is the same as the screen unlock password. After apt done its job, logout current session and there should be an option to login again using Plasma.

Other Shell #

Apart from Phosh and Plasma, Swmo, Lomini (from Ubuntu Touch), Desktop Gnome as well as LXDE are all available.

Current state: #

I’ve been daily driving it for a few days, it most certinaly had a long way to go, but I can live with it as is.

Feature	State	Note
Call	Yes	Poor audio quality heard by other side
Mobile Data	Yes	Plasma’s modem setting page cannot enable the modem, after doing it from a Phosh session it seems to be working, APN is autoconfigured
SMS	Yes	No unified way of storing chat history, history does not sync between different applications
Camera	Partial	Extremely high latency between frame (3s+), inaccurate color
WiFi	Yes	Drop-off seems to be more common than other phones, but might just be an isolated case
WiFi Hotspot	Yes	Plasma’s wizard default to WEP which is insecure and I cannot authenticate from other devices, but unprotected hotspot works
Bluetooth	No	Unable to connect to any paired device, seems to be a known issue

The PinePhone Pro Wiki page also has a list for hardware/software state.

Things I read this month

Thu, 18 May 2023 00:00:00 +0000

RetroBSD: a port of 2.11BSD Unix intended for embedded systems with fixed memory mapping.

https://github.com/RetroBSD/retrobsd/wiki
This might be a good base to build on.

DarkRiscV: a BSD-licensed RISC-V cpu core implemented in Verilog

https://github.com/darklife/darkriscv
It implements most of the RISC-V RV32E and RV32I instruction set (missing csr*, e* and fence*) and works fine on many low cost FPGA system.

Initial setting for a thinkpad running OpenBSD

Mon, 01 May 2023 00:00:00 +0000

Taken from ~/.xsession

Disable system beep #

xset b off

Scrolling by dragging with the middle button and trackpoint #

xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation" 1 
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Button" 2 
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Axes" 6 7 4 5 
xinput set-prop "/dev/wsmouse" "WS Pointer Middle Button Emulation" 3

Use Caps Lock as Control key #

setxkbmap -option ctrl:nocaps

Remap middle button to perform right click #

I find middle button to be easier to reach then the right button.

xinput set-button-map 7 1 3 3