43

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?

humanityANDpeace
  • 13,722
  • 13
  • 61
  • 107
  • 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

2 Answers2

60

/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.

Ciro Santilli OurBigBook.com
  • 17,176
  • 4
  • 113
  • 99
4

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.

FRob
  • 181
  • 1
  • 6
  • 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 07: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