I take no pleasure in writing this blog post. In fact, even as I am writing these words I am internally torn on whether this is the right approach to addressing the problem on hand. Whether I’ve chosen the right approach remains to be seen, but regardless, I now feel it’s time to confront misconceptions about the PinePhone.
The misconception concerns the openness of the PinePhone. On numerous occasions I’ve seen the PinePhone being refereed to as closed-source on one level or another. I don’t know the origin of this misconception nor do I understand the reason why it has become propagated throughout the internet. What I do know, however, is that it has been repeatedly quoted in online articles covering the PinePhone or other Linux devices for over a year now.
So let’s set the record straight: the PinePhone is not ‘full of closed-source firmware’ and, moreover, is one of the most open devices out there.
Let’s start with the Allwinner A64 SoC, which is the brains of the PinePhone; it runs mainline Linux, uses mainline ATF and u-boot and there are open source drivers for all main SoC components. This openness extends to the Lima GPU driver introduced in kernel 5.2.
Linux 5.6 will contain drivers for all major components of the SoC. The parts which still need to be upstreamed to mainline are HDMI audio and msgbox – both drivers are in the works. For more information on mainlining efforts, please refer to the A64 column at https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix
It’s worth mentioning that LPDDR3 initialization is done by u-boot SPL, which is also open source. There are no blobs in there either.
Needless to say, the PinePhone itself is an open platform for any OS to run on. The grand majority of the OSes developed for the PinePhone are, in and of themselves, completely open too.
The non-FOSS parts of the phone are as follows: WiFi and Bluetooth firmware must be uploaded to the Realtek RTL8723cs on initialization, an optional auto-focus firmware (currently not used in any PinePhone OSes) can be uploaded to the rear OmniVision OV5640 camera, and the Quectel EG25-G LTE modem runs its own closed-source OS.
The WiFi module communicates with the CPU over SDIO and BT is over UART – neither of these connections provide direct access to CPU memory.
The LTE modem on the PinePhone is a ‘black box’, and runs its own Linux system internally. This includes all the proprietary modules (blobs) needed to run the actual cellular radios. However, this system is almost entirely isolated from the main system running on the A64 SoC. The only data contacts between A64 and modem are USB connection for data and I2S connection for audio. All data going in or out of the modem must go over these connections.
There is no RAM or flash storage shared between the systems. In short, unless you explicitly send data to the modem, it is never in contact with the blobs running inside it. The modem cannot send any data to the phone unless phone is willing to receive it (that’s the basics of USB).
I do not think that this misconception arose online as a result of someone’s ill intention or a conspiracy. I really don’t. I do, however, feel that if I were to leave this unanswered for much longer then this misconception would be further propagated.
54 responses to “Setting the Record Straight: PinePhone Misconceptions”
Informative and educational and clarifying, Thank You for an Excellent summary! 🙂
I think it’s being misread and is instead saying that the Pinephone is unlike the others they compare it to.
Very good article, it clarifies the hardware boundaries and sets the record straight.
This is an excellent, well communicated article. As soon as the PinePhone is ‘stable’ I plan to get one. It can’t come soon enough! I hope there will be considerable progress made this year.
1st I’ve heard any of this.
Always love more tech info.
Thanks for the links.
Still inpatently waiting for user ready
Pinephone, pinetab, and pinetime.
Any consideration, debate, or rummor on 2nd
Gen Pinephone components like AM/FM/
HDTV/CB/SW receivers, IR transceivers, or
IR camera ?
Why does it use a WiFi chipset that requires closed source firmware when their are ones available that are fully free? E.g. Atheros AR9271
I have already bought a braveheart pineohone, I’m not trying to put it down, just curious.
Likely because of power envelope, cost at scale (or lack thereof, depending on numbers) and size on board.
+1
ditto.
Why use the Quectel EG25-G LTE modem, and not one with Free Software drivers?
https://wiki.pine64.org/index.php/PinePhone
…maybe hardware revision 2 will remedy this…
The Quectel modem has Free Software drivers and even has partially-free firmware (since it runs Linux). It is very unlikely that a Free Software LTE modem will ever exist, simply because LTE devices require certification.
The closest that exists is the Osmocom 2G baseband project, but that isn’t intended for use by end-users, part of it runs on a laptop and it still uses the non-free code in the ROM.
https://osmocom.org/projects/baseband
BTW, even the open-source WiFi firmware code that exists (like ath9k_htc.fw) still uses the non-free code in the ROM.
Firmware; this is the confusion for me. Some is erasible/writable by the kernel/driver…some is not…knowing which is which when one changes the kernel/driver.
I understand that the GPU is on the SoC and is chosen with the SoC. The LTE modem is separate from the SoC.
Additionally,. Putism seems to be considering 2 different LTE modules and yet still in consideration for FSF RYF. Librem 5 has announced an option of Gemalto PLS8 or Broadmobi BM818.
You might be able to make sense as to why they are still in FSF RYF consideration. Is this the mainboard design , LTE isolation design, and not Free Software firmware running on the module?
Here is a post by Nicole Faerber:
https://puri.sm/posts/librem5-2018-09-hardware-report/
Cellular (baseband) modem section.
It would be nice to have Pine64 make a public statement like this:
“We take the notion of “free” or “libre” seriously, striving to comply with the Free Software Foundation (FSF) strict “Respects Your Freedom” (RYF) requirements. Having that endorsement is an important and critical goal for us.”
Not that it is possible now, if ever, but it is a goal/mission.
To me, it isn’t about Linux, it is about Fee Software.
> It is very unlikely that a Free Software LTE modem will ever exist, simply because LTE devices require certification.
Certification is not a barrier in releasing something as Free Software. Being certified software and being Free Software is not mutually exclusive per se. Unless certification process bans release of source code. I know no such cases myself.
FCC regulations prohibit releasing several parts of how a 3G/4G/5G modem works inside, if you release it or leave it modifiable, your device simply cannot be certified.
Thanx for collecting the (required) design compromises of the pinephone in a single place, as well as the state of driver upstreaming.
One more thing I seem to remember reading about the pinephone: Isn’t the GPS hardware part of or at least accessible by the modem?
If so, this should also mentioned near above list-of-blobs.
Wrt the Quectel modem running Linux itself – do you have any links/paper/docs to read a bit more here?
Wrt Wifi firmwares at least, I’ve seen these labeled an OS as well, albeit smaller than the modem.
One more missing blob for completeness’ sake: the sim card itself, with its hardware and some processing capabalities.
thx for the list,
Pete
Re the Quectel modem running Linux-based firmware, the Osmocom folks semi-recently did some reverse engineering on these devices:
https://osmocom.org/projects/quectel-modems/
Completely outside of the scope of PinePhone – but shouldn’t Qualcom be publishing the source code of the GPL bits in that firmware ?
IIRC from watching the CCC talk that Harald did about these modems, Quectel and Qualcomm are in compliance with the GPL for that firmware, I suggest that you do test their compliance if you are able to.
I think you handled this perfectly. I’ve seen some mentions about closed binary blobs, but I never really had any clue what the actual scope of openness was (or wasn’t). Thanks for clearing it up!
I really appreciate how transparent you guys are. Continuing along this path will guarantee my continued support.
Do you know if any of the other chips in the SoC or the board have embedded proprietary firmware? I’m thinking of things like the USB controller and so on.
Have you considered adding hardware supervision of the modem and all the other chips that are running proprietary software? The Neo900 project pioneered this sort of supervision and have released schematics, talks and documents on it:
https://neo900.org/
https://neo900.org/faq#privacy
https://neo900.org/news/about-the-asn1-vulnerability
https://neo900.org/news/paypal-resumes-neo900-sources-again
https://neo900.org/resources
Does the AR100 OpenRISC power management controller embedded in the A64 SoC use the open firmware or the proprietary firmware?
https://linux-sunxi.org/A64/Memory_map https://linux-sunxi.org/AR100
I noticed that the GPS functionality is integrated into the modem, this seems like a potential privacy violation, are there no modems that don’t have GPS functionality?
– GPS cannot run opensource firmware for some legal reasons (they are not allowed to report both high altitude and high speed at the same time, in order to not use cheap GPS as source of missile guidance systems – so they are all provided under licenses that prevent the users from changing that inside the firmware).
– modern AGPS needs access to the cell modem in order to acquire fast lock using the ‘assisted’ part of AGPS.
Otherwise, you’re back to the old in-car dedicated satnavs’ “takes ~30min to lock, unless you have pre-loaded the ephemeris table with your computer”.
(Though *that* could be compensated for if the smartphone OS’ uses the list of visible Wifi AP / nearby Cell towers to query some database (Mozilla, Google or Apple. Or some built-as-you-go internal list) to guesstimate approximate position, like on lots of smartphones.)
Thus I guess that’s why most of the time you find combined GPS + Cell modules.
There is an open source GPS program here, it has an Android app and hasn’t been banned yet:
http://www.rtklib.com/
Also, can we get access to the Linux system running on the LTE modem somehow? I noticed that the Osmocom folks are working on reverse engineering these modems:
https://osmocom.org/projects/quectel-modems/
I was unaware of the misconceptions, except for single reddit comments and such. But it is good that you adress the issue if it’s there. Now we have a good source to link to when needed.
[…] Setting the Record Straight: PinePhone Misconceptions 5 by UkiahSmith | 1 comments on Hacker News. […]
[…] Setting the Record Straight: PinePhone Misconceptions 5 by UkiahSmith | 1 comments on Hacker News. […]
[…] Source link […]
Thanks for the writeup and keep up the good work, folks. Excited to get my Braveheart edition. Considering adding a thermal sensor to it using the i2c pads on the back for a pocket thermal camera.
Another company lied and omitted pieces of information about
how much non free software the devices on their products
require in order to work. Unfortunately their lies paid off and they
have gathered millions of dollars. I warn people about that
company. About the pinephone, pine64 has not acted in such
a way. People favoring free software know they have to
look into the details about a piece of hardware if they want
to get to know a piece of hardware’s stand on free software.
What the pinephone has experienced is nothing more than
a scrutinized verification on how free software it is. A company
like pine64 has supremacy about what hardware it selects.
But if you release wrong or incomplete pieces of information about
the pinephone and do not act accordingly when corrected, then
it is important that people get warned about your product. If
you would provide a thorough description on the free software
matter on your pinephone’s advertisement, it could become a
sales advantage for the pinephone.
Thanks for the very nice and clear article. Especially the info regarding the baseband interface.
I’m looking forward to ordering a pine phone and keyboard. I hope the next one could have a RTLSDR built in.
This article is obviously written using the “blob” definition used by Stallman, not the more practical and realistic ones used by the BSD community; please see http://www.gnu.org/distros/common-distros.html#BSD and http://www.openbsd.org/lyrics.html#39 (“Blobs are vendor-compiled binary drivers without any source code.”) and http://web.archive.org/web/20060603230017/http://kerneltrap.org/node/6550 (“we don’t want to become Hermes” “assembly language programmers”, “don’t load us up with more tasks”).
If my understanding is correct, PinePhone will ship with no blobs running on the main CPU using the main memory, just the proprietary firmware on some of the auxiliary devices (we don’t call those blobs). It might help you to clarify that the wireless device driver is OSS, too, right? (I think some people might miss this fact if not explicitly stated, and incorrectly assume that firmware is the same as the driver, which it is not.)
Also, any chance to clarify whether the manufacturers of the individual chips have programming documentation freely available for the OS device driver folk, without NDA? (This would make it fully open.) Or whether the non-Linux device driver developers are expected to use Linux device drivers as documentation, having to fish for the specs using the reverse-engineering techniques? (Ouch, did we got sold again?!)
Last but not least, can you also clarify whether all the firmware blobs are freely available for unlimited redistribution on simple terms without any silly restrictions, or whether contractual obligation are required in order to become a “distributor”? See http://web.archive.org/web/20060603230017/http://kerneltrap.org/node/6550 for some explanation if this is unclear.
In any case, thank you for clarification. So far, this seems better than we expected!
Thank you for addressing this, I am glad that you made the effort to make all of this clear to everyone. Even if you did not take pleasure in writing it, I am glad to see it documented plainly and all in one place. I am also really happy to hear that the only cpu-loaded firmware required is for wifi/Bluetooth, so that a fully free system is possible without entirely crippling the device.
Brilliant project
Great philosophy
Invested in a great set of devices to help provide affordable open source products
Commitment to clarity
Thanks for everything
Comments are written on the Internet that the A64 SoC is poor in performance, the GPU is especially old since the late 00s year. I would like someone to measure the performance of Pinephone on some benchmark in order to at least dispel these myths. And so the ambitious project, the first Linux-smartphone-PDA, delights me how it brings computers and smartphones together.
I wrote already – the question is closed, we discussed in the telegram. The smartphone is not for everyone, and who does not understand why this is – they should be ignored;)
Is Pinephone manufacturing in Chinese areas
currently under Corona qorenteen ?
Can Corona virus be passed on pinephones
shipped ?
The COVID-19 virus will not last on a surface as it takes to ship it from anywhere in the world. This can be verified on the internet.
Thanks for the clarification, Luke.
FYI, the [Ars Technica article](https://arstechnica.com/gadgets/2020/01/librem-5-phone-hands-on-a-proof-of-concept-for-the-open-source-smartphone/) you allude to in this post has been updated; it no longer lumps the PinePhone in with devices “full of closed-source firmware”, and has “An open source clarification” at the bottom that links to this post.
Great post. Thanks.
Some forists seem to feel hatred for allwinner, not being able to separaze the silicone from the bsp. The best thing to do is to advocate and to evangelise for sunxi 😉
And to all those who want to compare benchmarks of the pinephone with the actual top of the line Qualcomm 8xx Snapdragons forget it’s a different league, its not meant to be a gamer phone. Its an open source friendly phone, its something to tinker, a proof of concept. A toy for us linux and privacy lovers. It’s just a way to demonstrate how the smartphone world could look if it wouldn’t be all based on binary only drivers and closed kernel modules. This is more than a compensation for the slightly dated SOC.
[…] both the Librem 5 and PinePhone have separate baseband chips. And there the driver was clearly increased security. Both have hardware kill switches for the cellular baseband, WiFi, GPS/GNSS, camera and microphone. […]
Out of curiosity, what of the battery? Does it have its own circuitry that communicates things like power level and temperature? If so, how open is that?
w zwiazku z epidemia jak wyglada kupno komorek? czy da sie z nich juz dzwonic czy ciagle nie?
[…] Pinephone misconceptions […]
While the PinePhone makes use of much Free Software, it still can’t be certified as an FSF RYF device. That might be the confusion/frustration. However, I doubt Purisum’s Librem 5 will obtain the certification either.
Does Pine64 have aspirations of building Free Software Foundation Respect-Your Freedom devices?
https://ryf.fsf.org/about
‘The “Respects Your Freedom” certification program certifies retailers who sell hardware in a manner that respects the rights of their users and that comes with only freedom inside.’
It would be nice to see it use Coreboot-DepthCharge as the bootloader-payload for security and speed.
No hardware is truly capable of actually respecting freedom yet. For example, there are no USB controllers that run free firmware, even though there are “RYF-certified” laptops that have USB. RYF can also *reduce* potential future freedom by causing RYF-intending device manufacturers to make design decisions that block reverse engineering thereby shutting off future access to free firmware replacements.
This rabbit hole is deep: https://lwn.net/Articles/743822/
Here’s to hoping that this does to open hardware what linux has done for open software. Linux just keeps getting better and better, and more people join in putting out free and open source software. Pinephone will keep on getting better and better, and more people will want to put out free and open source hardware.
[…] PinePhone Freedom […]
I regret contributing to this misinformation, based on out-of-date information. For me, what made the PinePhone less free than the Librem 5 was the choice to use the Allwinner A64, a choice that Pine64 made years ago, before even thinking of the PinePhone. Back then, the Vivante GPU had an open-source driver that sort of worked, and the Mali GPU driver was highly experimental.
As more devices were sold, I expected it to be possible for open-source enthusiasts to reverse-engineer the driver, but I couldn’t count on it. After all, the PowerVR GPUs were sold by the billions, and that never was supported reasonably in Linux. What I didn’t anticipate was that the Mali driver would be merged into the mainline Linux kernel already. A few months ago. A short time before I commented in Ars Technica forums that the PinePhone seemed less free. Oops.
So, mea culpa, and here’s the backstory of where my mistake came from.
It’s good that You try to avoid BLOBs as much as You can. Unfortunately nobody so far has created open-source&hardware LTE modem.
I haven’t heard this. Most of what I have heard is positive, and very little negative.
I do have a complaint. I am in the US, and the Manjaro that shipped with the Pine64 wouldn’t see any cell towers or stay open for an real length of time. It was so frustrating that I SSH in to do anything with it, and felt like throwing it against the wall. I then flashed a 128GB card with Manjaro 22.01 from GetHub, which has a newer one up there just hours after I downloaded this one. Now I can make and receive calls, and a lot of the other problems just disappeared. What doesn’t work, I seldom or never used on my other phones anyway. So far I am happy with the phone. In my opinion Manjaro 21.03 is trash, and shouldn’t be shipped with this phone.
What a great post. This highlights the propreitary nature of much of the hardware driver industry software and the OEM’s opposition to releasing drivers as “Open Source” probably due to some patent lawyer’s backward counsel. However, I can understand that software will reveal alot about the internal software design.
Muy feeling is that the Pinephone is as open as reasonably possible. Hundreths of thousands of dollars would be needed to develop open source alternativas forma the components in question. It is a great start and supporting this project is probably the best way to ever have a wholly free and open cellphone.
I think in the last you meant “conspiracy theory” not “conspiracy”
Also, for sake of record, editing it mentioning the option of a mostly free GSM firmware for the EG25-G would be awesome.
Theres a chance this was my fault. I mentioned problems with Mali Graphics CPU’s.
But the problem was specifically about the CubiBoard, not the PinePhone specifically.