A couple months ago I started poking the modem, right after reading Lukasz's comments (https://www.pine64.org/2020/01/24/settin...nceptions/), because, you know, if we're going to have an open phone, let's at least get it as open as possible. With all the work others have done with the Kernel, Crust, cameras etc, nobody had touched the modem. And I'm a bit masochist, and way out of my league, but I though I might as well try and get as far as I could, so I might at least be able to ease the way for others to open this up a bit.

Megi found a way to unlock adb, so I started playing. My first findings?

Bootloader is locked. You can actually flash whatever you want, but when you try to boot it it will refuse to do it and you will get a bricked modem. Fortunately, Pine's hardware team left test points to start the modem in Qualcomm EDL/QDL mode, and you can use it to reflash the entire thing.

So here we go to unlock the bootloader. There's traces of quectel's Source code everywhere on the net, but funny enough all the source code released officially in their site is broken. So I picked up the pieces and started putting it toghether.

First things first, what can we do with the bootloader lock?
- Bootloader is Qualcomm's standard LK
- Signature check is done in LK, and LK is itself signed, and PBL checks it before allowing it to boot
- They used Qualcomm's test keys for signing it!
- There is some source code for the LK bootloader from Quectel's AG35 Modem out there

So, after getting the necessary qualcomm bits, decomposing some factory images to understand how sectools profiled the image and patching the NAND driver in LK so it can actually start it and look for partitions... we're in!

The bootloader source code is here: https://github.com/biktorgj/quectel_lk
I added two small things to it: Support for rebooting the modem into fastboot mode by using gpios, and support to booting to recovery from fastboot, that wasn't available before

Step 1 completed, bootloader unlocked. Now let's dive in to step 2: Booting something else
Now that we've got the device freed, we can begin checking out the rest of the stuff. Need to set the expectations first:
1. Not going to rewrite the ADSP code. I know nothing of how the hexagon DSP works. There's code out there for it, but no toolchains. Even if I could compile it, it probably wouldn't boot since all that code is tailored to the specific implementation in hardware, there's calibration, there is custom code bundled into the ADSP firmware by the vendor etc. We could spend years disassembling that thing without getting anywhere, so let's focus on what's achieveable
2. Even if there are numerous leaks of qualcomm's application level daemons (atfwd, qmi_qmux etc) we can't use that source. It's proprietary, and using it will probably get either me or Pine or both a C&D letter from Qualcomm's lawyers, and I don't want that for any of us
3. What can we do then? We can get our kernel running in the modem's ACPU, and we can have our own userspace, so let's get on to it

