Skip to content

Instantly share code, notes, and snippets.

@z3ntu
Last active July 25, 2017 09:22
Show Gist options
  • Save z3ntu/b8f26642c947e71175a80c04b6ff3d17 to your computer and use it in GitHub Desktop.
Save z3ntu/b8f26642c947e71175a80c04b6ff3d17 to your computer and use it in GitHub Desktop.
arm kernel stuff (& qualcomm stuff)

fdt/dtb(I think they're synonyms) are just the default devicetree stuff for booting a kernel on ARM. but the thing is that a fdt is ONE fdt, and as you may know there are usually tons of them for all inds of hardware variants and the bootloader has to select the correct one

and there are two methods: appendet fst, where all fdt's are appended next to each other behind the kernel image

and qcdt, where all fdt's are packed together in a dt.img and indexed so the bootloader doesn't have to parse them to find the correct id's

Huge thanks to @m1cha for explaining this to me on Slack (I corrected some minor spelling mistakes)

FDT = Flattened Device Tree DTB = Device Tree Blob QCDT = Qualcomm Device Tree

Just to try an explanantion from a different angle: The device tree mechanism is an approach to fix "shortcomings" of the ARM architecture. In the x86 world all devices are discoverable. So the kernel can query the PCIe bus or the USB bus to know which hardware is present and loads drivers/modules accordingly.

In the ARM world it works differently: There is a huge variety between devices even though most of them are using the same basic components - just with a little bit variation. The device tree file enables the kernel to know about the present hardware (and some hardware-specific configuration, e.g. memory addresses).

Now for practical matters there is not much difference between a FDT and a "non FDT" kernel. You always need to present a device tree to the kernel but you can do that as a boot parameter (new uboot) or just "bake it into the zimage itself". The first method helps distributors such as bodhi because he can provide a single kernel image for multiple devices.

So what you choose to do is completely up to you. If you only care about one device no method is clearly superior. If you don't want to upgrade uboot, you have to use the "legacy" method.

And just for completeness: "in other words, can i describe a given piece of hardware in both FDT and non-FTD ways?"

Sort of. Old versions of the kernel (before 3.16?) required that all device configuration was hard-coded into the C source code of drivers. Newer kernel versions require device tree files for the kirkwoord hardware.

Source: http://forum.doozan.com/read.php?2,24656,24666#msg-24666

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment