You may want to look at the online version of the documentation (also downloadable in the R32.3.1 page):
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3231/index.html
This is more specific to a TX2:
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3231/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/adaptation_and_bringup_tx2.html
If you have the correct tree installed in the R32.3.1 flash software on the host PC, then it would go something like this:
sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1
R32.3.1 has introduced some new ways of making updates via “apt”, and I do not know how this may change things when a new release is out and being updated by “apt” instead of by flashing.
Most people would probably start with the PINMUX spreadsheet to create a tree if they are building a new custom board, but the tree itself can be edited and reflashed with edits. If for example you found a specific “.dtb” file in the flash software which you know is the one containing your needed edits, you could instead convert that to source, edit the source, and then recompile it back to binary with only a few changes (versus starting from scratch).
Do know that boot looks at the device tree in earlier stages prior to reaching U-Boot, and that this is edited, followed by passing it on to U-Boot in edited form. What you extract from a running system may be slightly different than what you see in the L4T flash software on your host PC since earlier stages would have edited the content prior to Linux seeing it. Newer releases also sign content, and thus the need to use the flash tool to install new trees instead of simply putting a file somewhere in “/boot”.
If you have questions on a specific step you can always ask. One thing you can do (if you don’t mind flashing removing your root filesystem and replacing it with a default image) is to flash the TX2 once and keep a log of the flash. To do so, from the “Linux_for_Tegra/” directory of the flash software on the host PC, after setting up for flash:
sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | gawk '{gsub("[0-9][0-9]+[/][0-9[0-9]+ bytes sent..",".");print}' | tee log.txt
(the “gawk” part reduces the size of progress bars in the log)
Then go to that log and look for any references to “.dtb”. You’ll be able to confirm the exact files used. You can then convert that file to source, e.g., with contrived file names, like this:
dtc -I dtb -O dts -o tree_to_edit.dts some_original_tree_name.dtb
# Edit the "tree_to_edit.dts", back up the "original_tree_name.dtb", then:
dtc -I dts -O dtb -o edited_tree.dtb original_tree_name.dtb
cp original_tree_name.dtb /where/ever/the/log/said/the/file/is/flashed/from.dtb
# This is just for device tree flash, but you could flash the whole install as well.
sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1
Even so you will have to probably make adjustments depending on what you are changing.
If you want to clone prior to a flash, then something like this with the TX2 in recovery mode:
sudo ./flash.sh -r -k APP -G my_backup.img jetson-tx2 mmcblk0p1
…which would produce a large file, “my_backup.img”, and a much larger file, “my_backup.img.raw”. It is the raw file which you can examine and edit…the sparse “.img” file can only be used for flash. I throw away the sparse file and keep only the larger raw file. When storing I use “bzip2 -9 my_backup.img.raw”, but beware this is an enormous file and you’ll want significantly over 32GB of spare host disk space before you even think about doing this.