thanks — oops, I missed the branch with the make-it-compile fixes 
I needed to add a few extra modifications because there were still more warnings treated as errors, probably because I had a different GCC version (aarch64-linux-gnu-gcc Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)
I added the patch with the changes 0001-suppress-warning-that-are-treated-as-errors.patch.not.a.pdf (4.7 KB)
(renamed to pdf to allow uploading, its txt 
)
stupid question, how do I unlock the bootloader on FP3?
I tried to allow OEM unlocking in the developer options, as suggested by Wiki, but I get this:
If I put on my tin foil hat and read about “alternative operating systems for the fairphone”, then maybe Fairphone disabled the possibility to unlock the bootloader and will only come up with new possibilities later (Google’s long arm?).
Mine’s been unlocked from the first minute in my hands, so maybe I can test something for you?
I contacted support, but its still holidays, so no reply yet.
What I wanted to try - without flashing anything yet - was just to override kernel, dtb and kernel commandline for a single boot using a fastboot command.
If you managed to compile the kernel, as above, can you try if you can boot into it at all with something like
fastboot boot arch/arm64/boot/Image.gz --dtb arch/arm64/boot/dts/qcom/sdm632-ext-codec-mtp-s4.dtb
note, NO flash command, it’d be a smart idea not to flash anything to the phone’s partitions before testing it in one-shot mode
this should - if it works - boot the phone up into the default android system, but using the self compiled kernel.
if that works, as a next step I’d try
fastboot boot arch/arm64/boot/Image.gz --dtb arch/arm64/boot/dts/qcom/sdm632-ext-codec-mtp-s4.dtb --cmdline “init=/bin/sh”
to try to just run a shell instead of android.
this likely will result in a blank screen (but if you’re really lucky, the kernel has a working framebuffer console. then you could connect a keyboard via a USB-C OTG cable and browse the file-system)
if there was no framebuffer console, maybe the kernel can be recompiled with one enabled, (make menuconfig) but its possible additional cmdline options need to be supplied to setup the screen correctly
once you have a shell, the next step would be to compile a ramdisk image with busybox or similar and an ssh server, wifi support (wpa-supplicant) etc, to have a working linux to play.
from there its a very small step to a working ubuntu image or similar.
ok, the --dtb commandline option doesn’t work, fastboot complains about the option not being valid for “version 0” boot images… - back to square 1
the fact the sourcecode had to be patched to allow compiling dtb’s the phone isn’t using suggests that for the real thing, only the correct dtb gets compiled, so I still think only one dtb is to be included in the image. I’ll play around with that a bit.
big shoutout to @_tmp for supplying the script to generate the bootloader unlock code in Oem unlock "input verify code" 
I remembered now another thing so your extra warning patch isn’t needed (I’m guessing gcc-wrapper.py complained about disallowed warnings):
make -j9 CC=aarch64-linux-gnu-gcc
If you look into the Makefile you can see CC being set to CC = $(srctree)/scripts/gcc-wrapper.py $(REAL_CC) but you can override that by giving make the real gcc directly through make. I’ll adjust my post from before for that
I couldn’t get past the “dtb” not found. I am wondering if this could help:
apparently there is a particular boot image layout used by some bootloaders on qualcomm chipset devices using a separate header describing the dtb’s available and the supported chipsets.
i found that by following links from here:
that “dtbtool” can be compiled simply with “gcc dtbtool.c -o dtbtool”
it can be run succesfully with
export PATH=$PATH:[path-to-kernel]/scripts/dtc
./dtbtool -o dtbtreeimage [path-to-kernel]/arch/arm64/boot/dts/
if dtc is not in the PATH, it will fail to parse the dtb’s and extract the relevant qualcomm chip ids.
now I have the dtb table, but I don’t have a complete boot image yet (nor a way to load it without flashing, does anyone know if a boot image instead of just a kernel is even an option with fastboot? the forum entries suggest fastboot boot might work too)
To compile the kernel, I had to disable some warnings.
diff --git a/Makefile b/Makefile
index a12cc2722114..777d421cfdc3 100644
--- a/Makefile
+++ b/Makefile
@@ -654,6 +654,20 @@ KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow)
KBUILD_CFLAGS += $(call cc-disable-warning, int-in-bool-context)
+KBUILD_CFLAGS += $(call cc-disable-warning, attribute-alias)
+KBUILD_CFLAGS += $(call cc-disable-warning, sizeof-pointer-memaccess)
+KBUILD_CFLAGS += $(call cc-disable-warning, stringop-truncation)
+KBUILD_CFLAGS += $(call cc-disable-warning, stringop-overflow)
+KBUILD_CFLAGS += $(call cc-disable-warning, array-bounds)
+KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
+KBUILD_CFLAGS += $(call cc-disable-warning, packed-not-aligned)
+KBUILD_CFLAGS += $(call cc-disable-warning, missing-attributes)
+KBUILD_CFLAGS += $(call cc-disable-warning, misleading-indentation)
+KBUILD_CFLAGS += $(call cc-disable-warning, bool-operation)
+KBUILD_CFLAGS += $(call cc-disable-warning, bool-compare)
+KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized)
+KBUILD_CFLAGS += $(call cc-disable-warning, parentheses)
+KBUILD_CFLAGS += $(call cc-disable-warning, memset-elt-size)
It seems we can change the boot image header version created with mkbootimg
(https://source.android.com/devices/bootloader/recovery-image - and another interesting link: Boot Image Header | Android Open Source Project).
Note : I have bricked my phone trying to deal with the treble function (I have only access to bootloader). I can help to test things if needed. I hope I’ll have some images soon ^^.
Strangely, my boot image header version changed (without touching it) :
Argument dtb not supported for boot image header version 0
as far as i understand it, that “boot image header” is the header of the “bootimage” that the fastboot executable compiles on the fly when you use the “fastboot boot” command in this way.
(fastboot runs mkbootimg internally and compiles a header and a boot image from kernel, ramdisk, dtd and commandline, then sends the entire image to the phones bootloader which takes it apart again)
you can tell it to create a header version 2 with
fastboot boot --header-version 2
but I have’t been able to get around the dtb error that way either
Actually, it was an answer to this error :
fastboot can do both, it can “create” a boot-image on the fly from specified kernel, ramdisk, dtd (if using header-version>=2) and commandline in this case output will look like this:
fastboot boot arch/arm64/boot/Image.gz --dtb dtimage --header-version 2
creating boot image…
creating boot image - 27367424 bytes
Sending ‘boot.img’ (26726 KB) OKAY [ 0.835s]
Booting FAILED (remote: ‘dtb not found’)
fastboot: error: Command failed
or one can create one’s own boot image using mkbootimage
mkbootimg --kernel ~/src/android_kernel_fairphone_sdm632/arch/arm64/boot/Image.gz --dt ~/src/android_kernel_fairphone_sdm632/dtimage -o boot.img
fastboot boot boot.imgSending ‘boot.img’ (26726 KB) OKAY [ 0.878s]
Booting FAILED (remote: ‘dtb not found’)
fastboot: error: Command failed
I tried that both using individual dtb’s and compiled dtb’s using dtbtool, both with v2 and v3 dtb image version (I assume v1 is a flat single dtb) I also tried a flat concatenation of all dtb’s like the kernel make file creates.
So far I haven’t gotten past “dtb not found” – but if we had a working boot or recovery image from Fairphone (or offloaded from a phone somehow) we could analyze that to at least figure out which format the bootloader expects - and then figure out which dtb version we need
lacking any working images for FP3, I looked at the TWRP image for FP2.
This boot image uses a combined dtb image using dtbtool in version 2
trying to boot from it kinda unsurprisingly results in a “dtb not found” error
@z3ntu , where did you get the parameters for fp3 as in:
--base 0x80000000 --second_offset 0x00f00000 --kernel_offset 0x00008000 --ramdisk_offset 0x01000000 --tags_offset 0x00000100 --pagesize 2048
the TWRP fp2 image uses different offsets. I have no clue how important/critical those are.
You should rather compare images for other sdm632 devices (asus X01AD, motorola river, etc) than FP2 images
These are the addresses on moto G7 (same chipset)
interestingly the twrp image for the moto G7 has the device tree concatenated old school to the kernel image (using a single device tree file) but this might be depending on the bootloader used
the descriptor info says:
model = "Qualcomm Technologies, Inc. SDM632 + PMI632 MTP S3";
compatible = "qcom,sdm632-mtp", "qcom,sdm632", "qcom,mtp";
qcom,msm-id = <0x15d 0x0>;
qcom,msm-name = "SDM632";
interrupt-parent = <0x1>;
qcom,board-id = <0x8 0x3>;
qcom,pmic-id = <0x10016 0x25 0x0 0x0>;
channel-id-map = [00];
that matches the entries in fairphones sdm632-mtp-s3.dtb
however trying to load that (twrp) image results in (you guessed it) “‘dtb not found’”
just for fun I looked at (the TWRP image for) that one as well. It uses the same addresses as the motorola g7, but it has a whole bunch of dtb’s concatenated to the kernel image in binary, for a whole lot of chipsets (including the SDM632 with msm-id 0x15d and pmic-id = <0x10016 0x25 0x0 0x0> but without specifying and board-id)
so now we do indeed have all 3 variants seen in the wild 
Edit: and of course: “dtb not found”
I had a closer look at
https://source.android.com/devices/architecture/dto/multiple
and
https://source.android.com/devices/architecture/dto/partitions
its possible that fastboot ignores the device tree information in the boot image and instead looks for the images in the dtbo partition
fastboot getvar all
lists among others:
(bootloader) has-slot:dtbo: Yes
(bootloader) partition-type:dtbo_b:raw
(bootloader) partition-size:dtbo_b: 0x800000
(bootloader) partition-type:dtbo_a:raw
(bootloader) partition-size:dtbo_a: 0x800000
this could be a problem. Although the installed device trees would always fit the hardware, they might not fit the built kernel
the sources we have are for linux 4.9.112
but with the latest updates on the phone (2019-12-17) the stock android image is running linux 4.9.119 - incorrect - still on 4.9.112, must have been my eyes!
how hard is it to upgrade the kernel (assuming/hoping none of the fairphone specific patches got changed) ?
I’m still on 4.9.112 for 2019-12-17…?
Linux localhost 4.9.112-perf+ #2 SMP PREEMPT Tue Dec 17 14:35:21 CST 2019 aarch64
But anyways, I don’t think the dtb has changed and it would definitely be “compatible”. And I think dtb != dtbo but that might be completely wrong, I don’t know what the dtbo partition is really used for.