So much Pine64-bashing and quite a lot of factual errors.
There were several pinephone HW revisions that fixed HW issues based on direct developer feedback. Yeah, there was no direct communication with HW engineers, but at least the critically important feedback was applied (otherwise modem would not be able to wake up Pinephone SoC from sleep and Alt-D over USB-C would not work at all, and probably bunch of other things I barely remember). I or someone else in #pinedev could tell TL Lim, and if change was reasonable it would be made. There was quite lively discussion around HW issues in #pinedev early on. And company did not seem to lack effort, eg. for Pinephone keyboard there were like 5 revisions, including doing an X-Ray analysis of burned down keyboard MCU and subsequent citcuit improvement. So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs.
"The volunteers working on the PinePhone's kernel generally didn't [upstream]" is factually completely wrong.
PinePhone DT was mainlined for Linux 5.7 by me. smaeul rewrote the sun8i-codec driver and did lot of stability and other work, anarsoul upstreamed Bluetooth and maintained Lima, and many many many more small upstream contributions by different people (git log is your friend), just on the kernel side. People created entire new upstream projects like Crust and p-boot and levinboot, etc.
Yes, there's some long residual stack of patches, but so what? Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading.
And another thing is that even if there was lack of upstreaming, almost no Anroid phone is fully upstream in Linux and it doesn't prevent it from gaining marketshare. Downstream kernels suffice for it.
Latest version of supported downstream kernel for pinephones with good HW support has been available for years. Almost no Android phone can even claim that for their downstream kernel.
Then there's over-estimation in the article of how upstreaming to kernel is important. You can easily say that having full HW support quickly in some downstream kernel is kinda preferable, because it allowed people to actually use the phone sooner, and allowed userspace development to progress. If every change would have to go to upstream, with its long iteration times, etc., people would not be able to use the phone at all for 4 years or so. How many would even stay around? :) I ceratinly prefered making the HW work and work well, over upstreaming. I understand upstream kernel is a distro maintainer wish. People are free to have wishes. :D
Pushing upstream changes coordination of work and to some extent simplifies maintenance for some, while making it way harder for others in the community.
The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago. Yes, again, you need a downstream kernel, but it's been maintained for every release for years since the beginning, just like PP. It's very similar situation to Raspberry Pi, which also sucks without downstream kernel, but did not prevent it from reaching marketshare, or whatever. Commercial cancellation is more lack of interest/commercial viability, rather than anything pointing to lack of SW support.
The article opens by promising to "examine what held back mobile Linux." Well, it consistently assigns blame to companies/vendors while treating the enormous volunteer engineering as background and blameless. Well it's not.
As for the company: Pine64 promissed 10 years of original Pinephone. It's so far delivering what? 8th year? At the same/similar pricing to 8 years ago, across all that happened in the HW industry in the meantime? Covid? Ramocalypse? I'd call that a massive success on promissed claim. The company also never promissed fully working OS/HW android experience. It promissed cheap accessible long-term stable HW product to jumpstart the ecosystem (paraphrasing from memory). And I thoroughly enjoyed developing and supporting Pinephone on the kernel side for 8 years release after release, building well designed (as far as UX goes) bootloaders, and interacting with TL Lim and wider community, etc.
"Once the best volunteers abandoned PINE64, the company hasn’t been able to complete the development of the PinePhone Pro, PineNote, PineTab2 and many of its other projects, so the people who ordered these devices are unlikely to ever be able to use them as fully functional devices."
Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing. I know of one: HW accelerated video encoding on original Pinephone. The only claim I see other than performance, is lack of "HW accelerated video encoding". But who would want to record videos with webcam level sensor that uses CAF for auto-focus? Has anyone even tried to imagine what it means practically when you get CAF full range sweep in the middle of the vide? :)
Performance is not really relevant to "level of SW support".
You can also say that perhaps people drifted off after the work was mostly done, because there was nothing more exiting to do, other than absolutely unsatisfying gruntwork that even paid engineers at most android shops don't bother to do.
"but instead PINE64 dismissed the screen flicker" is also incorrect, IIRC. I remember suggesting removal of some resistor to avoid leakage of power into PL port power rail, that caused variation in backlight PWM control voltage, since PL rail served as a voltage reference for backlight PWM. And it was resolved.
Hi Megous, I'm the author of the article. Before we get started here, just let me say from the outset, thank you for all your hard work on the PINE64 hardware.
I will correct the things that I got wrong in the article, if I can verify my errors.
I have the PinePhone 1.2b (Beta Convergence Package), that was shipped to me on April 5, 2021. It is currently running Mobian Weekly with kernel 6.18.32.1, which I downloaded about three weeks ago.
I see the flicker on my PinePhone's screen. I usually see it for a minute or two after I turn on the phone or resume from a suspend, but I sometimes see it at other times. I see the flicker both when the screen brightness is set to a minimum or to a maximum. I have seen this problem the whole time I have owned the PinePhone.
I assumed it was caused by this issue: https://wiki.pine64.org/wiki/PinePhone_v1.2#Backlight
However, rereading it, my case doesn't fit, because the screen flicker exists at both minimum and maximum brightness. Can you explain this?
Maybe my screen flicker problem is special, but was the problem listed on the wiki ("When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily.") ever resolved by PINE64?
There are several possible causes of screen flicker.
One cause of screen flicker is if display is not properly turned off and driver does not wait the required 120ms after turning it off before cutting the power to it. Then on the next display power on, it may very visibly flicker for extended period of time, depending on time between last power off and next power on of the display. I believe mainline kernel driver does not wait. This was my bane when I worked on p-boot bootloader. :-D
Things in mainline get regularly broken by unrelated work, so maybe this got broken by the unrelated kernel change in 2024 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... that caused the clock that feeds the timing controller for the panel to not be able to set required 432 MHz to achieve the specified 60 Hz, so if you run mainline kernel change made for Olimex laptop caused Pinephone panel to be driven by 16% faster clock and refresh rate is almost 70Hz, which is out of spec. It can only be fixed by revert, without breaking anything else like eg. convergence functionality. Probably not the source of the flicker, but who knows how borderline panels behave. Eg. the mentioned commit says that pinephone SoC MIPI-PLL is unstable at 432 MHz, yet it does not acknowledge what that driving the panel at 16% faster clock may result into at all, from 16% higher power drain due to every userspace app having to render at 70 Hz, to stutter of video playback or UI stutter in systems that don't derive all timing from the display (eg. if input is read at 60Hz and output is done at 70Hz this can really mess up the UI feel) to behavior on borderline panels.
Panel clocked at higher than expected frequency may not complete the required LCD dicharge process correctly/completely due to compressed time (and this error may accumulate over several power on/off cycles), because it works with different than expected timings to complete a fixed physical process. (partly speculating here - what I know for sure is that this issue that causes flickering accumulates over several power on/off cycles if poweroff is done wrongly)
In any case, for my kernel I prefer 60Hz and underlocked PLL (works on all my 5 pinephones) so I revert that 500 MHz PLL limit in my kernel and run the panel at specified frequency. I don't see any flicker issues on my devices other than during development/hard poweroffs, etc..
"There were several pinephone HW revisions that fixed HW issues based on direct developer feedback... So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs."
That's great, but that wasn't my experience as an ordinary buyer of the PinePhone who wasn't on the special developers list and had no way to communicate with TL Lim. PINE64 provides no way for an ordinary user to register a bug report about the hardware in the PinePhone.
Since PINE64 didn't provide a way for me to register a bug report about it, I listed those errors on the wiki page. Instead of fixing the schematics, every mention of errors in the schematics was deleted from the wiki by user "Kx" on 2023-12-24. My questions on the PINE64 forum about how to get the schematics fixed were never answered. I don't blame PINE64 for the wiki edits, since I assume "Kx" was just someone in the community who didn't like seeing that there were errors in the schematics. However, the fact that PINE64 doesn't have a public bug tracker for its hardware issues is frankly an indication of problems with the way the company was run in my opinion.
"Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading."
I did some web searches and see that there were more commits to mainline Linux than I thought. I will edit that part. However, there was a marked difference between Purism and PINE64 in this respect.
"The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago."
I don't own a PPP, so I was going off what is listed on the PPP PINE64 wiki, which lists:
Bootloader (critical bugs), Stability (WIP), Suspend (Experimental), Updates (WIP), Phone (WIP), MMS (WIP), LCD (WIP), Rear camera (WIP), front camera (WIP), camera flash (critical issues), Bluetooth (WIP), GNSS (WIP), Sensors (WIP), Keyboard add-on (WIP), Qi Wireless (WIP), LoRa (not implemented), Fingerprint reader (not implemented).
Is the wiki wrong? I held off on buying the PPP for years waiting for those issues to be resolved, and I saw little progress on getting those problems solved since many of the high profile volunteers left in 2022.
"As for the company: Pine64 promissed 10 years of original Pinephone."
"Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing."
The PineTab2 wiki says that Bluetooth doesn't work, WiFi can't be reset, so device needs to be power cycled. The camera drivers need to be ported, The Rockchip CSI/ISP driver needs to be extended to handle 2 lanes. Suspend does not currently work reliably, so suspend has been disabled.
"Performance is not really relevant to "level of SW support"."
In the case of the A64 in the PinePhone, its GPU for hardware acceleration is pretty weak, and there is no ISP and aDSP, and the VPU's hardware encoder only includes H.264 video, so I don't think SW support was really holding back the performance of the cameras and the speed of the interface. There are other SoC's where proper SW support is a more relevant issue holding back performance.
Purism chose to upstream their changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel generally didn't.
To:
Purism generally chose to upstream its changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel were less consistent about upstreaming their changes.
I also added a postscript note at the bottom of the article thanking you for pointing out that you had submitted more upstream to mainline Linux than I thought, and linked back to this conversation.
Yes, the feedback that would tend to get addressed was always related to actual HW issues, and the issues listed in your blog article seem to all be failry superficial without any effect in practice. Eg. eMMC and DRAM is a commodity, various phones batches likely got different components based on what was available. I know for sure that my pinephones have different eMMC chips from different vendors that have different real speeds, so got to 78 MiB/s at DDR52 some just to 50-60 MiB/s, etc. DRAM will probably be a similar case just based on the fact that some phones got 2GiB and some 3GiB on the same PCB.
"I don't own a PPP"
Yes, wiki is not uptodate. There are several bootloaders available, from levinboot https://xnux.eu/log/103.html to u-boot with display support and graphical menu, there are small tools like rk2aw that fix the HW issue with charging from discharged battery (bootloaders fix it too to some extent), etc. Suspend is not experimental, never really was. It was working from the beginning, because it was implemented by Rockchip for google RK3399 chromebooks or whatever. LCD works. Cameras work and ISP is fully supported since like 1 year after release, and 0 days after release for ISP. Camera flash works, but should not be used for extended period of time, due to overdriving the LED. Dunno what bluetooth issue would be about, it's part of WiFi chip and supported mainline. GNSS fully works just like on Pinephone, since it's the completely identical thing part of EG25-G modem. Sensors fully work. Keyboard add-on is supported mainline, with out of tree policy manager for managing dual battery power if you like. Qi/LoRa are I know nothing about, and are just back-covers unrelated to PPP in particular. Convergence works well, including HDMI audio. Fingerprint reader was a user backcover project, that got some help from Pine 64 IIRC, and would be an insecure toy anyway. There's basically nothing missing on the kernel/low-level side of things that would be a show-stopper for anything I can imagine doing, except for video encoding acceleration. But that's just a lack of upstream consensus how to even create a kernel api for it. It's not really pinephone pro specific issue. There's no lack of upstreaming attempts for this over the years. There will be no encoder drivers upstream for any stateless encoder HW accelerators, until there will be consensus. Downstream kernel can have encoder in a few days if someone wants it.
Pinetab2 wiki is not accurate either. You'd be better off looking at pages of distros you'd like to use that support the device. Support level is always determined by the distro anyway.
As for GPU acceleration. SW support is absolutely key, especially on older GPUs. If you optimize for those you can have very snappy UI for pretty much any imaginable smartphone functionality with imperceptible latency even on original Pinephone with maybe one exception, and that is web browsers. Those are just so bloated these days it's ridiculous.
Normal distros and Android have extremely bloated architecture, so things get slow and heavily dependent on storage load times. I know for sure that original Pinephone GPU is fully capable moving those few UI pixels typical mobile UI has at 60 FPS with barely any dips even at reduced CPU/GPU/DRAM frequency to save power without any sweat. Things need to be done differently though.
Central support status matrix pages are futile for Pine64 devices. You can have perfect kernel/bootloader support and any chosen distro can still be unusable, because of lacking userspace integration. And there are maaany distros. And some pick and choose kernel patches, and fix/break various things. Some distros also disown bootloader support, so whether something will work or break depends on what bootloader user runs, etc. etc.
There's plenty of outdated info everywhere. Users should just ignore anything status related that's apparently old. And that wiki page was last updated 3 years ago or so.
There were several pinephone HW revisions that fixed HW issues based on direct developer feedback. Yeah, there was no direct communication with HW engineers, but at least the critically important feedback was applied (otherwise modem would not be able to wake up Pinephone SoC from sleep and Alt-D over USB-C would not work at all, and probably bunch of other things I barely remember). I or someone else in #pinedev could tell TL Lim, and if change was reasonable it would be made. There was quite lively discussion around HW issues in #pinedev early on. And company did not seem to lack effort, eg. for Pinephone keyboard there were like 5 revisions, including doing an X-Ray analysis of burned down keyboard MCU and subsequent citcuit improvement. So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs.
"The volunteers working on the PinePhone's kernel generally didn't [upstream]" is factually completely wrong.
PinePhone DT was mainlined for Linux 5.7 by me. smaeul rewrote the sun8i-codec driver and did lot of stability and other work, anarsoul upstreamed Bluetooth and maintained Lima, and many many many more small upstream contributions by different people (git log is your friend), just on the kernel side. People created entire new upstream projects like Crust and p-boot and levinboot, etc.
Yes, there's some long residual stack of patches, but so what? Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading.
And another thing is that even if there was lack of upstreaming, almost no Anroid phone is fully upstream in Linux and it doesn't prevent it from gaining marketshare. Downstream kernels suffice for it.
Latest version of supported downstream kernel for pinephones with good HW support has been available for years. Almost no Android phone can even claim that for their downstream kernel.
Then there's over-estimation in the article of how upstreaming to kernel is important. You can easily say that having full HW support quickly in some downstream kernel is kinda preferable, because it allowed people to actually use the phone sooner, and allowed userspace development to progress. If every change would have to go to upstream, with its long iteration times, etc., people would not be able to use the phone at all for 4 years or so. How many would even stay around? :) I ceratinly prefered making the HW work and work well, over upstreaming. I understand upstream kernel is a distro maintainer wish. People are free to have wishes. :D
Pushing upstream changes coordination of work and to some extent simplifies maintenance for some, while making it way harder for others in the community.
The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago. Yes, again, you need a downstream kernel, but it's been maintained for every release for years since the beginning, just like PP. It's very similar situation to Raspberry Pi, which also sucks without downstream kernel, but did not prevent it from reaching marketshare, or whatever. Commercial cancellation is more lack of interest/commercial viability, rather than anything pointing to lack of SW support.
The article opens by promising to "examine what held back mobile Linux." Well, it consistently assigns blame to companies/vendors while treating the enormous volunteer engineering as background and blameless. Well it's not.
As for the company: Pine64 promissed 10 years of original Pinephone. It's so far delivering what? 8th year? At the same/similar pricing to 8 years ago, across all that happened in the HW industry in the meantime? Covid? Ramocalypse? I'd call that a massive success on promissed claim. The company also never promissed fully working OS/HW android experience. It promissed cheap accessible long-term stable HW product to jumpstart the ecosystem (paraphrasing from memory). And I thoroughly enjoyed developing and supporting Pinephone on the kernel side for 8 years release after release, building well designed (as far as UX goes) bootloaders, and interacting with TL Lim and wider community, etc.
"Once the best volunteers abandoned PINE64, the company hasn’t been able to complete the development of the PinePhone Pro, PineNote, PineTab2 and many of its other projects, so the people who ordered these devices are unlikely to ever be able to use them as fully functional devices."
Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing. I know of one: HW accelerated video encoding on original Pinephone. The only claim I see other than performance, is lack of "HW accelerated video encoding". But who would want to record videos with webcam level sensor that uses CAF for auto-focus? Has anyone even tried to imagine what it means practically when you get CAF full range sweep in the middle of the vide? :)
Performance is not really relevant to "level of SW support".
You can also say that perhaps people drifted off after the work was mostly done, because there was nothing more exiting to do, other than absolutely unsatisfying gruntwork that even paid engineers at most android shops don't bother to do.