Fairphone 3 unbricking

Now that I think about it, when you dump memory, the UART buffer should also be in there somewhere.
I suppose you could grep for strings that are printed by aboot such as “Android Bootloader” to find it.

I assume you have an FP3 and you have already entered the EDL mode using the volume buttons? How exactly did you do? Was the timing so critical?

I don’t own an FP3 myself, we tested on @basxto’s device and it worked there.
@_tmp has also described a similar procedure here:

I never had timing issues when connecting for EDL mode:

  • First I powered the device down via the fastboot menu, in your case you might need to remove the battery?
  • Then I held both buttons and connected the cable without any hurry.
  • There is a short vibration directly after connecting the cable.
  • Then I let go of the buttons and started edl.py.

(I did this at least 20 times while trying different firehose loaders because after trying a wrong one the phone would not accept new commands but need a power cycle)

All issues with EDL I had were gone when I made sure ModemManager was stopped and qcserial was not loaded.

@basxto/@k4y0z : where did you find the working programmer? It doesnt seem to be contained in any of the repositories linked here in the forum.

Yes, I already saw the post. I suspect that the SBL is responsible for allowing to enter into EDL mode through the volume keys. I would guess that if the PBL does not manage at all to chain load the SBL, then it would put the phone in EDL mode automatically. Instead, if the PBL managed to chain load into the SBL, and the SBL does not manage to go on in any way for whatever reason, then one is stuck there.

Since I do not have any UART converter nor any good skills in soldering, your option to short either of the DAT0, CMD or CLK of the EMMC to ground while powering on would be great, but as you say it requires to locate any of these… so right now I’m a bit stuck :slightly_frowning_face:.

I’ll try meanwhile to understand what went wrong in the first place. So I extracted all relevant partitions with dd, I even flashed them back into both slots using fastboot (and all went very well and the phone booted on any of the two slots), and later on I packaged it into a TWRP zip-file. Before publishing that file I wanted to test it, which I did, and end up bricking my phone.

Originally I assumed we would need a programmer that is signed by Fairphone/Arima.
But since they didn’t burn in the PK HASH fuse, and therefore aren’t checking sbl1/programmer signatures any compatible programmer should work.
Since Xiaomi publishes their programmers and the Redmi 7 shares the same platform I found it in the Redmi 7 firmware package:

Did you try to find the UART buffer in the memory dump as I suggested?

If both slots were working previously, I don’t understand why it would not have just loaded the other slot after your failed flashing attempt.
Can you share the ZIP that bricked your device?

I’m still on it, the output of the dump is a bit cryptic to me, I’m parsing stuff with xxd trying to find meaningful strings.

Here it is: https://we.tl/t-uFx5vR1oB8. This is after packaging for TWRP. The images before packaging were working after flashing on both slots, and they are here: https://we.tl/t-UYd0maMW9e. Both files will be automatically deleted in one week.

I was suggesting to use something like this, to find the position of the UART buffer in memory:
grep -aob "Android Boot"

The files in your ZIPs all show up as sparse images:

aboot.img: Android sparse image, version: 1.0, Total of 768 4096-byte output blocks in 6 input chunks.
boot.img: Android sparse image, version: 1.0, Total of 16384 4096-byte output blocks in 3 input chunks.
cmnlib64.img: Android sparse image, version: 1.0, Total of 256 4096-byte output blocks in 2 input chunks.
cmnlib.img: Android sparse image, version: 1.0, Total of 256 4096-byte output blocks in 2 input chunks.
devcfg.img: Android sparse image, version: 1.0, Total of 64 4096-byte output blocks in 2 input chunks.
dsp.img: Android sparse image, version: 1.0, Total of 4096 4096-byte output blocks in 20 input chunks.
dtbo.img: Android sparse image, version: 1.0, Total of 2048 4096-byte output blocks in 3 input chunks.
keymaster.img: Android sparse image, version: 1.0, Total of 256 4096-byte output blocks in 6 input chunks.
lksecapp.img: Android sparse image, version: 1.0, Total of 32 4096-byte output blocks in 2 input chunks.
mdtp.img: Android sparse image, version: 1.0, Total of 8192 4096-byte output blocks in 118 input chunks.
modem.img: Android sparse image, version: 1.0, Total of 22528 4096-byte output blocks in 1276 input chunks.
product.img: Android sparse image, version: 1.0, Total of 32768 4096-byte output blocks in 9 input chunks.
rpm.img: Android sparse image, version: 1.0, Total of 128 4096-byte output blocks in 4 input chunks.
sbl1.img: Android sparse image, version: 1.0, Total of 128 4096-byte output blocks in 2 input chunks.
system.img: Android sparse image, version: 1.0, Total of 786432 4096-byte output blocks in 2589 input chunks.
tz.img: Android sparse image, version: 1.0, Total of 512 4096-byte output blocks in 14 input chunks.
vbmeta.img: Android sparse image, version: 1.0, Total of 16 4096-byte output blocks in 2 input chunks.
vendor.img: Android sparse image, version: 1.0, Total of 262144 4096-byte output blocks in 105 input chunks.

