I’m using L4T r35.3.1 and flashing an Orin NX device with the initrd flashing method.
The script tools/l4t_flash_prerequisites.sh installs the device-tree-compiler package containing dtc(1) from the apt repositories.
The BSP also comes with the device tree compiler at kernel/dtc, which is invoked during the flashing process. It is possible that this binary contains some Nvidia-specific patches.
What sources are used to produce the BSP’s dtc binary? Does it differ from the upstream package? Can I safely ln -sf /usr/bin/dtc kernel/dtc?
(If the binary is no longer needed, and if it is still included in newer releases, consider removing it. The included one does not work well under QEMU emulation on arm64 hosts.)
I can’t answer, but will provide a bit of information related to this.
The device tree compiler source comes with every Linux kernel. This is one of the possible kernel build targets. There are also compilers each distribution has as a package. For the most part none are different since the device tree blob itself is more or less architecture independent (I won’t say “completely” independent, but in many cases it will be).
Most computers running Linux will have some plug-n-play components which can “self-describe” when queried. An example is that all USB and PCIe devices are plug-n-play and have a description to reply with when asked what they are. Various hot plug type software systems will see this and tell drivers about the hardware, and then software will take ownership of that hardware. However, a large number of devices will not self-describe.
Those non-plug-n-play devices use a physical address somewhere on a hardware bus. It is up to other software to tell the driver that it is to work with some physical address. This is what the device tree does. Potentially, most drivers in the kernel source have some possibility of needing a device tree fragment which describes the driver and what hardware it might pair with. This is more or less passed to the driver as an argument as the driver loads. That information is not part of the driver, and in no way changes the driver itself, but since the kernel configuration is where drivers are picked, then it is also a convenient time to pick what device tree fragments are to be used.
The kernel’s Kconfig system is quite good, and if someone wishes to build the device tree based on the kernel’s configuration, then those fragments will be assembled together and compiled into a device tree binary blob after building the dtc itself. This is not necessary as one could build the device tree from anywhere at any time, but the presence of the dtc in kernel source is for this purpose of convenience and comes with all kernel source trees.
I usually just use the one on the system. If the kernels are far enough off between the host and the destination, then you might use the kernel one. The kernel version is guaranteed to be up to date with respect to that release.
Not everyone installs dtc on the local system, and not everyone is compiling kernels. Sometimes apps like QEMU need to be certain that a compiler exists which executes under some other architecture or cross-architecture, but the output is the same (only the execution environment differs).