Fairphone 3 unbricking

Participate Development
21

Have you blacklisted (and maybe unloaded) the qcserial kernel module as mentioned in the edl readme? Please check the end of dmesg after plugging in the device for anything related.

This module together with ModemManager can capture the device before you are starting edl.py and cause invalid modes. Maybe even stop NetworkManager as this will always restart the ModemManager.

I had somewhat similar issues when trying edl.py at the beginning while trying to find a working firehose programmer and I am using the ModemManager for the WWAN modem in my laptop.

1 Like
22

Disabling ModemManager is definitely a good tip!
I’ve had issues with other serial devices in the past.

23

Okay, there is maybe some progress. I tried on a different computer unsuccessfully, but then I tried to boot holding both volume buttons, and continuously holding them when invoking ./edl.py wl unbrick --loader=unbrick/prog_emmc_firehose_8953_ddr.mbn (which I did not do beforehand). I got this output:

flca3632@medeglia:/scratch/flavio/FP3/edl$ ./edl.py wl unbrick --loader=unbrick/prog_emmc_firehose_8953_ddr.mbn
Qualcomm Sahara / Firehose Client (c) B.Kerler 2018-2019.
__main__ - Using loader unbrick/prog_emmc_firehose_8953_ddr.mbn …
__main__ - Waiting for the device
__main__ - Device detected :slight_smile:
__main__ - Mode detected: sahara
Device is in EDL mode … continuing.
Library.sahara -
------------------------
HWID: 0x000ba0e100000000 (MSM_ID:0x000ba0e1,OEM_ID:0x0000,MODEL_ID:0x0000)
PK_HASH: 0xcc3153a80293939b90d02d3bf8b23e0292e452fef662c74998421adad42a380f
Serial: 0xadb2e024
SBL Version: 0x00000000

Successfully uploaded programmer :slight_smile:
Library.firehose - Nop succeeded.
Library.firehose - <?xml version=“1.0” encoding=“UTF-8” ?><data><log value=“logbuf@0x080795A8 fh@0x08076410” /></data>
Library.firehose - TargetName=MSM8953
Library.firehose - MemoryName=eMMC
Library.firehose - Version=1
__main__ - Supported functions:
-----------------
Writing unbrick/rpm_a.bin to partition rpm_a.
Library.firehose -
Writing rpm_a.bin to physical partition 0, sector 526360, sectors 1024
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Writing unbrick/aboot_a.bin to partition aboot_a.
Library.firehose -
Writing aboot_a.bin to physical partition 0, sector 917504, sectors 6144
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Writing unbrick/tz_b.bin to partition tz_b.
Library.firehose -
Writing tz_b.bin to physical partition 0, sector 532504, sectors 4096
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Writing unbrick/tz_a.bin to partition tz_a.
Library.firehose -
Writing tz_a.bin to physical partition 0, sector 528408, sectors 4096
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Writing unbrick/sbl1_a.bin to partition sbl1_a.
Library.firehose -
Writing sbl1_a.bin to physical partition 0, sector 524312, sectors 1024
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Writing unbrick/rpm_b.bin to partition rpm_b.
Library.firehose -
Writing rpm_b.bin to physical partition 0, sector 527384, sectors 1024
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Writing unbrick/splash.bin to partition splash.
Library.firehose -
Writing splash.bin to physical partition 0, sector 786432, sectors 22528
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Writing unbrick/aboot_b.bin to partition aboot_b.
Library.firehose -
Writing aboot_b.bin to physical partition 0, sector 923648, sectors 6144
Progress: |██████████████████████████████████████████████████| 100.0% Complete
Writing unbrick/sbl1_b.bin to partition sbl1_b.
Library.firehose -
Writing sbl1_b.bin to physical partition 0, sector 525336, sectors 1024
Progress: |██████████████████████████████████████████████████| 100.0% Complete

But then I released the buttons and unplugged the phone before doing ./edl.py reset, how bad would that be? The thing is that I still don’t get anything on the screen of my FP3, but something changed: with lsusb I now get Bus 001 Device 030: ID 05c6:900e Qualcomm, Inc.. But I don’t manage to go into fastboot mode.

The bad side of all that is that I can no more get the phone to go into QDL mode either. Any new idea?

24

05c6:900e If I remember correctly is memory dump mode.
It goes into that mode if i.e aboot crashes, though in that case you should still be able to enter fastboot by powering it on via Vol Down + Power
When you run
./edl.py --vid=05c6 --pid=900e
It will probably start dumping memory.
Take out the battery, put it back in and turn it on with Vol Down + Power.
If that doesn’t work, you should still be able to force EDL mode with both volume buttons.

25

It looks so, after ./edl.py --vid=05c6 --pid=900e and waiting some time I indeed get a message Done dumping memory. Yet, no combination of buttons seems to make it enter either fastboot or EDL. Also, it used to be that the device would appear in lsusb even if it was plugged without having the battery installed. Now it just does not do anything without the battery.

26

Try the suggestions here to reenter EDL:
https://zukfans.eu/community/threads/help-qualcomm-hs-usb-diagnostics-900e.138/post-1714

Apparently it is timing sensitive.

Specifically this:

Step 6 – Make sure you hold the phone in a way that you can comfortably press both volume buttons. Now press the Volume up (+) and Volume down (-) buttons simultaneously and connect the USB cable. The key of success here is timing. Make sure you press both volume buttons and the same time as pluging USB cable in.

If you cannot enter fastboot there may be more partitions that are required for it to work.
I have attached a zip, that also includes lksecapp, cmnlib and keymaster.
Use this, once you get back into EDL.
unbrick-new.zip.pdf (3.2 MB)

27

Thanks! Is there however any other way to get back to EDL mode? Have the magic JTAG pins been identified for the FP3? Or maybe someone tested with one of those EDL USB cables?

Playing with the volume buttons really does not work for me.

28

There is allways the option to short either of the DAT0, CMD or CLK of the EMMC to ground while powering on, so the PBL cannot access the EMMC.
You’d have to identify these first though.
I would try further with the volume buttons and different timings.
You could also attach a serial console, to find out what exactly is going on.

29

Can this be done through the USB, without any soldering?

30

Not that I know of.
UART TX is available at the point marked T here:

31

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.

32

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?

33

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:

34

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.

35

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.

36

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:
https://bigota.d.miui.com/V11.0.2.0.PFLMIXM/onclite_global_images_V11.0.2.0.PFLMIXM_20191022.0000.00_9.0_global_b0cd3cab92.tgz

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?

37

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: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free. This is after packaging for TWRP. The images before packaging were working after flashing on both slots, and they are here: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free. Both files will be automatically deleted in one week.

38

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?

39

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.

40

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.