Which would explain, why they could be flashed with fastboot but not with TWRP, since fastboot will unsparse them.
However if you copied them with dd without further processing you should not have gotten sparse images.
It also doesn’t explain, why both of your slots didn’t boot.

Is it possible there is an issue with your volume-buttons, that could explain why you can’t enter fastboot or EDL?

Okay, so there we go then, TWRP flashed those images without unsparsing them, hence possibly corrupting all partitions.

I don’t believe the b slot ever got a chance to boot.

Correct, I converted them later. And now that you mention it, the images I flashed were the original ones, passing the parameter -S 522239K, which should first sparse the big images and unsparse them afterwards if I properly understood. I thought the same limitation applied to TWRP.

No, when I was booting in fastboot I was using them to navigate into the menu, and I definitely tested both of them and they worked.

Yes, although it should only have corrupted the active slot.

Under normal conditions, if both slots are marked as successful, it should automatically switch slots after 7 failed attempts.

Yes, that is what the option does. And sparse images are usually only used for the large filesystem-images, such as system, vendor and product.

Sorry, I did not read everything, but I’m quite certain that aboot catches the “both volume buttons pressed” situation, since I got output from aboot when that happened.
Aboot falls back to EDL mode if it crashes and I would expect SBL to do the same thing.

Yes, me too, but I am quite certain that the boot process never reaches aboot…

At the beginning the SBL partition was corrupted, and indeed the device would fallback into EDL mode. Actually I suppose it was the PBL bringing the device to EDL mode when it could not properly run the SBL. Then I flashed some of the partitions anew (namely aboot, rpm, sbl1, splash and tz for both slots a and b) in EDL mode, which were those available in the above-mentioned unbrick.zip. So now the SBL should be in a good shape, just as aboot, but I don’t think that the boot process ever gets into aboot. The SBL probably detects something is wrong and sets the device in memory dump mode instead of setting it in EDL mode. Then I am pretty sure that the volume-buttons combination is only caught by aboot and not by the SBL or the PBL.

Which leads me to the following question: do you think that the PBL/SBL would catch the “signal” set by a USB EDL cable? If not, my only option is probably that of k4y0z:

Regarding the UART buffer, I did not find it in the memory dump. I’m not even convinced that it is actually produced by the SBL. A grep of “Android Bootloader” (or similar, and also ignoring case) leads to nothing.

Any new ideas are extremely welcome :grinning:. And in the absence of ideas, a good guess of where the above-mentioned pins are could also be welcomed (but I would only try that as a very last solution).

I think you are right and it currently is loading sbl1, then loads aboot, which crashes for whatever reason.
UART seems to be disabled in sbl1, therefore you don’t see anything usefull in the memory-dump.
One more thing you could try is plugging in a charger, with the battery removed.
Then insert the battery while still connected and connect to PC and see, what mode it is in.
If you are going to try shorting, I’d probably start with testpoints that are close to the EMMC and CPU.

I, L and K seem like good canditates.

Could also be that the required points are under the metal shielding.

You can first try an “EDL-Cable” which is basically a cable that shorts D+ to GND during power on, here is a schematic:

1 Like

You should set up a fundraiser. I don’t have much money, but seeing how active you are in the FP3 root community (you basically are it), I’d donate to keep you invested in that.


I fully agree with CosmoSteve, I am amazed you could learn so much about it without having your own to play with.

I quite disagree in this part of the diagnostic, correct me if I am wrong. If the SBL was able to go as far as to load aboot, I should be able to enter the EDL mode by keeping both Vol+ and Vol- pressed, at least if I understand properly what is written in https://alephsecurity.com/2018/01/22/qualcomm-edl-1/:

