Hi, it is already closed but I will try next time. Good idea to check for connections elsewhere 
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 . Currently I just can measure an analog signal since I do not yet have uart hardware for 1.7v signals yet.
8 Likes
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
Hi,
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
https://android.googlesource.com/kernel/lk/+/qcom-dima-8x74-fixes/platform/msm_shared/uart_dm.c#381
6 Likes
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.
4 Likes
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 …
5 Likes
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
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.
5 Likes
The second one reads:
RollbackIndex 0
[3340]
The third one reads (assumed start bit is two bits in) :
master64: is_unlocked:
8 Likes
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)
{
#if WITH_DEBUG_UART
uart_dm_init(1, 0, BLSP1_UART0_BASE);
#endif
}
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() :
#if WITH_DEBUG_UART
uart_putc(0, c);
#endif
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 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 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.
16 Likes
<3
Could you upload the partitions images please ! ? (at least, system, boot and vbmeta )
2 Likes
If I understand k4y0z right, he will create a TWRP-thread - where you can get all the infos 
4 Likes
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
18 Likes
Wow, that is amazing. And maybe soon you had the first Fairphone with cusom android.
It is a pity that Fairphone does not give a jump start here.
4 Likes
The speaker module is also a nice placeholder for mods.
Also with root everybody should be able to dump the partitions.
5 Likes
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.
8 Likes
That’s great news. I’m looking forward to finally rooting the thing, no access to my own hardware sucks.
4 Likes
Hi guys,
here’s the full stock firmware-dump
https://androidfilehost.com/?fid=4349826312261709323
Enjoy!
20 Likes
More Developer badges, please @moderators 
10 Likes