Each carrier board has its own device tree provided by the manufacturer. The manufacturer would have to provide the information for that carrier board. I cannot give you enough details to actually do this, but some explanation follows.
Every driver in the kernel will tend to need some specific details about how to set up hardware. Let’s say you have a common chipset for a device. The driver will be the same on all systems, but details, such as the base address, will change depending only on how the device is wired into the board. If those details were part of the driver, then you would need a different driver or code in the kernel source for every single variation in existence. It was decided to instead keep the drivers generic, and pass the information needed to the driver as the driver loads.
The device tree is a unified method of naming arguments to pass to drivers or to the kernel during boot. Keep in mind that U-Boot is itself a kernel, and its only purpose is to overwrite itself with the Linux kernel, but it is still a kernel. One device tree might be for the Linux kernel. There can be a different device tree used in bootloader stages. Sometimes the device tree is loaded directly from Linux, and sometimes earlier boot stages might pass along the device tree (with or without editing).
The device tree and how it is changed depends on whether the bootloader stages need to see it or not, depends on which L4T release you are using, depends on any kind of secure boot options enabled, and probably a lot of other details. The simplest case is that a device tree is put in “
/boot” (see the “
.dtb” files there), and then the “
/boot/extlinux/extlinux.conf” names the device tree to use via the “
FDT” key/value pair. If this is the case, then you could place your device tree in “
/boot”, and simply name it via the FDT key/value pair.
In many cases it is not this simple. For example, not all releases of L4T had the ability to read an ext4 filesystem type. In that case the dtb must be in binary form in a partition (the driver can read the eMMC even if it can’t use ext4 formatting).
In cases of secure boot features, then not only must the dtb be in a partition, the partition content must also be signed by a key.
Content going into a partition requires using flash software (or “Jedi mind tricks”…in computer that’s “dd” tricks).
If flashing the content, then you’d have to put your dtb in the correct place in the flash software before flashing. Since you have a third party carrier board that information would have to come from ConnectTech. Basically it is the stock JetPack/SDK Manager software with their customizations on top of it.
Keep in mind that also, in some cases, U-Boot has some settings which cannot be controlled by device tree. In that case you would be required to actually edit the feature in the U-Boot source code, build a new U-Boot binary, and put that in place before flashing.