We also encountered SBLs that test the USB D+/GND pins upon boot (e.g. Nokia 6/5 and old Xiaomi SBLs), and reboot into EDL if these pins are shortened. This is known as the EDL or ‘Deep Flashing’ USB cable. Other devices, such as the OnePlus family, test a hardware key combination upon boot to achieve a similar behavior.

If the SBL went as far as to load aboot, it would certainly have detected the Vol+/Vol- key combinations, shouldn’t it?

By the way, I tested also the EDL-USB cable trick, by shortening GND and V+ (and testing the cable with a multimeter). It did not work, but that did not surprise me either: if the SBL was getting far enough for this to work (assuming this trick is implemented), it would already have detected the Vol+/Vol- keys without any need of EDL-USB cable.

@k4y0z: there is still one doubt that subsists from my side. I checked the SBL in your unbrick zip (sbl1_a.bin and sbl1_b.bin), and compared it to the original file I had on my phone. Well, they differ. This could be due of course to some OTA update (I did none). Question: is the Vol+/Vol- combination normally working with the SBL you gave me? Where did you get it from? If someone still has that very same version on his phone (md5sum of sbl1: 1a1ecf739d7050341f39088b2b924493), I would be glad to know if that combination still works.

I have paypal, maybe I should add a link to my threads :wink:
Would certainly make things easier having one myself.

I am not sure anymore, I was under the impression that it was aboot that reboots into EDL.

@basxto and I did some tests today, including an EDL cable.
And it worked.
We’ve put the phone into the same situation you are in currently and it stopped working.
We did manage to bring it back though.
You need to short the points marked as L and K here:

We used an 1KΩ resistor for safety.
Also redownload the unbrick package, it includes more partitions that will get you into fastboot:

The image-files are from the 110 firmware.

1 Like

I’d like to give you a few handfuls of euros for the work you do for us. :slight_smile: Whether or not you buy a Fairphone for it, I leave it to you. However, it would be great if you could develop better.

In the end the Fairphone Open might be based on your work.

Wait, that’s not fair, many here are doing good work for the community. I would like to give you money to buy a Fairphone 3. It would be very nice if you would continue working on it, but that’s not a condition of mine.

1 Like

Are you crazy :scream:?!? Well, thank you so much! Testing shortening L and K pins was going to be my next step, but I wanted first to have a close look to these pins and the main board, and post some more detailed pictures for checking with you if L and K really looked like the right ones. Nevertheless, there was no point in trying to burn a second phone: mine was already in a situation in which there was nothing else left to do than testing.

I left behind a lot of stuff such as my multimeter, resistors, soldering iron… when moving out some time ago. Then testing electronics-related stuff is a bit slow for me: I need to find people to borrow the stuff. I’ll try to resurrect my phone when I get hand on a resistor: even if it worked for you I think it is still better not to directly shortcut two pins…

It seems it is possible to reboot into EDL at different stages. For me it was very instructive to read both https://alephsecurity.com/2018/01/22/qualcomm-edl-1/ and https://www.timesys.com/security/secure-boot-snapdragon-410/. The second link allows us to make a good interpretation of what happened when trying to unbrick the phone:

  1. The SBL, aboot, tz, rpm and splash were properly restored. However the other partitions remained corrupted
  2. When booting, the PBL checked the SBL, which was fine, properly signed, and accepted, and chain booted on it without going to EDL mode
  3. The SBL started verifying the authenticity of other partitions, including aboot, tz and rpm, but also lksecapp and maybe others, which were still corrupted
  4. Failing to do so at the SBL stage brings the phone to memory dump mode as a fallback, unlike the normal EDL fallback at the PBL stage when verification of the SBL is unsuccessful

I fully support the found raising idea :smiley:.

Well, we did that only after testing the EDL-cable, which did work before.
After that didn’t work anymore either, I couldn’t leave @basxto with a bricked phone :joy:

ifixit has some nice pictures of the internals:


As said, we did use a resistor as well.

I have read the first one a while ago, I’ll check out the second link, thank you.

Forget about checking the SBL, as we already established there is no signature checking done on SBL.

After your first unbrick attempt aboot, tz and rpm were all fine and I would have assumed that that’s enough to get fastboot.
Apparently more is needed for that, which is why the new unbrick-zip also contains lksecapp, keymaster, cmnlib(64) and devcfg.
devcfg was the last partition I added, after adding only lksecapp, keymaster and cmnlib(64) wasn’t working either.

Again, forget about the verification of SBL, that isn’t happening.

I’ll add a paypal link to my threads, unless you have a better idea how to do that…