in a first step, it should be possible to make a very minimal linux, offering a serial console, able to mount partitions, inspect them, test hardware, etc…
the kernel is only half of the equation though, to boot linux from an arm system-on-a-chip you need a hardware-device tree specification for the particular motherboard/device the chip has been soldered on,
on a desktop PC that is not needed, as the BIOS takes care of it with its ACPI tables (which store which hardware can be found at which address/device tree path)
although some laptops have been known to have faulty ACPI tables which cause hardware damgae/bricking when linux was trying to address the hardware according to those wrong descriptors)
on any embedded device including phones, there usually is NO BIOS. There’s a bootloader, but that only loads the kernel, it doesn’t stay in the background and does low level hardware abstraction shit like the BIOS does on a PC historically
instead the kernel needs a binary device tree specification (DTS / DTB) file that tells the kernel drivers which hardware is connected to eachother in which way
systems on a chip can have many multi-purpose pins that could be connected to anything depending on how the board has been designed/soldered by the manufacturer. so for each motherboard a specific CPU is put on, you need the matching DTS
the DTS sources are part of the linux kernel, as such technically the fairphone linux kernel should include DTS files specific to fairphone3.
There are indeed DTS-includes for various fairphone specific subcomponts in the source (for example for various batteries
in
arm64/boot/dts/qcom/qg-batterydata-Fuji-3000mah-Jan22th2019-pmi632.dtsi
/arm64/boot/dts/qcom/qg-batterydata-Kayo-3000mah-Jan22th2019-pmi632.dtsi
arm64/boot/dts/qcom/qg-batterydata-mlp356477-2800mah.dtsi
GPIO pin control
arm64/boot/dts/qcom/msm8953-pinctrl.dtsi
audio:
arm64/boot/dts/qcom/msm8953-audio.dtsi
touch driver:
arm64/boot/dts/qcom/sdm450-pmi632.dtsi
the problem is, none of these actually specify exactly for which phone they are. Instead of making specific master device descriptors for fairphone3, it looks like existing descriptors have been patched to include fairphone3 specifics - but these are included by quite a number of board DTS files.
considering the fairphone3 has a Qualcomm Snapdragon SDM632 CPU, I would assume the correct device tree root file is either one of
arch/arm64/boot/dts/qcom/sdm632-cdp-s2.dts
arch/arm64/boot/dts/qcom/sdm632-rumi.dts
arch/arm64/boot/dts/qcom/sdm632-pm8004.dts
arch/arm64/boot/dts/qcom/sdm632-pm8004-rcm.dts
arch/arm64/boot/dts/qcom/sdm632-pm8004-qrd.dts
arch/arm64/boot/dts/qcom/sda632.dtsi
arch/arm64/boot/dts/qcom/sdm632-pm8004-cdp-s2.dts
arch/arm64/boot/dts/qcom/sdm632.dts
arch/arm64/boot/dts/qcom/sdm632-pm8004-ext-codec-mtp-s4.dts
arch/arm64/boot/dts/qcom/sdm632-mtp-s3.dts
arch/arm64/boot/dts/qcom/sdm632-pm8004-ext-codec-cdp-s3.dts
arch/arm64/boot/dts/qcom/sdm632-rcm.dts
arch/arm64/boot/dts/qcom/sdm632-pm8004-mtp-s3.dts
arch/arm64/boot/dts/qcom/sdm632-ext-codec-cdp-s3.dts
arch/arm64/boot/dts/qcom/sdm632-qrd.dts
arch/arm64/boot/dts/qcom/sdm632-qrd-sku4.dts
arch/arm64/boot/dts/qcom/sdm632-pm8004-qrd-sku4.dts
arch/arm64/boot/dts/qcom/sdm632-ext-codec-mtp-s4.dts
or neither and fairphone forgot to include it
the device tree specifications (.dts) are all compiled into a binary device descriptors (.dtb) when compiling the kernel
the correct one for a specific hardware is then stored either as part of the kernel binary (bzimage) or stored separately in the boot partition and given to the kernel by the bootloader. that way the same generic binary kernel can be used on multiple ARM devices, but on each it would need the correct device tree to work
on android this works like this:
https://source.android.com/devices/architecture/dto
loading the wrong one might misconfigure vital components and could brick the phone or make it go up in smoke (especially if hardware responsible for charging/discharging the battery is configured wrongly)
now on the phone there is already a compiled device tree file and a kernel, so maybe one can use this binary device tree spec to load a different kernel (compiled from the same sources) and use that to inspect it further to find out how exactly the hardware is configured.
but a bit of extra information along with the kernel sources (for example which device tree matches which fairphone3 build revision) would be really helpful.