FP3 custom rom development based on released source code

Hi, it is already closed but I will try next time. Good idea to check for connections elsewhere :slight_smile:

1 Like

Hi, yes I soldered thin wires onto the pads and then closed the device. Now can measure without the need of four hands :slight_smile: . Currently I just can measure an analog signal since I do not yet have uart hardware for 1.7v signals yet.


The weird thing about that signal is the inversion. Why is the binary part between 0 and -1.8V but then jumps to +1V ? Is that an artefact of how it was measured? What was your used ground pin?

1 Like


Changing a few lines in the python script:

-		data += t[i*10+k] * 2**(8-k)
-	print(hex(data), ' ', end='')
+		data += t[i*10+k+1] * 2**(k)
+	print(str(chr(data)), end='')

Reveals the following:

Android Bootloader - UA

…I guess this is part of “Android Bootloader - UART_DM Initialized!!!” from


Please if you’re going to look at LK sources, at least look at ones from the correct chipset: https://source.codeaurora.org/quic/la/kernel/lk/tree/?h=LA.UM.7.6.2.r1-09200-89xx.0 (tag LA.UM.7.6.2.r1-09200-89xx.0) - something similar (but definitely at least slightly modified) is likely running as bootloader on the FP3.


Indeed, a very good question and I do not yet have an answer yet. It surprised me as well.
I abused one of the sim card housings as ground. All of them are connected to the R pin. There is a slight probability that I’ve measured between S & T but then I would expect a different signal then.
I just finished decoding the first two of the three transmissions (there seem to be bit errors in the third). I found two times 23 bit that look like garbage. However, start and stop bit are always matching. Weird …


Thank you very much for the hint!
I’ve miss-interpreted/programmed MSB and LSB. The code for the first part is already corrected.

Seems like we are now at the right place. Now is the time to build or buy a signal converter :slight_smile:
Tomorrow, I will try to boot my custom kernel and see if I see some messages that reveal why it does not boot / complains about dtb not found.


So far I got:

Android Bootloader - UA
RollbackIndex 0

The second one reads:

RollbackIndex 0

The third one reads (assumed start bit is two bits in) :

master64: is_unlocked:

This is the BESTEST news ever!

The string "Android Bootloader - UART_DM Initialized!!!\n" is printed by function uart_dm_init() in platform/msm_shared/uart_dm.c
The only place this is ever called is from within target/msm8953/init.c is:

void target_early_init(void)
	uart_dm_init(1, 0, BLSP1_UART0_BASE);

this in turn means WITH_DEBUG_UART was #defined at bootloader compilation, which in turn means:

dprintf(CRITICAL, <error message here>); within app/aboot/aboot.c
prior to call
fastboot_fail("dtb not found");

will result - via a call to dputs() in lib/debug/debug.c to

platform/msm-shared/debug.c : _dputs() :

	uart_putc(0, c);

The DEBUG level for these error messages is CRITICAL, so it doesn’t actually need to be a “debug” compile, as CRITICAL is identical to level ALWAYS

TL;DR: The exact reason why the bootloader is refusing the dtb (including possibly the mismatching chip ids - those in the dtb and those expected) will be printed out on this UART.

AKA Jackpot! That’s almost as good as having a sample boot image :slight_smile: Now all we need is a 1.8V UART converter.

Edit: I had a quick worry, because platform/msm_shared/uart.c defines an uart_putc() which actually writes to a different UART. But it seems we are fine, since both files, platform/msm_shared/uart.c and platform/msm_shared/uart_dm.c define that function. Neither of them is static, so the are effectively conflicting, there can be only one. And we already know that must be uart_dm since the string from its init() function is printed :slight_smile: So we’re good.

Edit2: at looking closer at uart_dm.c init() function, although there could be up to 4 uarts defined, and the “debug” uart is hardcoded to uart 0, the fact that the init funftion is only called once from one place (for that chip at least) should make us pretty certain, the UART found is the correct one (UART0). That being said, the other strings are also a good indication. I couldn’t find any of them in this source in their exact form, but similar strings show up in various dprintf’s. This means our aboot uses a different source, but it probably shares at least some code with it.

Edit3: In the entire aboot source the debug uart is the only uart anything is ever written to. And it’s always UART0 except for the Beagle platform which uses UART2. So we should be good.


coming soon, thanks basxto and k4y0z


Could you upload the partitions images please ! ? (at least, system, boot and vbmeta :slight_smile: )


If I understand k4y0z right, he will create a TWRP-thread - where you can get all the infos :wink:


Chaosmaster made backup of my partitions. So it should come some time.
He also patched the kernel with magisk and made a backup of that too.
So I probably have the first rooted fp3 now.
His Kernel needs still some fixups since he just commented out till stuff worked. Fastboot told the kernel to skip initramfs by default.
And my 3.3 UART adapter worked with the 1.7 signal


Wow, that is amazing. And maybe soon you had the first Fairphone with cusom android. :slight_smile:

It is a pity that Fairphone does not give a jump start here.


The speaker module is also a nice placeholder for mods.

Also with root everybody should be able to dump the partitions.


That’s right, with a smaller speaker you can do both. Or if the fingerprint module is gone, something else can go there.

A modular smartphone is great.


That’s great news. I’m looking forward to finally rooting the thing, no access to my own hardware sucks.


Hi guys,
here’s the full stock firmware-dump



More Developer badges, please @moderators :star_struck: