In their monthly announcement, among all the cool things Pine64, they talked about the open firmware for PinePhone’s LTE modem. The firmware isn’t fully open – a few parts remain closed. And Pine emphasizes that they neither pre-install nor officially endorse this firmware, and PinePhones will keep shipping with the vendor-supplied modem firmware image instead.
That said, the new firmware is way more featureful – it has less bugs, more features, decreased power consumption, and its proprietary parts are few and far between. I’d like to note that, with a special build of this firmware, the PinePhone’s modem can run Doom – because, well, of course.
And with all that, it’s become way easier to install this firmware – there’s fwupd
hooks now! You can think of fwupd
as the equivalent of Windows Update for firmware, except not abusive, and aimed at Linux. A perfect fit for keeping your open-source devices as functional as they can be, in other words.
What’s the deal? If open firmware is that much cooler, why don’t more of our phones have open firmware options available?
What’s The Deal?
Phone modems are fairly complex. Your phone, numpad or “smart” alike, has a modem chip from someone like Mediatek or Qualcomm, and that chip has a reasonably powerful CPU core inside. For instance, if you take the SIM800 modem (a 2G-only modem module), it has the MT6260 chipset, which is an ARM7 single-core CPU and GSM baseband in one chip. You can think of it as an ESP8266 on steroids, but for GSM.
In the SIM800 module, this CPU acts as a “receive AT commands and do GSM things” intermediary, but it’s also been used as the does-everything processor for GPS trackers, smartwatches and other GSM-connected devices. In fact, the MT6260 can run an entire Nokia 3310! The 2017 version, to be exact.
With the PinePhone modem, the situation turned out to be the same. It was quickly found that the Quectel modem ran a stripped down version of Android on its ARM core, with adb
shell available over the modem’s USB interface. When a few adventurous hackers started probing it and got shell access, they found tools like ffmpeg
, vim
, gdb
and sendmail
compiled in – certainly not something you’d need on a cellular modem, but hey. Firmware images got unpacked, some code got reverse-engineered, and the modem got itself a newly compiled Linux heart.
The specific chip powering the PinePhone’s Quectel EC25-G LTE modem is a Qualcomm’s MDM9207, with a single-core CPU and 256 MB of RAM and flash by its side – this Pine64 Wiki page will get you up to speed with the technical details. If you think about it, the PinePhone isn’t a quad-core CPU device, really – it’s a penta-core dual-CPU device, running two Linux installs side by side. And yes, it’s not impossible that same goes for your Android phone.
Why Is This Valuable?
Why value cellular modem firmware openness, anyway? We’ve been living quite fine without it, some might say. Turns out that open firmware for modems brings good things aplenty!
One of the most noteworthy ones is the ability to downclock the CPU core of the PinePhone modem – bringing it from 400 MHz to 100 MHz. This makes the modem consume less power, and not heat the phone up as much. The modem’s configuration, for instance audio bitrates, is made more dynamic – no longer requiring a modem reboot to change audio parameters. There’s all kinds of developer-friendly features like logging capabilities and testing facilities; PinePhone’s integration can also be improved upon – i.e. debugging and improving call handling while the PinePhone’s CPU is suspended to improve battery life further.
And, of course, Doom.
It’s also possible to fix many of the problems that impede upon PinePhone’s cellular capabilities – as it tends to be with cellular modems, there’s plenty of firmware problems. Some of these are fixable by using a different vendor firmware image, but going between binary images and looking for the least glitchy one is an exercise in frustration. It’s also possible to patch vulnerabilities, like the “render the modem inoperable” one that was exploited by the PinePhone-targeting weird piece of malware half a year ago.
This is the kind of control that large-scale phone manufactures already get over the modems they embed into phones, to be clear. An open phone project has to have this kind of control – otherwise, it is bound to be disadvantaged, purely because of reliance on proprietary firmware images with all sorts of glitches and mis-features. Without firmware modifiability, open phones have one more roadblock towards feature parity, and our technology is already quite hostile to open phones as-is.
Not everything is open in this firmware. The baseband firmware, aka the RF bits known as ADSP firmware, remains closed and not yet reverse-engineered by anyone – you’re not gonna be running OpenBTS on this modem yet.
The TrustZone kernel remains closed too – my understanding is that it’s signed by Qualcomm. However, the Linux install is fresh and no longer stinks, and the Qualcomm’s application stack seems to have been replaced with a more lightweight one – removing any need for closed userspace tools or drivers, too. This is a firmware you can modify to your needs in many aspects, then compile and flash yourself.
I keep listing all this background and benefits – to think of it, it’s a bit unfair that I haven’t answered the intro question yet. Why haven’t we had modem open firmware earlier? Well, we’re finally arriving at the “why”.
Regulatory Irregularities
The open firmware for the PinePhone modem is technologically superior, and code-wise, the baseband, aka RF paths don’t change. So, why not ship this firmware from the factory? Why the “not officially endorsed or recommended” thing? The answer is, Pine64 could lose regulatory approval in certain countries if endorsing or pre-installing this firmware – which is why they’re not doing either.
As it stands, one would be foolish to expect Pine64 endorsement of this firmware. They work hard to ensure that PinePhone remains certified in as many countries as possible – without pre-established networks of representation and competencies that phone manufacturers benefit from, it’s a complicated task. If you’re legally able to run this firmware, godspeed – otherwise, all possible responsibility, however unlikely, shall be yours. Here on Hackaday, we revel in the freedom to do things as a private individual that you couldn’t do with gear for sale.
And one such area is radio-relevant firmware. Direction from the US FCC on regular WiFi router firmware resulted in router manufacturers attempting to restrict you from installing OpenWRT. Which is to say, it should be possible for routers to remain custom firmware-friendly, but I’m not optimistic. Observing the trends over the years, noticing firmware get more and more locked down, I’ve been thinking a lot about a certain question.
Do The Manufacturers Just Not Bother?
It’s important to understand that regulatory restrictions can be worked around by the cellular modem manufacturers. Beyond all excuses and laws, there’s the question of effort. It’s not impossible to open-source modem firmware with certain caveats, it’s that manufacturers are not motivated to bother with the effort of making it open. Laws can be worked around – we know full well there’s no shortage of legal creativity in marketing departments. The sheer lobbying power of corporations, sizeable when they stand to lose profits, isn’t on display when firmware-restricting laws get passed. Why not here?
What I’ve seen used as an excuse is the sheer complexity of cellular tech – and it holds some water. These standards are complex indeed. However, it didn’t take wading through cellular protocol nuances to downclock the modem’s CPU frequency, or fix interfacing bugs. Some parts of it could be open, or at least open-source, and yet they’re not.
Other excuse is the regulatory compliance, and that holds some water, too – however, the conversation was never started to begin with, there was never an acknowledgement of our needs, needs that can and should be discussed. Some modems have an SDK that integrator companies can make use of, a few modems will provide you with some kind of code interpreter, even – more often than not, access to documentation for these requires an established business relationship, and then, regulatory troubles seem to not be as much of a blocker.
A lot of problems excused by regulatory compliance happen to benefit the manufacturers financially – whether through new hardware sold because of planned obsolescence, or money not spent on effort they technically aren’t forced to put in. Firmware customization stays behind NDAs and business relationships, as opposed to being at least partially open and competitive. Which suits monopolistic players just fine.
Firmware openness is a question of committing to it and working through the hurdles – and if manufacturers won’t put that effort in, at least we the hackers can compensate here and there. For now, if we want feature parity for open phones, we’ll have to get our reverse-engineering tools hooks-deep in proprietary firmware at some points.
Why Now?
You might be wondering – why specifically now, and why Pine64? There have been open-source baseband projects before, but not many of them have reached this far. Well, a good few factors played in their favour, and I’d like to talk about the primary one.
Getting hardware into hands of hackers is key to breakthroughs like these – this is what Pine64 has managed to do well. PinePhones have been shipping for over two years now, and basically everyone who wants one can get one, resulting in a fair few hackers owning an open device with a Quectel modem in it.
From there, it was a matter of time until hackers started poking at the modem! The low price also helps – while PinePhone is nothing to marvel at when compared to flagship phones, it also only costs a fraction of the price, and having Linux on it helps you squeeze out more when it comes to performance, negating the downside that’d be more significant if it were to run Android.
I would also add that having a hacker-friend phone at such a low price means that you make it accessible for specifically the kind of hackers already used to squeezing more and more out of the devices they own – for financial reasons, among others. Sometimes our skills are sharpened by need, which is one of the reasons work done by Pine64 is all that more valuable – helping a new generation of hackers access tools and playgrounds they’d previously be financially locked out of.
New Opportunities
It could very well be that one of your personal phones is hackable in the same way – ripping out the subpar Linux build running your phone’s modem and replacing it with a Linux build you have more control over. PinePhone’s availability has helped us get over this hurdle, and now future projects stand to benefit from it. In fact, you can get one of these Quectel modems as a mPCIe card, and build an open-firmware modem into your own devices easily!
This firmware is not fully open, but a large portion of it is – which happens to be the portion most useful for improving PinePhone’s cellular capabilities. With modifiability like this, what are we going to achieve next? And given these capabilities, what challenges will we face in the future? We don’t yet know everything that will happen, but this work is good news for us.
What do you mean by “we’re moving away from openwrt flashed routers…” in the caption? I see it being adopted more and more every day.
Interesting! My understanding is that manufacturers are less interested in letting us do so, and it’s been getting more complicated – chip maker proprietary bullshit doesn’t help either. Could you tell me more about what you observe being adopted?
In the article:
“Direction from the US FCC on regular WiFi router firmware resulted in router manufacturers attempting to restrict you from installing OpenWRT”
The caption:
“We’re moving away from OpenWRT-flashed routers capable of years-long uptime”
So I think by “we” is “the US” (as usual, the center of the universe), and the move is “forced by manufacturer adapting to regulations”
But we don´t really know what the author meant. Can´t say articles here are the paramount of journalistic precision and exactitude, to be polite.
can assure you, I’m not an American, and not particularly interested in centering America – there’s enough of that happening as-is!
As for the subject, I don’t have a lot of faith in them making firmware non-upgradeable for US only – I don’t think there’s anything forcing them to have open firmware in EU, for instance. And even when it comes to USA-only changes – that’s a large portion of hackers out there.
That’s essentially what Xiaomi has done with their AX9000. The Chinese version has secure boot disabled/not enforced so can easily boot any working image from flash. The hw-identical International version has secure boot enabled which currently hampers booting unsigned images from flash. You can still boot initramfs images via ftfp, just not from flash.
Xiaomi is about to get a hard lesson in grey markets?
Needs to be done every few years. Always ends the same way.
I remember buying Thai Netmare licenses for much less than the local novel vendors _cost_. His wife worked for us, so it got back to big red. I suggested he start buying grey market, but he was chicken they would cutoff his sweet sweet CNE training/testing grift.
“I don’t think there’s anything forcing them to have open firmware in EU, for instance.”
“FCC radio lockdown” comes from the Germans. They raised the issue of weather radar interference with 5GHZ wifi radios that did not had built-in radar detection, and they pushed the FCC to adopt radio lockdown.
Radio lockdown has passed in the EU with the 2014 regulation, there were public consultations on both sides of the Atlantic (mostly saying “don’t do this”), but diplomats in those EU technical committees continue to push for Radio lockdown, in ***all frequencies***.
The FSFE has worked a lot on this:
https://fsfe.org/activities/radiodirective/radiodirective.en.html
That’s nice and all, but does it run Doom?
B^)
You didn’t bother reading the article, I see…
“That said, the new firmware way more [featureful](sp.) – it has less bugs, more features, decreased power consumption, and its proprietary parts are few and far between. I’d like to note that, with a special build of this firmware, the PinePhone’s modem can run Doom – because, well, of course.”
yes https://github.com/Biktorgj/pinephone_modem_sdk/releases/tag/0.6.7-Doom :)
… not until you flash the Doom firmware ;-P
ok why pine 2040 pico not is open similar this?
Do you mean the Raspberry Pi Pico RP2040? Pine64 is a different entity from the RaspberryPi people and I don’t think they have any similar products.
Similar to the RP2040 that is.
Did people learn anything useful, for the Pine phone, from the files NEC left for the Terrain when they exited the market?
What files would be good for to community to look at? If you have pointers someone might be able to use them.
Hi,
Well, when no one responded I deleted some of the NEC files from my HD because I figured no one was interested and since my NEC Terrain is soon to be crushed, since I will not be writing code for it, I decided why keep the files any longer? They were the source for the boot loader and the two .dll files. Though I do still have them on CD-ROM and DVD in old archives somewhere …
That being said, I still have these three files, which appear to be the complete source files needed to build the images for the NEC Terrain. They were released by NEC, after they exited the market, when someone strongly reminded them of the GPL (?) terms of making the source available. From going through the blue tooth files and such, it appears to be the complete source code.
nec-external_Terrain.tar.gz
nec-kernel_Terrain.tar.gz
nec-terrain-readme.txt
From the readme file:
===================================
How to setup the build environment.
===================================
This document describes how to build a build for the Terrain. Please follow the steps below to complete the Build.
1. Download the Base environment from Code Aurora Forum (CAF) found at https://www.codeaurora.org/
The Manifest File is as follows:
https://www.codeaurora.org/xwiki/bin/QAEP/
-Android releases-
Date Tag / Build ID Chipset Manifest Android Version
August 10, 2012 M8960AAAAANLYA153617 msm8960 M8960AAAAANLYA153617.xml 04.00.04
$ repo init -u git://codeaurora.org/platform/manifest.git -b release -m M8960AAAAANLYA153617.xml –repo-url=git://codeaurora.org/tools/repo.git
$ repo sync
2. Overwrite the Terrain’s open source environment with the environment downloaded in Step 1.
3. Add the (JDK) Java Development Kit’s path to the environment variable PATH.
example: $ export PATH=/bin:$PATH
4. Run the commands below:
$ source build/envsetup.sh
$ choosecombo release msm8960 user
$ make clean && make -j8
Note: Ensure to match the last “-j8” to the Build environment.
Caution: Please note that we cannot guarantee operation using images created with this build.
======================================================
(C) NEC Mobile Communications, Ltd. 2015, All rights reserved.
Is this only PP or PPP too?
Both PP and PPP. By my understanding, though, there are other QoL issues still being worked out with the PPP that make the PP a better daily driver for now. I’m clinging to my dying android until it seems that the PPP is a reasonable daily without significant fiddling.
I don’t know what those are but to someone over a certain age it sounds like you are talking about dialup.
So in my mind that is what you are doing. Maybe you are stuck at 33.6 and trying to hack in the compression to get up to 56k? In my head I see you pulling your phone out at the coffee shop and that unforgettable old sound of a dialup modem connecting fills the room.
I’m sure it’s wrong but I like this image, I’m keeping it.
A good example of why Acronyms/Initialisms should see less use. In this case they mean PinePhone and PinePhone Pro
…are you sure you have read what I wrote?
clearly not!
If you think there aren’t plentiful zero-days in closed modem firmwares, you must not even tangentially follow the security world. Said vulnerabilities are very common and quickly abused due to the exposed nature of the attack surface and the ubiquity of more common makes.
That’s not to say that FOSS alternatives are always better, but firmware zero-days sure isn’t a legitimate argument to be leveled against them.
Cool! I hadn’t seen this before, but now I will be looking into using this on my daily driver PinePhone.
If the modem itself is already running Linux, it seems like it should be possible to cut out the middle-man.
There are plenty of applications that could likely run directly on the “modem” and forego the Pi or whatever microcontroller.
Is there any information on exposed pins available from within the modem environment? GPIOs, I2C lines, USB host interface, etc?
Links in the github repo and associated issues.
I’d really love to see the Pinecone wifi/bluetooth reverse engineering project get so far as this. It’s all very cool stuff that pine have enabled but the phone is still pretty far from reliable as an enthusiastic enduser in my experience.
> The firmware isn’t fully open – a few parts remain closed.
To be more specific, *all* parts that make the modem actually be a modem remain closed. It’s an awesome project and having access to the application processor can be super useful, but saying “there have been open-source baseband projects before, but not many of them have reached this far” doesn’t make any sense at all, as this project hasn’t even started to tackle the area that projects like OsmocomBB have successfully worked on before and it doesn’t seem like it’s even going to start tackling it anytime soon.
You’re right about that! And I made sure to emphasize the “baseband is not open” throughout the article. What I meant by “reached this far” is not “level of openness”, but “actually developing an open firmware that a large number of people can make use of on the devices their own” – that is an outstanding achievement in my book. Glad I could clarify this.