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 '16 at 18:03

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

I think both are aliases, /sys/firmware/devicetree/base likely being the better choice after the taming of /proc.

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.

|improve this answer|||||

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.

|improve this answer|||||
  • 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? – humanityANDpeace Feb 27 '16 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 '16 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.