@Maarten
I came across this kind of info during my previous job a few years ago. We first used a standard Raspberry Pi as a platform for an embedded Linux running device and were upgrading to a newer system-on-a-module platform that had linux support. However we ended up soldering that module on our own custom motherboard, which had a lot of periphery on pins different to the arrangement on the reference developer board that came with that system-on-a-module.
(manufacturers regularly sell those so potential customers can try out a module/chip before committing to buying a million of them - the reference boards usually have all sorts of periphery to showcase all the features of the CPU/module, often most aren’t needed for a specific application, and most embedded CPUs have their pins soft-wired and configurable - meaning the very same solder pad/pin can be USB, serial IO, a GPIO, I2C, connected to an sdcard, etc… and the bootloader needs to first configure the chip correctly to address whatever hardware is actually connected to it.)
I then had the problem of modifying the Linux image that the module manufacturer provided to work with our own hardware (similar to what Fairphone likely had to do with the reference image they certainly got from Qualcomm)
On X86 Linux doesn’t need to deal with any of that. The BIOS/ACPI framework (and it’s EFI successors) do it for you, and on X86, hardware can usually be addressed through known IO port addresses. (remember 0x3f8 for serial port? )
On ARM, which is much more configurable, and there’s actually CPU instructions to change what pin does what, Linux relies on the device tree framework to tell it which hardware is connected to which pin, and how that pin needs to be configured to work (and not fry that hardware or the CPU)
This sheds a bit of light on the topic:
https://elinux.org/Device-tree_documentation_project
Android so far uses a Linux kernel, and as such getting a self built android kernel to run on a phone (or any other ARM embedded platform) is no different from getting any custom linux to run. You need to tell it where it can find which hardware, and put all other pins into a safe state that won’t burn anything.
The latter is especially important when GPIOs (general purpose input output) pins are connected to high power Transistors that control current flow to and from components such as batteries, control FANs (you don’t want to overheat something) or are unused and hardwired to ground (in which case you don’t want to configure the pin to become a “driven”, active low output, because then it would try to apply voltage to a pin thats wired to ground, which causes a short inside the CPU. Not all embedded CPU’s tolerate that. (The datasheet of the CPU can tell you, it can usually be downloaded from the manufacturer, usually for free and public, but some idiotic manufacturers require to sign an NDA or even pay for that information)
A similar issue happens if the pin remains unconnected (open) but is configured as an “input” - because then its floating and can trigger IRQs and/or make things unstable.
A good board manufacturer will design a board such that all pins in their default (@bootup and uninitialized) configuration is safe, and most CPU’s will configure the pins in as benign a configuration as possible (input, active high with or without a high Ohm pulldown to prevent them from floating) but unfortunately you can’t rely on
that to be always the case.
Effectively, to be able to write the device tree from scratch, you’d need the data sheet and reference documentation from Qualcomm, and the circuit/connection diagram from Fairphone, which tells you what periphery is connected to which pin on the Snapdragon processor.
If you don’t have the circuit diagram, you can try to reverse-engineer it, by opening the phone (which luckily isn’t that hard) and figuring out which pin of the CPU is connected to what other component (as well as identifying these components and what the pins there do) - taking the data sheets for all these chips as reference - usually downloadable on the manufacturers webpage.
OR, since Fairphone has released the kernel source code, which includes device tree files, one can try to read out the information from there. I tried that but failed, because I couldn’t figure out which device tree configuration is actaully loaded on FP3
Is Fairphone’s circuit plan available?
More info: https://blog.modest-destiny.com/posts/linux-device-tree-pinctrl-tutorial/
I tried to find technical manuals for the Snapdragon CPUs, but it seems like Qualcomm is only giving those to OEMs signing an NDA. source
However I found documents for the Snapdragon 410e as well as 600 which can tell you what this documentation would look like, if it was available (will of course not be valid for the FP3s 632
Edit: I should add, (after reading them) these are technical data sheets about the whole family of chips. As such they describe general information (number of UARTs, device addresses, boot modes , power specs, in case of the 410e even programming examples) but they don’t tell you which pin is where on the CPU/MPU. The reason is that each MPU architecture is usually sold in different “packages” - aka different sizes of the chip with slight change in number of available pins, amount of internal memory, etc… it’s the same core architecture but differs in “options”
so you also need the manual for the specific version used on the FP3 (and I don’t even know which one that is, though the fineprint on the chip should usually tell - it should have series/family, model, hardware revision, and possibly serial number)
Edit again: Doesn’t apply here, actually there is Pad/PIN documentation in both, it’s just formatted badly
one problem (which becomes already apparent from the 600 technical manual linked above which has a lot of sections that say “will be included in future revision of this document”) the hardware life cycles in mobile technology have become so short and the chips so complex, that the manufacturers don’t even bother writing complete documentation anymore.
instead the code (hardware description language used to design the chip) and the driver code developed alongside it become the documentation.
so, worse comes worse, even if you sign an NDA with Qualcomm, the sourcecode that Fairphone has already published (although lacking instructions/docu) might actually all you’d ever get.
scary, isn’t it?
Edit: Found another one, for Snapdragon 820e - this one has specific pin/GPIO/pad information