Some URLs which are related, though perhaps not exactly what you are after:
- https://forums.developer.nvidia.com/t/topic/263834/16
- https://forums.developer.nvidia.com/t/topic/220390/8
A bit of a restatement of the above: The official documentation which talks about .dtsi files isn’t really talking about directly editing a device tree. The .dtb file is the compiled binary device tree, and the .dts file is the device tree source file. Device trees come in fragments, whereby one branch or leaf of the tree is its own little independent world related to one driver. The .dts or .dtb are just packages of fragments combined in one organized fashion.
If you have the dtc program (via “sudo apt-get install device-tree-compiler”), then you don’t need a .dtsi file to edit or modify a device tree. One can convert back and forth between source format (a .dts file you can edit) and binary format (the form used during boot).
A given device tree fragment can be thought of as arguments or environment to pass to a driver as the driver loads. For example, plug-n-play devices state what they are and where they are, but some non-plug-n-play device exists on a bus at a specific hardware address and the driver has no way to know how to find that device (or even that the device exists). Device trees provide that information. When a driver loads it can examine the device tree to see if there is a fragment compatible with that driver. If there is, then the fragment is consulted to find the device and for optional arguments to pass to the driver.
Long ago, one would have had to have had a different driver, or some source code to select different variations on using the driver if the same chipset were used for a device, but located at some different address. Or if the device could run at multiple speeds, then one would have needed a different driver for every speed. The device tree was invented to allow generic/abstract drivers which are independent of the arguments passed to the driver. Device tree does not modify a driver except by data.
When building a kernel one is selecting a list of drivers and features. Building the kernel itself (the Image file), or building modules (still part of the kernel and drivers, just dynamically loadable/unloadable), is actually unrelated to device tree. There is no need to put device tree content in kernel source. However, it is rather convenient to do so since you only need to provide device trees for drivers which you are building. The kernel configuration is a shopping list of features that might need optional arguments or environment passed to it during load.
When talking about a .dtsi file you are talking about properly escaped strings containing the content of one device tree node or fragment. If you enable a driver which uses that fragment, then building the device tree in the kernel simply concatenates all the fragments and turns it into a single .dts file. Then it converts to binary format (the .dtb file). That’s the long way of building a tree: Configuration a kernel and then building from that shopping list.
If you look at a device tree binary file (e.g., one in “/boot”), then you can easily convert it to human readable source. If for example the file is named tree.dtb:
# Create binary to source:
dtc -I dtb -O dts -o tree.dts tree.dtb
# You can now read and edit tree.dts.
# Or, Jetsons export the current device tree to "/proc/device-tree" (browse those read-only files).
# You can create a source file from the running tree shown in the filesystem:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
# Let's say you edited and now have "modified.dts". Convert it to binary:
dtc -I dts -O dtb -o you_can_boot_this.dtb modified.dts
I suggest you create a source file from “/proc/device-tree” like in the example above. Use an editor to look at it. Consider you can convert the source right back into binary format. It’s a simple file and files can be copied into place. The extlinux.conf FDT key/value pair is one way of naming a different .dtb file.
If you see reference to a .dtsi file, then someone is expecting you to configure a kernel to match your running system to pick the right features and drivers, followed by building the device tree target (the dtbs build target). The patch you might see is escaped so the build software can turn it into a device tree fragment and assemble all the fragments into a single file. It’s easier if you already have a file to turn it into source, edit, and turn it back into binary.