#12 was from an earlier release. Mostly #12 is correct, but there is now a device tree signing which makes installing a bit more complicated (if the dtb is not correctly signed, then the dd step will put a new dtb in which the system won’t accept).
Here is a general blurb on device tree operations, and although it was for a TX1 (file names will probably differ in some cases since they are a combination of base board name and carrier board name…or a subset thereof), it was for R28.2 and the R28.2 generic device tree information is the same as that of a TX2. You may find references to a patch to flash.sh, but R28.2.1 has this in place already.
Generally speaking, there is only one device tree. When looking at the files of the kernel source each file is just some subset. There is a “make dtbs” kernel target for building device trees, but beware there are also setup steps. It is usually much easier to just extract a device tree from the running Jetson as a whole. In the above URL you can search for this which explains:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
It is always worth saving a backup of this extracted device tree when you have a running system. You might want it for later reference or comparison to other device trees even if you never flash a device tree.
In cases where you see dd being used you must also go through steps to sign first. If you were to flash just the dtb on a TX2 (and let flash.sh do the signing) it would go like this if you have edited the existing dtb file from the driver package and replaced the one normally used for flash:
sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1
Depending on board you might find the right file to reverse compile, edit, and then recompile and put in place is this one:
(note there is also an “a03” variant of the “c03” file…I believe this is for older revisions)
Note that in theory (there may be exceptions) the file I just named is the one which actually created the current existing device tree (it is a fusion of pieces of device tree combined during a kernel build “make dtbs” where the config matches what your installed R28.2.1 TX2 is using). Restated, flashing with this dtb file is most likely the same as doing nothing on a TX2 with R28.2.1. An equivalent command to the first one flashing the kernel-dtb would specifically name that file:
sudo ./flash.sh -r -d ./kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb jetson-tx2 mmcblk0p1
Reverse compiling tegra186-quill-p3310-1000-c03-00-base.dtb, editing this, and then recompiling is probably the route I would choose for your case (your device tree is not customized).
A word of caution: The “-r” option says to “reuse” the rootfs’s system.img. In some cases the result is that you just flash the dtb and the rootfs is never touched. In other cases, this results in not generating a new rootfs, but still flashing based on what is already in “bootloader/system.img”. You are advised to back up any rootfs before you experiment (I think the above will leave your rootfs alone, but I won’t guarantee it). If you are interested in cloning, then see this:
As mentioned earlier, there was a patch, but this applied to R28.1. Your R28.2.1 does not need any patch to clone.
To emphasize something from cloning: Both a “backup.img” and “backup.img.raw” are generated. You can’t do anything with “backup.img” other than restore with it. I delete my “backup.img” and save “backup.img.raw”. This latter file is very large, but can be loopback mounted, examined, edited, and used for flash (a longer flash versus backup.img since it is larger).
If you ever want to log an operation from flash.sh or any command line tools of the “Linux_for_Tegra/” directory (which is what the driver package is), then just append this to the command (and I suggest logging any flash for help if something goes wrong):
2>&1 | tee log.txt
So for example:
sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1 2>&1 | tee log.txt