tl;dr: We have the kernel, but we are missing crucial configuration information.
Try and error is not really an option because it can soft- or hardbrick the phone.
So we try to collect as many informations as possible to reconstruct these configurations.
(ofc it would be really nice of a fp dev to provide them to us, hint hint )
tl;dr: We have the kernel, but we are missing crucial configuration information.
@hirntot and any interested person willing for a summary in non-too-technical terms:
Just some clarification of the steps made so far…
Fairphone published (as promised) the kernel source code, but not yet the complete install image.
In this topic, a few people managed to compile the image properly and outside of the android’s build environment, but
having the kernel source code does not mean having a compiled and running kernel. If you are a Linux user, just go to kernel.org, grab the latest Linux release, compile and replace your existing kernel. If you are experienced it is fairly easy, but it is not a trivial thing to do. Now, when it comes to doing the same for a smartphone, it gets a bit more tricky. No one here actually managed to boot the compiled kernel on FP3.
The trick seems to properly package the compiled kernel into a boot image, and this seems to be very much device-dependent and it is not specifically documented for FP3. It is not possible to directly see how it is done on FP3 because there is no access on the phone to the relevant data without rooting the phone first (which is what people are trying to do here!). In order to break this vicious circle, corvuscorax proposed to
check automatic phone updates, and try to grab the boot image from them. The problem was that these updates would not provide the whole system in the phone, but just the differences between the system in the phone and the updated system; a lot of impressive work was done in order to extract as much information as possible from these differences, but nothing really useful was found so far (even though in a future update the full system might be provided, and we are ready for intercepting it if this happens). That’s why, meanwhile, it was proposed to
come back to the boot process, and try to understand what goes wrong. The problem is that there is a lack of debugging information during the boot process. Actually, debugging information is normally not conveyed through the screen when a smartphone boots, but often (and this is device dependent) through a signal across 3 pins on the motherboard.
That’s why Matombo took the initiative of soldering wires on his phone.That’s why pigpig took the initiative of probing debug pins candidates inside his FP3. It seems no one here has attemtped soldering anything yet .
To conclude with, if you wish to get rid of google on your phone/to have it rooted/to install a free OS on it, you have a variety of options:
- Wait till Fairphone actually does it (I really think they will, even though they have no obligation, but it will certainly take time)
- Wait till Fairphone makes a full image publicly available (I don’t think they have any obligation of doing it, but they promised to do so; it might also take some time, but less than the previous option)
- Do the whole work yourself from the published source code (that’s what is tried here, but see, it’s hard and not clear if it will take less time than the previous option)
- Wait till someone external to Fairphone does the job in hopefully less time than Fairphone (that is my strategy, trying maybe also to help a bit here and there when possible)
Anyhow, whenever there is significant progress, for sure you will know very quickly, even if you don’t read all posts in this topic. This is my bet: if you don’t see any new post here for 3 days in a row, then the custom ROM is running on FP3 .
hummm. I always thought, trying to run a TWRP build (without installation) and then just copying the /sys partition to another place might have been easier…
well, I guess TWRP needs some configuration as well, but I couldn’t understand what configurations when I tried to research it some weeks ago.
To boot twrp on the fairphone 3 you also need to be able to boot a custom kernel first. We are stuck at the step before porting stuff.
btw: again i didn’t solder anything on my fp3, i haven’t even opened it yet. pigpig did open it and messured debug pins (without soldering stuff to it).
I just ordered a usb type-c breakout board and try to see if the unused type-c pins are used for uart. But the adpter comes from china so it will arrive in 2week-2month.
Feel free to open another topic.
Please don’t get me wrong (this is not meant as an offense), but this is the “participate/Development” category. And if you read some of the (126) posts you’ll see most of them are really fitting in this category! So please let them discuss technical details here. I think it’s really great what some have already found out!
After I got such elaborate technical and promising (though unfortunately not fruitful) reply to the question about JTAG, I asked the same contact from support about UART.
The support person was again very helpful and forwarded the question. However they received this slightly unsettling reply:
- Debug UART is not accessible for customers
I interpret that as “There is a debug UART, but we don’t want you to know about it” – which doesn’t look promising regarding helping the community getting this phone opened up. Quite a contrast to FP2. I wonder why.
That probably means we best keep reverse engineering this piece of locked down hardware, as if it was an Iphone. Maybe we should start looking into root-exploits.
For people interested in active development this probably means its better to not install updates anymore for the time being, so you don’t get patched out of potential local privilege escalation vulnerabilities you might need later.
Not happy about this. Can’t blame the support, but not happy about this.
Edit: This actually increases the probability that we are on the right track with the solder pads.
TWRP is linux based and needs a device tree configuration to boot. (Basically tells Linux device drivers which periphery chip is connected to which pin/bus of the CPU)
Technically, we already have the device tree, - although its a bit cryptic - it came with the open source kernel, but the bootloader doesn’t accept it. Keeps saying “dtb not found” regardless what kernel and device config you give it. That’s also what you get when you try to boot TWRP.
Aside that only first generation FP3s are even unlockable without hazzle. Any updated phone needs a code, for which someone had to actually reverse engineer some of fairphones proprietary software extensions. Not exactly what you’d expect from a “fair” phone.
Pretty far from it. I doubt there’s a direct connection, but can’t rule it out either, as its a many layer board, traces could be routed all over the place
Back to the oscilloscope, if someone else can try, it would be nice. Since my device is bricked, it is not sure it was in the right phase & it can’t have the boot signal.
we don’t know for sure if the bootloader actually uses the debug uart. Looking at aboot sourcecode for a different phone, it can give more info about whats wrong over serial uart, but that’s an optional compile flag to actually enable that, it could be compiled without. (In which case the uart probably is a dead end)
the stock kernel however has uart enabled, so latestly when android boots you should see all the kernel boot messages on the osci/COM device.
whats the frequency of these peaks? I hope that’s not just a clock
Actually I wonder if it wasn’t only the sector freq… (If it was only in charging mode??)
well its nice rectangular flanks, that DOES look like a binary signal, not an artifact.
I agree for the signal.
It seems that the flashing program from qualcomm (hXXps://www.qpstflash.com/) (link changed as site is very suspect, see below) is able to do some backup. Someone has a computer with Wind*ws and can check it?
Nobody tried the treble option to have an AOSP with su?? (just be carrefull with the slots -what I wasn’t-, I can give the cmds)
Sure that the site isn’t scam? It has a couple of red flags, like no legal information, bad grammar, encrypted zip files and implausible claims.
I don’t know. Someone gave this link on another thread. Search for qualcomm qpst flash
You should definitely not try it. A quick whois shows for qptsflash.com:
(Edit: you should at least be careful and aware that it does not come from an official source, see the next post)
Registry Registrant ID:
Registrant Name: WhoisGuard Protected
Registrant Organization: WhoisGuard, Inc.
Registrant Street: P.O. Box 0823-03411
Registrant City: Panama
Registrant State/Province: Panama
Instead, if you do the very same for qualcomm.com, you get:
Registry Registrant ID:
Registrant Name: Host Master
Registrant Organization: Qualcomm Inc.
Registrant Street: 5775 Morehouse Drive,
Registrant City: San Diego
Registrant State/Province: CA
These tools are usually not released by chipset vendors, at least not outside of a small group of qualified technicians. One of those sometimes leaks the tool, after which it ends up on some vague site on the net (packaged with or without malware). The tool for the MTK chipset in the FP1 also came from a shady source, if I recall correctly.
Rock / hard place.
This looks fishy. That tool, among a number of others are all listed on
https://androidmtk.com/download-qpst-flash-tool (scroll down to section “Alternative Qualcomm Flash Tool”
they all have different names, they all claim to be able to flash firmware for “any qualcomm chipset” - they all call it “download” when really they mean flashing a firmware onto the device, and they are all shady windows programs from shady webpages with zero other content.
I downloaded one of those zip files. automatic virus analysis failed because (what a surprise) the zip its password protected (with the password written on the webpage in cleartext) hindering automatic analysis
I went to the trouble and unzipped it, extracted the files from the msi installer and sent them to virustotal. No known malware was detected, but the heuristics went bonkers:
TL;DR don’t dare installing and executing that stuff unless you do it on a virtual machine running on a RAM disk on a battery powered raspberry in a sealed room with lead walls, and burn it afterwards. Connect your phone at your own risk, especially if its unlocked. If the malware is any good, it might actually install itself on your phone.
Edit: After snooping a bit more in the contents, it looks like there is some actual qualcomm tools in there, but they are from 2015 and likely don’t support the newer chips like the 632, so don’t get your hopes up too high.
Edit2: Since I didn’t want to upload every single file to virustotal for checking i re-zipped the unpacked folder (without password) these are the results:
while nothing specific has been found, I have to say, this does not look safe
btw if these “qualcomm downloader” tool were to work, then THIS here https://www.96boards.org/documentation/consumer/guides/qdl.md.html would work, too. has anyone checked that?
Edit: This uses edl modem this page describes how edl mode is engaged if available
Edit again: Neither adb nor aboot on the FP3 know anything about the “edl” which is likely because thats qcom msm based chipsets specific (which have that emergency bootloader hardcoded in the main cpu - great for unbricking!)
apparently there is even a special USB cable for these chipsets that shorts a pin to force boot the phone into edl mode - available from some forensic supply shops.
probably wont help us, as this is a USB2 cable and FP3 is USB3/USB-C - its possible that something equivalent exists for the SDM6xx series, but since qcom doesn’t release docu and there is nothing in the wild… the msm series had the advantage that there are dev boards openly sold and tools for download from qcom. while for the newer SDM those are only available for OEMs.
It seems like Fairphone the company isn’t even the OEM. The more I learn about the firmware and the device itself, it looks like Fairphone outsourced parts of phone design and manufacturing to a company in far east - which did the actual hardware design. As such the knowledge and NDA’s are between that company and qualcomm, while Fairphone is out of the loop and doesn’t even have that info about their own phone.
I don’t know that for certain, but there are indications, such as the Service Menu app, (com.arima.servicemenu) - it doesn’t include an “about” info anywhere, but this here might make sense:
another bit of info is the info from customer support that qualcomm NDA related info is not known to fairphone employees even. Which would totally make sense if Arima designed and certified the phone for Fairphone.