xnux.eu - site map - news

PINE64 PinePhone

Contribute

I usually abbreviate PinePhone as PP.

Work in progress

I keep current infromation about my PinePhone related kernel and other development adventures in my PinePhone Development Log.

Board photos

Some hi-res board photographs of PinePhone:

Feature/driver support matrix

This information reflects the status of my kernel tree at: https://megous.com/git/linux/log/?…

You can click on each feature's name to see more details and ways to use the feature on PP from userspace.

Second column in the table contains information about status of support in the mainline (Linus's) kernel tree: N – not supported, Y – supported, Q – queued for next version in linux-next tree, P – partial support. The table reflects the status of 5.10 kernel. Linux-next is what's queued for 5.11.

Feature Mainline Status Notes
User interface input
Power key Y works can be configured via PMIC to react more quickly to key press to power on the device
Volume buttons Y works can be also used from bootloader to affect boot script decisions (with a patch)
Touch panel Y works touch panel has a lag. it's normal, but possible to avoid in SW by using prediction techniques
Accelerome­ter/Gyro Y works as IIO device
Magnetometer Y works interrupts are routed incorrectly on the board, and need to be disabled, so the sensor can really only be used with external triggers (1.0–1.1), works correcly on 1.2
Light/proxi­mity sensor Q works as IIO device
Front Camera – GC2145 N works missing some controls, I wrote a driver that's ava­ilable in my cam tree
Back Camera – OV5640 P partial missing autofocus, limited resolution/fra­merate settings, some controls misbehave, the mainline driver is not very reliable, i2c addresses of both cameras are the same so they conflict and can't be powered on at the same time
User interface output
Display panel Y works
Display panel backlight Y works the lowest PWM duty cycle for backlight to work may vary between devices (may need per-device calibration)
Audio Q works Codec was recently (2020–02–07) much improved by smaeul to support complex HW mixing of audio from bluetooth and the modem.
RGB LEDs Y works via a LED class driver
Flash LED Q works The driver is mainline, DTS changes will be in 5.9. When booting from eMMC the LED flashes for a second.
Vibration motor Y works (as EV_FF input device)
Wireless connectivity
Modem Voice Calls Q works Calling works with special apps, most distros already support making calls.
Modem data Y works
Bluetooth N works
GPS Y works works via a modem
WiFi Q/dkms works Old messy driver from 2014. I have ported a newer version from 2017 to mainline kernel. Power management still sucks. Realtek doesn't seem to support this chip anymore. All the drivers I can find, even precompiled ones for windows are at most from 2017.
Wired connectivity
USB-OTG Peripheral Y works, but slow sunxi musb driver doesn't implement DMA, throughtput is limited to ~12MiB/s and high CPU load, but it's possible to export block devices as USB storage devices over USB, and make PP emulate other USB gadgets (network card, etc.)
USB-C Dual Role N works/hw broken I've implemented a driver in my pp-5.7 branch, based on the Martijn Braam's work. All the current PP variants (1.0–1.2) have a major issue, that prevents CC pins from working correctly. It's therefore not possible to perform any kind of negotiation and communication over the CC pins. It's not fixable in SW, other than via a manual selection of power and data roles by the user. There's a HW mod that you can do to fix CC pins from being hogged by the VCONN switches by removing the switches. See the howto, or video from adnidor. After this HW mod, you'll be able to use USB-C peripherals that don't need VCONN (hubs, etc.) with the driver in my tree.
USB-OTG DP Alt mode N works/hw broken HW on Pinephone 1.0 and 1.2 is broken, see above. With HW fix and USB-C HDMI dock/cable, HDMI out works.
USB-OTG DP Alt mode (HDMI audio) N works/hw broken HDMI audio playback works with my 5.9 kernel. You need to play/convert to 48kHz/16bit audio, which is what HDMI I2S audio requires.
POGO pins N untested should just work (it's a regular i2c interface, that's sup­ported by existing drivers), though see braveheart quirks signal's vol­tage = 3.3V, power voltage = 5V
Storage
eMMC Y works read speed is about 85–88MiB/s max in Linux (somewhat slower on 32GiB variant – ~65MiB/s) patches for u-boot to make it as fast during bootloader stage exist too
microSD Y works read speed is about 23MiB/s max in Linux. patches for u-boot to make it as fast during bootloader stage exist too
Power/thermal management
CPU hotplug Y works via ATF PSCI
System suspend N works Suspend works with crust SCP (incl. DRAM self-refresh), achieves ~110mW (130mW with modem enabled and sleeping)
Thermal regulation Y works CPU frequency throttling happens at 70°C by default. May be too much for some people. It's confi­gurable in sysfs.
PMIC P some bugs After poweroff PP 1.0 and 1.1 still consume around ~20–30mA (this is fixed on 1.2). This drains the battery in ~2 days. Samuel Holland discovered that this is fixable by desoldering U1301 and shorting R1309. I've made a quick howto on how to do it.
Battery/USB power Y works, mostly PP needs a good power supply AND USB cable (2A+, phone takes 700mA during use + up to another 1.2A for charging). Type-C chargers only work after Linux boot and don't cooperate automatically (or well) with the PMIC.
Other (internal SoC features, etc.)
CSI Camera Interface Y works / OOT multi-camera support works and is well tested
Display engine Y some bugs display engine driver has some bugs when atomic modesetting uses multiple planes and scaling, patches exist, good enough for general use
DE2 Rotation Engine Y works Works with a demo app (camera and display are oriented differently, so rotation of frames is needed to get the correct orientation for preview)
Video H.264 Deco­ding/Encoding Y works Works with Kwiboo's ffmpeg and gstreamer 1.18 (out of the box). It's possible to play video to external monitor, with HW based upscaling/dow­nscaling. Best performance is achieved with gstreamer kmssink, atm.
Mali GPU Y works It works with mesa/master and the driver in Linux 5.7. I've tested it with chromium and electron with a --use-gl=egl command line option, and it makes both faster.

How my kernel tree is updated

My kernel tree contains many branches named after mainline Linux releases. The branches follow this naming convention: NAME-VER. NAME represents a category of patches (anx for patches related to ANX7688 support, cam for patches related to camera support, wifi a wifi driver, …) to the mainline kernel, and VER represents the mainline Linux version these patches apply to. These category branches are all merged into orange-pi-VER branch. The branches just help organizing the 100s of patches, and may depend on each other.

My kernel tree follows the latest master branch of https://git.kernel.org/…s/linux.git/ and latest stable branch of https://git.kernel.org/…e/linux.git/

[Let's say current mainline Linux version is 5.8 and 5.9 is in the rc phase] While Linus is releaseing v5.9-rc# versions I frequently rebase my NAME-5.9 branches and collect, integrate and develop patches for the upcomming 5.9 release.

As soon as the final v5.9 release is made by Linus, I stop rebasing my NAME-5.9 branches and from that time on I'll only add on top of them. The things that get added are merges from the stable tree from linux-5.9.y branch, and important bugfixes to the Pienphone specific drivers.

When Linus releases v5.10-rc1 I copy all NAME-5.9 branches to NAME-5.10 and rebase NAME-5.10 branches on top of linus/master branch. After the rebase I retest my kernels to make them work again if there was breakage introduced by v5.10-rc1, try to send whatever patches I have time for mainline, look for new patches that can be integrated to my tree, and the cycle repeats itself.

To help track change during the churn introduced by rebasing I keep a changelog in the commit message that gets added to an empty commit on top of orange-pi-VER. Otherwise it may be hard to keep track of what patches may have been modified, etc.

My publicly available work

Private work I'm doing with PinePhone

Current status of my PinePhone

Some of the things I've optimized my PinePhone software for: