Commonly for arm systems, device trees supply hardware information to the kernel (Linux). These device trees exist as dts (device tree source) files that are compiled and loaded to the kernel. Problem is that I do not have access to such a dts file, not even to a dtb file.

I have access to /sys and /proc on the machine and I wanted to ask if that would allow me to "guess the correct values" to be used in a dts?

Also potential answer could highlight additionally the aspect if the answer to this question also depends on whether the device tree interface was used in the first place (i.e. a dtb was created and provided to the kernel) instead of some more hacking "we simply divert from vanilla and patch the kernel so as to solve the device information problem for our kernel only"-solution?

  • Do you have access to the boot image? You could extract the device tree from there. I can help.
    – phk
    Oct 17, 2016 at 18:03

2 Answers 2


/proc/device-tree or /sys/firmware/devicetree/base

/proc/device-tree is a symlink to /sys/firmware/devicetree/base and the kernel documentation says userland should stick to /proc/device-tree:

Userspace must not use the /sys/firmware/devicetree/base path directly, but instead should follow /proc/device-tree symlink. It is possible that the absolute path will change in the future, but the symlink is the stable ABI.

You can then access dts properties from files:

 hexdump /sys/firmware/devicetree/base/apb-pclk/clock-frequency

The output format for integers is binary, so hexdump is needed.

dtc -I fs

Get a full device tree from the filesystem:

sudo apt-get install device-tree-compiler
dtc -I fs -O dts /sys/firmware/devicetree/base

outputs the dts to stdout.

See also: How to list the kernel Device Tree | Unix & Linux Stack Exchange

dtc in Buildroot

Buildroot has a BR2_PACKAGE_DTC=y config to put dtc inside the root filesystem.

QEMU -machine dumpdtb

If you are running Linux inside QEMU, QEMU automatically generates the DTBs if you don't give it explicitly with -dtb, and so it is also able to dump it directly with:

qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine dumpdtb=dtb.dtb

as mentioned at: https://lists.gnu.org/archive/html/qemu-discuss/2017-02/msg00051.html

Tested with this QEMU + Buildroot setup on the Linux kernel v4.19 arm64.

Thanks to Harry Tsai for pointing out the kernel documentation that says that /proc/device-tree is preferred for userland.

  • 2
    @AnthonyD973 The ABI docs take the opposite position: Userspace must not use the /sys/firmware/devicetree/base path directly, but instead should follow /proc/device-tree symlink.
    – Harry Tsai
    Mar 31, 2021 at 19:12
  • @HarryTsai I stand corrected ; thanks a lot! I've deleted my other comment to avoid confusion. Mar 31, 2021 at 21:04
  • 1
    /sys/firmware/fdt is the device tree blob file location Jan 11 at 13:42

I'm not sure if I understand you correctly.

If you're on a system that booted using a dtb, your device tree should be accessible inside debugfs.

You can also try the dtc tools by Pantelis Antoniou, they include fdtdump and fdtget that print dts from a blob.

If you don't have a device tree at all and did not boot boot from a dtb, then you'll have to go through the machine code yourself and add all device specific attributes and nodes to your dts. There is no "synthetic" device tree generated for such a boot. A starting point would be a similar machine or parent and then working your way system by system.

  • Thanks, to clarify. There is a chance that the dtb might be accessible through through the debugfs yet that would rely on CONFIG_DEBUG_FS in .config and even if set still on the mere whim that they actually used a dtb to start with, do I read this right? So with some "bad luck" they did neither and used some sort of direct kernel patching instaed of device tree interface, also right? So this would mean the last resort woult be machine code, given they violate GPLv2 and closesource the kernel, right? Feb 27, 2016 at 7:01
  • Yes and yes for the first two. Last, IANAL, but the machine arch/???/mach-???/board-???.c would contain the special devices present for a machine in older kernels. This should be covered by GPL and have to be available for a fee. Individual device drivers might be closed source, no violation there.
    – FRob
    Feb 27, 2016 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.