Partly yes. Some may possible to build from Android sources or sources from Qcom respectively. However I guess that many of them will only be available as binaries for whatever reason. Of course you could invest lot of time to reverse-engineer or convince Qcom to release sources 
@david-guillot:
Considering reverse-engineering: for fun I loaded some of these Qualcomm binaries into Ghidra and had a look at what they do. Most of the code is just boring glue code that translates requests to and from lower levels such as drivers. The really interesting Qualcomm code will likely be the firmware that controls radio/baseband and runs on a dedicated CPU core (modem partition)?.
Hm thanks for your answers @Max_S and @dk1978. My interest is less technical (I certainly won’t start a reverse-engineering adventure 
) than functional (I like to know what parts of my phone require proprietary blobs) and I see a quite huge list in proprietary-files.txt, but I guess it’s the usual…
And actually my real interest is: how to make your amazing work an official LineageOS distribution as soon as possible, in order to have it updated and to recommend it to friends who own a FP3 but just want to keep things simple. There’s probably a way for me to help (not on the tech stuff but on structure/documentation/communication/etc.) meeting Lineage requirements. I have never done that but if you tell me what are your views on going official and on what parts do you need help, I’d be glad to give it a try 
.
1 Like
Hi,
to cross-check if proprietary files are consistent, I’ve created a small script that checks if all specified files are there. That could help and warn if the proprietary-files.txt was changed or to avoid strange build issues (like on my PC … ).
After having a closer look on the proprietary files and switching to the WeAreFairphone repo, most of my previous issues vanished. The only thing that is not working so far is the earspeaker. That is weird as I see commints that should’ve fix it.
Does anybody else have issues with the earspeaker?
1 Like
That is a bit worrying. I know it sounds lame, but have you tried a clean build (wiping the out folder completely)? I have had issues with left-over build artifacts on configuration changes already. Example: the useless FM radio app kept landing in the build image until I deleted intermediate build products by hand.
Please feel free to open an issue on the Github repository so we can look into this in more detail.
1 Like
Is this a final technical verdict? …
Is this a final technical verdict? …
Not really. I am a software guy and I don’t know my way around the hardware internals of the FP3. If someone can demonstrate that an FM radio should be there and operational, we will get the app for it running. Until then, no point in including something broken. By the way- I have not seen any FM radio app in the stock FP3 system either.
1 Like
That’s correct, there is no FM radio App in Fairphone OS at the moment.
But the SoC has the capability, and FM radio was apparently included in initial specs that went out to resellers, only to be omitted in later specs, so there was speculation here from the start whether FM radio could be perhaps brought to life via software somehow, or whether there was still hardware missing, e.g. some antenna wiring … see the topic I linked to.
I think most LOS ported devices still include vendor binaries. As you stated, this is pretty usual.
Unfortunately I don’t know the requirements for an official LOS device, however there are some. E.g. there is a Wiki page describing how to add a device there. Furthermore I think that I read somewhere that there are some rules about maintaining the device tree.
Anyway first we need to get to a stable state before we can check to make it an official version. 
Usually the build scripts should complain if proprietary files are missing. I mean the extract script prints a message, but the build fails with an error then. At least this was my experience. Did you add some more checks in your script?
I randomly fell over this and posted my findings in the thread. However I also assume that there is a reason why they removed it from the stock firmware. And I totally agree to @dk1978 that we should remove it for now. To really make sure I think some hardware expert needs to check for that or maybe we can get some details on that from Fairphone themselves.
1 Like
Hey @michlx,
you have access to the UART, right? Do you see messages from the bootloader here?
I’m currently checking for flashing with TWRP. However it seems like bootloader rejects to boot the slot afterwards for some reason.
Could those repos be of help?
1 Like
The kernel repo interestingly has original commits from Arima in there (but also my fixup commit to make the dtbs build 
), so they got some (previously) internal git repo from Fairphone.
4 Likes
Seems like it was a cooperation / partnership this time https://twitter.com/gael_duval/status/1255567703089336320?s=19
Hi, sorry for the late reply. Good question, I sometimes run ‘make clean’, especially when I observe weird things 
. Make clean also seems to delete all contents of the out folder
Hi Max_S, I created that script as kind of integrity check. Strangely, I did not observe build errors. Though, I might have overlooked a warning somewhere. What kind of additional checks do you have in mind? I do not yet check the sha1sums, but that should be no issue to add.
Sure, the UART is still connected. I just need some time to prepare to record stuff again.
Above, in post 23 is a link to a gist that shows how it looks like and the lines that are necessary in the kernel config.
Just drop me a message what I can try for you.
Yes, definitely. I’ll try to build LOS with it. Looks really great, they have important security features enabled as well like Android-Verified-Boot and SELinux.
Good that Fairphone supported the development. However would have been nice if they had published some details about that. But hey, finally we have something available we also can build upon 
I’m not totally sure, but it also seems that they officially signed the /e/ images. Otherwise I would expect that locking the bootloader would make it fail to boot. However I never tried, maybe the bootloader doesn’t check the signature or supports certificate pinning or something like that. I’ll try to check for that.
4 Likes
Yes, maybe some integrity check with hashes etc.
The build stopped for me with an error message when files from proprietary-files.txt were not available.
Oh yes, and it looks like there is some output from the bootloader. Lines like that are interesting here:
[21:46:24:644] [1840] avb_slot_verify.c[1840] :[1840] 417[1840] : DEBUG: [1840] Loading vbmeta struct from partition '[1840] vbmeta_b[1850] '.␍␊
[21:46:24:644] [1850] avb_vbmeta_image.c[1850] :[1850] 226[1850] : ERROR: [1850] Hash does not match!␍␊
[21:46:24:644] [1850] avb_slot_verify.c[1860] :[1860] 539[1860] : ERROR: [1860] vbmeta_b[1860] : Error verifying vbmeta image: [1860] HASH_MISMATCH[1870] ␍␊
[21:46:24:644] [1870] ReadRollbackIndex Location 0, RollbackIndex 0␍␊
[21:46:24:644] [1870] avb_slot_verify.c[1870] :[1870] 417[1870] : DEBUG: [1880] Loading vbmeta struct from partition '[1880] system_b[1880] '.␍␊
[21:46:24:689] [1880] negative Offset (-64) converted to (0xbfffffc0) ␍␊
[21:46:24:689] [1890] read from system_b, 0x40 bytes at Offset 0xbfffffc0, partition size 3849453568␍␊
[21:46:24:689] [1890] StartBlock 0x5fffff, ReadOffset 0x1c0, read_size 0x40␍␊
[21:46:24:689] [1900] read from system_b, 0x740 bytes at Offset 0xbff5b000, partition size 3849453568␍␊
[21:46:24:689] [1910] LastBlock 0x5ffadb, ReadOffset 0x0, read_size 0x140␍␊
[21:46:24:689] [1920] ReadRollbackIndex Location 2, RollbackIndex 0␍␊
[21:46:24:715] [1920] avb_slot_verify.c[1920] :[1920] 157[1920] : DEBUG: [1920] boot_b[1930] : Loading entire partition.␍␊
[21:46:24:843] [2070] avb_slot_verify.c[2070] :[2070] 232[2070] : ERROR: [2070] boot_b[2080] : Hash of data does not match digest in descriptor.␍␊
[21:46:24:890] [2080] avb_slot_verify.c[2080] :[2080] 157[2080] : DEBUG: [2090] dtbo_b[2090] : Loading entire partition.␍␊
[21:46:24:890] [2100] avb_slot_verify.c[2100] :[2100] 232[2100] : ERROR: [2100] dtbo_b[2100] : Hash of data does not match digest in descriptor.␍␊
[21:46:24:890] [2110] system_b uuid: 68bc91e6-9723-e5d0-1210-96dcc78c4f05␍␊
[21:46:24:890] [2110] boot_b uuid: 813695bb-3859-9b75-5afd-a3eb6165e68d␍␊
[21:46:24:890] [2120] vbmeta_b uuid: 4617542d-6902-0abe-e740-2c209d448ea4␍␊
[21:46:24:933] [2120] State: Unlocked, AvbSlotVerify returned ERROR_VERIFICATION, continue boot␍␊
However I guess it is caused by vbmeta we need to build, maybe with AVB enabled. The /e/ guys did that, so hopefully we can adapt that. If still not working I’ll come back to you.
After some night hours I got LOS successfully building with the /e/ config. Some small changes were required, e.g. in extracting the binaries. Great thing is that I was able to flash it with TWRP from @k4y0z now. Seems like my expectation with the vbmeta image was correct. Checking the image from stock firmware, /e/ and my build one with avbtool it seems like the test key is used for all of them:
Public key (sha1): cdbb77177f731920bbe0a0f94f84d9038ae0617d
This would also explain why bootloader can be locked with it.
Ear speaker is again not working with it. I think most probably because they use a different qcom hardware branch. I’ll try to switch to that and build again tomorrow.
I uploaded the built package and the images to github. Maybe someone want to give it a try.
I think we should go with that config as a base from now. The /e/ guys did a great job. And this would also allow to sync between the repos more easily.
@dk1978 What do you think?
10 Likes
@Max_S:
I agree. From what I could judge, everything in the device tree looks clean and well thought through. The /e/ people obviously got some “inside” knowledge such as Arima code contributions that we can make use of.