As we know, the device tree blob is passed along from bootloarder to kernel at an early stage during boot. So the blob should be loaded into memory before the root file system is mounted.
So I am curious why there are a lot of *.dtb files are located in the /boot folder? In fact, I can delete all of them even delete the dtb in the /boot/dtb folder and I can still boot the Orin to multi-user mode. Just like this :
So my question is: why these dtb files are delivered while they are actually not being used ?
Another question is: when we build the kernel, we also build the dtb files with “make … dtbs” and this created all the blobs in the folder arch/arm64/boot/dts/nvidia including tegra234-p3701-0004-p3737-0000.dtb.
So how should these dtb files be used to update the system if I don’t want to go through flash process ?
yes, you may remove those unused binary file if necessary.
there’s feature to load device tree blob via file system. if you look into /boot/extlinux/extlinux.conf, you’ll see FDT entry to specify the path of the binary file, for example, FDT /boot/dtb/kernel_tegra234-p3701-0000-p3737-0000.dtb
if you don’t specify a FDT entry, it’ll load device tree blob via kernel-dtb partition.
Thanks for pointing me to the FDT entry. BTW, I wonder how to figure out what driver uses what dtb? such as tegra234-p3701-0002-p3711-0000.dtb, tegra234-p3701-0004-p3737-0000.dtb and tegra234-p3701-0000-as-p3767-0000-p3737-0000.dtb.
The dtbs are binary files. Is there any way that we can examine the contents just as we disassemble executable files ?
Device trees can be thought of as a way to pass options and arguments to drivers as drivers load for devices which are not plug-n-play. It isn’t just one driver. Often this will be content to describe a physical address of a device, a list of drivers, some options, so on. The naming of that file in this case is a combination of designations for the module itself, plus the designation for the carrier board (many of the devices being managed exist on the module, but many also exist on the carrier board…a merging of both results in a device tree).
If you don’t have the tool “dtc”, then you can install it with “sudo apt-get install dtc”. Incidentally, kernel source always has a version of this available in it. Many releases are compatible, but if there were a specific change, then the release which comes with your particular kernel would always work.
To decompile a device tree in binary format (a “.dtb” file) into human readable source format (a “.dts” file), or back, is easy. Here is an example taking one of your device tree file names as the input:
# decompile
dtc -I dtb -O dts -o extracted.dts /boot/tegra234-p3701-0002-p3711-0000.dtb,
# You can then edit and examine "extracted.dts".
# Now you might want to turn it back into a modified binary format:
dtc -I dts -O dtb -o modified_tegra234-p3701-0002-p3711-0000.dtb extracted.dts
# Or you might wonder what tree the running system is using since boot content
# can edit the dtb as it boots. That content is reflected in "/proc/device-tree". To
# extract that:
dtc -I fs -O dts -o extracted_from_system.dts /proc/device-tree
No device tree in any format is executable. It is all just a tree format of data being passed as an argument.
you may also check kernel logs, such as… $ sudo dmesg | grep DTS
it shows the dtsi file which actually loaded by kernel.
the “dtc ” utility mentioned by linuxdev is widely used. it’s helpful to review and debug dtb issues.
besides,
you may also # cat /proc/device-tree/ to look into properties to double check your device tree settings.
and… you may see-also developer guide, Device-tree overlay, there’s a feature to load DTB overlay file to configure the board dynamically.