There are two ways to do this. Because you are editing a “.dtsi
” file, which is an include header file of device tree source, and not the full device tree, this implies you are working with the kernel source and not with a full “.dts
” source file.
You should know that device trees are not technically part of the kernel, but each device tree corresponds directly to drivers which you might pick in a kernel configuration. The implication is that if you configure a kernel to match your running system, and then build device trees from that configuration, then you will have what you need for those particular drivers.
Drivers can read device trees and more or less use them as arguments to pass to drivers as they load, or to help find where the hardware is in physical address. Details for a specific implementation of hardware can be left out of the actual kernel source, and yet provided in a generic way to the kernel.
If you were to build a kernel, after configuring correctly, then you would use a command such as “make Image
” or “make modules
”. There is a less often used target, “make dtbs
”, and it is this latter which builds device trees. Technically you do not need to make Image or modules if you are configured correctly and prepared, but as an acid test I suggest you always run a “make Image
” once for a given configuration to see if it works, and then make whatever other target you are interested in.
Now if you happen to have a full device tree source file (a “.dts
” file), then you could use the device tree compiler (“dtc
”) to directly convert this. In fact, the kernel build has the source of dtc
, and when you “make dtbs
” this is one of the targets which executes prior to using the resulting dtc
to build trees. dtc
is generally available as a standalone application as well and quite likely if you’ve built kernels, then your system might already have this. The advantage of the one from the kernel is that it will always be compatible with the particular device tree source (this is not usually a problem, dtc
seems to be fairly lenient about releases). Try “which dtc
” to see if you have it. On Ubuntu (including Jetsons and hosts) you can install this separately with “sudo apt-get install device-tree-compiler
”.
In dtc
you specify a source format, a destination format, and file name in and out. dtc
can both forward compile (create a “.dtb
” binary) and reverse compile (create a “.dts
” source). A third form, which is related to the tree structure (which matches how a filesystem works), is “filesystem”.
- If you have an input file which is source, then “
dtc -I dts
”.
- If you have an input file which is binary, then “
dtc -I dtb
”.
- If you have an input directory tree (filesystem), then “
dtc -I fs
”.
- Similar for output forms, but “
-O form
”.
- Output file name with “
-o name
”.
- Input file name via the final argument.
Examples:
- Export your running system’s current tree:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
- Examine the source of “
tegra186-quill-p3310-1000-a00-00-base.dtb
”:
dtc -I dtb -O dts -o tegra186-quill-p3310-1000-a00-00-base.dts tegra186-quill-p3310-1000-a00-00-base.dtb
(which you could then edit and recompile)
- Convert
my_source.dts
to a binary, my_binary.dtb
:
dtc -I dts -O dtb -o my_binary.dtb my_source.dts
.
Note: If you know which dtb file is being flashed from in the “Linux_for_Tegra/
” content, then you could convert to source, edit, convert to binary, save original, copy replacement in, then flash. Recent releases might sign the binary before using it, so if you try to compile/decompile with a signature added, then likely you will get an error. Signing occurs on some content during flash.