- A64 SoC
- 4-core Cortex-A53 1.1GHz
- 2GiB RAM
- USB OTG
- 6" display
- 2× camera
- EG25-G modem
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.
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
Y – supported,
Q – queued for next
P – partial support.
The table reflects the status of 5.10 kernel. Linux-next is what's queued
|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|
|Accelerometer/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/proximity sensor||Q||works||as IIO device|
|Front Camera – GC2145||N||works||missing some controls, I wrote a driver that's available in my cam tree|
|Back Camera – OV5640||P||partial||missing autofocus, limited resolution/framerate 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 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)|
|Modem Voice Calls||Q||works||Calling works with special apps, most distros already support making calls.|
|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.|
|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 supported by existing drivers), though see braveheart quirks signal's voltage = 3.3V, power voltage = 5V|
|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|
|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 configurable in sysfs.|
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 |
|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 Decoding/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/downscaling. 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 |
How my kernel tree is updated
My kernel tree contains many branches named after
mainline Linux releases. The branches follow this naming convention:
NAME represents a category of patches
anx for patches related to ANX7688 support,
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/
current mainline Linux version is 5.8 and 5.9 is in the rc phase] While Linus
v5.9-rc# versions I frequently rebase my
NAME-5.9 branches and collect, integrate and develop patches for
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
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
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
Otherwise it may be hard to keep track of what patches may have been
My publicly available work
- I'm collecting information about PinePhone's driver status, what's missing, known issues, and how to use the PinePhone hardware from Linux on this website.
- I've been designing and testing audio codec routing setup for voice calling and prepared a sound „card“ controls documentation for A64 codec driver. I also wrote voice call audio routing setup app.
- I'm implementing GC2145 (front camera) driver (basics are working now).
- I'm maintaining a Linux kernel tree with the collection of the latest patches from all around the internet that are relevant to PP + my own driver work.
- I'm providing easy to use binary builds for my Linux kernel tree
- I've implemented support for multiple cameras to the sun6i-csi driver, so that PP kernel can support multiple cameras.
- I've implemented optimizations for u-boot for faster boot times (DDR support and DMA support for eMMC/SD drivers in u-boot), dcache support for aarch64 version of SPL, and many other smaller improvements.
- I wrote a specialized bootloader for extremely fast boot times. Typical boot times are ~50–100ms baseline + load times for images. For eMMC it's 85–88 MiB/s, for uSD it's 24MiB/s. So for a typical 12MiB Linux Image, the total boot time from eMMC is ~230ms.
- I'm helping with getting PinePhone supported in mainline Linux. Basic support for 1.0 and 1.1. Support for LCD.
- I wrote patches to improve battery capacity reporting and enable charging to 4.35V.
- I wrote a modem power manager driver
- I created a multi-distribution image for Pinephone, containing 13 different Pinephone Linux distributions.
Private work I'm doing with PinePhone
- I wrote a boot menu app (youtube video)
- I tested and debugged the new image rotation driver from Jernej via my specialized camera app
- I'm writing a voice calling UI app
- I'm writing a ffmpeg based accelerated video playback app (with DRM based rotation of the video to landscape view and scaling)
Current status of my PinePhone
Some of the things I've optimized my PinePhone software for:
- Booting to Arch Linux and being accessible on WiFi in ~5 seconds
- Booting to my custom init process, initializing the system and running my UI app in ~1 second
- Highly optimized work with cameras: image capture, rotation and scaling at 30FPS (everything done with offloading of hard work from CPU, with CPU load at 0–1%)
- It can make phone calls with good audio, but UI is still lacking