@karsten One thing that would help me is an explanation why the bootloader refuses to boot my custom boot.img with FAILED (remote: 'dtb not found').
I know there’s a dtbo partition but I don’t know inhowfar that’s used by the bootloader.
I’ve built the kernel using the msm8953-perf_defconfig, and put the built Image.dz-dtb with a custom ramdisk into a boot.img made with mkbootimg (parameters: --base 0x80000000 --second_offset 0x00f00000 --kernel_offset 0x00008000 --ramdisk_offset 0x01000000 --tags_offset 0x00000100 --pagesize 2048) and tried to boot that with fastboot boot boot.img but the error from above gets returned then (I’ve also tried flashing it to boot_b and setting the active slot to B but it reboots to the bootloader - probably because of the same issue).
A quick peek inside msm8953-perf_defconfig reveals the following option set:
CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE=y
I think this means the kernel expects the DTB to be directly after the kernel binary rather than at a location provided in r2. If the bootloader doesn’t append it for you, you may wish to boot the image.gz-dtb file that is created during kernel compilation. … Okay, and as I research the problem I parse your post better. 
Perhaps you need to set the BUILD_ARM64_APPENDED_DTB_IMAGE_NAMES kernel configuration option to select the DTB file you wish to append?
Hi everybody, so far I was able to reproduce the work of z3ntu. Unfortunately, I am stuck with the same error message ‘dtb not found’. I’ve tried to use the kernel config from the device as well as msm8953-perf_defconfig.
I feared as much when I first looked at the kernel source tree.
I wrote a quick summary here:
has anyone tried to compile a .dtb from either of these configuration files? is it possible to extract the dtb (and compare) from a vanilla phone/factory image?
I had another look.
in the kernel diff,
among others, the following dtsi got changed:
arch/arm64/boot/dts/qcom/sdm450-pmi632-mtp-s3.dtsi
this is used only by 5 dts files:
sdm450-pmi632-mtp-s3.dts
sdm450-mtp-s3-overlay.dts
sda450-pmi632-mtp-s3.dts
sdm632-mtp-s3.dts
sdm632-pm8004-mtp-s3.dts
as well as one include file:
sdm632-ext-codec-mtp-s4.dtsi
the latter is used by:
sdm632-ext-codec-mtp-s4.dts
sdm632-ext-codec-mtp-s4-overlay.dts
sdm632-pm8004-ext-codec-mtp-s4.dts
pm8004 is an audio power amplifier chip, however other parts of the source code as well as https://www.ifixit.com/Teardown/Fairphone+3+Teardown/125573 suggests FP3 uses the Awinic AW88980 as power amplifier, which kinda rules the pm8004 dts files out
also ruling out the sdm450 and sda450 dts files (wrong processor), this leaves:
arch/arm64/boot/dts/qcom/sdm632-mtp-s3.dts
arch/arm64/boot/dts/qcom/sdm632-ext-codec-mtp-s4.dts
as well as
arch/arm64/boot/dts/qcom/sdm632-ext-codec-mtp-s4-overlay.dts
if you look at the files, the first 2 dts file specify supported chips, while the “overlay” skips this, other than that they are identical
the only difference between s3 and s4 is that s4 includes
sdm632-ext-audio-mtp.dtsi
which enables wcd9335 “tasha-sound-card” support.
This source file https://github.com/FairphoneMirrors/android_kernel_fairphone_sdm632/commit/c97c17e2a9f60efa13757067c505add89d734616#diff-36561f03a3a2d64e213781ef313387a7 highly suggests that this chip is present.
As such, I would suggest compiling the dtb for
arch/arm64/boot/dts/qcom/sdm632-ext-codec-mtp-s4.dts
and
arch/arm64/boot/dts/qcom/sdm632-ext-codec-mtp-s4-overlay.dts
and see if either of them boots.
Btw, can anyone link a tutorial to me how to crosscompile an android kernel and try it out?
Yes but there are no factory images released, so I don’t have access to a stock boot.img.
The stock kernel config has the option CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE=y set which basically takes all compiled .dtb files and appends them to the zImage. Then the bootloader picks out the dtb it needs based on qcom,board-id and other similar properties; and as far as I understand the problem that a self-compiled kernel doesn’t boot is that the dtb the bootloader exists isn’t present in the sources (but I might be wrong there, it’s my current interpretation 
)
Take this branch: https://github.com/FairphoneMirrors/android_kernel_fairphone_sdm632/commits/compile
Download some cross compiler for aarch64/arm64 (e.g. from Linaro or from your Linux distribution - on Arch Linux it’s the package aarch64-linux-gnu-gcc).
Then run something like
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make msm8953-perf_defconfig
# override CC= in that command so gcc-wrapper.py doesn't run and find 'disallowed warnings' that we don't care about
make -j9 CC=aarch64-linux-gnu-gcc
If you have downloaded the cross compiler you maybe have to adjust the CROSS_COMPILE variable so the gcc binary is named ${CROSS_COMPILE}gcc, and also adjust your PATH variable so that the folder where your binaries are are in your PATH.
I’ll give that a try.
From https://source.android.com/devices/architecture/dto I understood that you need to include only a single .dtb - the correct one, but I haven’t really figured out how the bootloader figures out the dtb blob address to tell the kernel, especially when sideloading a kernel without actually flashing. I assume including just one dtb into the kernel image itself (before the ramdisk) might be the way to go. I’ll play around a bit.
which compiler (gcc version) are you using to compile the fairphone kernel? I tried both a stock cross compilation GCC (ubuntu, gcc-7) and the cross compiler that comes with android studio (4.9 based)
I run into the same error every time:
drivers/bluetooth/btfm_slim.c:26:10: fatal error: btfm_slim.h: No such file or directory
#include <btfm_slim.h>
btfm_slim.h is in drivers/bluetooth so replacing the braces in #include with
#include "btfm_slim.h"
fixes this, but there are other, similar instances, including one where the include comes from a trace file macro
Use the branch I’ve linked above (named compile), I’ve fixed those errors there. These errors are because the kernel is compiled in-tree or something (“not compiled with the Android build system”). But if you came that far, your compiler should be fine
Anyways, I’m using that:
aarch64-linux-gnu-gcc (GCC) 9.2.0
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: https://source.android.com/devices/bootloader/boot-image-header).
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