The Kernel:
The kernel shipped with the modem is version 3.18.20. Latest update leaves it at 3.18.48. The kernel is heavily patched, sometimes with some reasoning (MSM HS Serial driver), sometimes to fuck with their customers (lock the entire modem if you try to read some of the partitions), and sometimes just because (hijack the init process to pass an argument to one of the kernel modules).
I managed to get up and running a 3.18.140 CAF based kernel. I had to backport the audio and serial driver, and all the dts board files (the closed binaries expect some pins to have some specific names).
You can find the source here: https://github.com/Biktorgj/quectel_eg25_kernel/
Currently the kernel boots, and given the correct userspace it is capable of making phone calls (audio doesn't work though), and establish data connections (that actually works). I haven't checked power management, but thermal throttling seems to be working and the modem doesn't get hot at all if left alone. 

The userspace:
The userspace is based on OpenEmbedded. It is basically Qualcomm's provided old OpenEmbedded distro with some packages added on top by Quectel. The problem with this is that you need an old linux distro to build it, and packages, even if built from source, are old. I also didn't manage to actually build it, but didn't put much attention to it
I'm trying to make the work easy to replicate, so I'm using Yocto for the userspace. Currently using version 3.1. I've forked the meta-qcom layer to patch in support for the mdm9607, and slowly added bits and pieces for everything I could.
You can find the repo here: https://github.com/Biktorgj/pinephone_modem_sdk
Once downloaded, running 'init.sh' will download yocto, the bootloader, and all the layers and dependencies, and set a lot of things for you. You will still have to install the packages required by Yocto to build image, but if you have all of Yocto's dependencies installed, you will be able to run 'make root_fs' or 'make recovery_fs' and get a bootable image you can play with. Check the Readme in the repository to see what you can do (remember to first flash an unlocked bootloader or you will brick your modem and will have to jump start it with test points -https://github.com/Biktorgj/quectel_eg25_recovery-)

I've just scratched the surface of what can be done with the modem, but hopefully this will help others to get started quickly and get us an even more open phone. Feel free to fork everything, and any fix is welcome

I heard the term "Abandonware" used on here recently. Please say it isn't so! I really had high hopes for UT, it was by far the early pack leader, and still has the most promise but now just about every other distro has surpassed it since it seems development stopped here months ago. Now UT seems to be dust in the wind. Yes, there's daily OTAs, but it seems like each one is scheduled and just updates the "last updated" time/date on autopilot regardless of whether any dev work was actually done. I suspected early on UBports was slacking off because the financial incentive was dropped when Pine64 decided to release the subsequent batches dedicated to new dev teams, so maybe the only worked for the $10/phone for the UB ports CE phones? Some good work continued after but much slower. Yet here we are and nothing of value has been done for months (except helping Manjaro get Lomiri too perhaps).

The worst part is that their devs are never on here and never take feedback. Yes, i realize they have their own forum, but it's not intuitive or user friendly, and this is where the actual pinephone users are, so they should at least have a presence here.

I don't like being negative, but i'll light a spark if it gets something done. If anyone could kindle this flame under the logs over at UBports until they catch on... That'd be great! 

C'mon guys! I say this because i love you! Truly, UT is awesome, i really love your work. Please just get going and finish it!

If Luke or anyone else at Pine64 could pick up the phone and call the UBports team and give em a nudge, that would be Brilliant!

Whatever that means.... So Manjaro is now listing their next upcoming PHOSH build as a Beta! Sure sounds better than Alpha! Hopefully it will all be there. That said, im not sure what more to expect. It seems like everything has worked at one point or another and the last thing is for everything to work at the same time, and hopefully faster! Having said that i cant say the indication I've got is that it will be a significant leap from where we already are, but hey if they're confident enough to call it Beta, that will make it a pinephone first! 
I still think the Arch alpha seems slightly ahead however. Cant wait for Lomiri to reach Beta or 1.0

Whatever that means.... So Manjaro is now listing their next upcoming PHOSH build as a Beta! Sure sounds better than Alpha! Hopefully it will all be there. That said, im not sure what more to expect. It seems like everything has worked at one point or another and the last thing is for everything to work at the same time, and hopefully faster! Having said that i cant say the indication I've got is that it will be a significant leap from where we already are, but hey if they're confident enough to call it Beta, that will make it a pinephone first! 
I still think the Arch alpha seems slightly ahead however. Cant wait for Lomiri to reach Beta or 1.0

Does anyone know if Manjaro with Lomiri will utilize some form of Open Store? I'd guess there might be some intricacies with repos and whatnot, maybe a separate repo that clones the UBports openstore daily? Might need some file types to be converted too. Or maybe something similar, but different an native to Arch/Manjaro?

Does anyone have any success installing wine-stable on manjaro pinebook?
I tried with activation AUR and running it with pacmac without success. after a while it hangs up in the checking/cloning.


thanks,
Paul

purchased this pinetab + KB  out of curiosity as well as to support the great work being done by the Pine64 team. Packaged beautifully! Tab is of great quality...Will sell for $100+ shipping (cost me $147). I opened it up and after some tinkering and after the home page displayed get a "Move mouse to the right edge of the screen" and it is locked......   Let me know if you are interested.

has anyone successfully used Wi-Fi calling?

I know, that tracfone says Wi-Fi calling, but I have not been able to  successfully use it

To my knowledge VoLTE works for some carriers with the pinephone, but no one's been able to get Sprint to work with VoLTE. I've also been told that Sprint has started to only allow whitelisted devices. Is there any chance that Sprint will ever work with the pinephone?

Hello 

Has Pine64 considered supporting more SoC additional to Allwinner and Rockchip?  I understand you support open software and hardware.

Would consider Amlogic S905Y2, S905X3,, S922X SoC and making Pinephone, Pineebook development boards based on Amlogic, so software could be worked on?

Regards

Theguyuk