Actually applying a device tree to a TX2 depends on which release you are using. R27.1 is fairly simple, but later versions get more complicated. Even so, I’d highly recommend first updating to R28.2.1 if it is possible. There is quite a bit of improvement just going to R28.x.
On the other hand, if you want to see a human readable source code version of the existing device tree, then this will work (you might need to install package “device-tree-compiler”, i.e., “sudo apt-get install device-tree-compiler”):
dtc -I fs -O dts -o extracted.dts /proc/device-tree
The “extracted.dts” file is derived from the kernel’s current running configuration.
Within this file you will find a code block…I’m actually looking at R28.1, so it might differ, but here is an excerpt…
- Find "eth_iso_enable":
nvidia,eth_iso_enable = <0x1>;
- Note this is within the code block "ether_qos@2490000". Thus this is the ethernet controller at base address 0x2490000. In some cases there could be more than one controller, but for ethernet this is the only one.
- This is a name/value key pair entry. Somewhere, within the driver for ether_qos, there will be code which has a variable named "eth_iso_enable". When the driver sees this, it will fill the value in with "0x1". Instead, edit this to be "0x0".
- Multiple instructions exist for actually editing the right location and installing the edited code depending on release. The short and simple form of this simply recompiles the edited extracted code, followed by installing it. Here is the recompile:
dtc -I dts -O dtb -o edited.dtb extracted.dts
- Earlier releases allowed simply placing this "edited.dtb" binary format file in "/boot", giving it the right name, and editing the "FDT" key/value pair name to match in "/boot/extlinux/extlinux.conf". Most semi-recent releases alter this, and if you do it wrong, you may have to flash your system (or at least the device tree) before it will boot.
As alluded to above, instructions for actually installing this depends on details of the existing system. I very highly recommend first going to R28.2.1 unless you absolutely must stay with R27.1.
Once the same rootfs began to be shared between the TX1 and TX2 dealing with actually installing a device tree changed. Earlier boot stages began to look at the device tree prior to the file system being mounted…which meant that actual device tree content went into a partition instead of being in a file. Then more recent changes after that also adding a step to sign the content, and if the content is not signed correctly, boot would fail.
The L4T Documentation for the particular release has details of installing the edited device tree.
Note that you will also find comments on building the device tree from kernel source. The device tree is independent of building a kernel, so “make dtbs” in no way requires adding or editing the kernel itself…but values in the device tree are tied to the driver which uses those values, so the two ship together. You’d probably still want to configure the kernel to match your existing system before building a device tree, though I’m not sure it would matter (you’d copy “/proc/config.gz” to the kernel build root, gunzip it, and rename it as “.config” if you choose to do so).
In the case of instructions suggesting edit of “.dts” and “.dtsi” files in the kernel source, what happens is that several files are brought together and assembled as a single file…resulting in something very much like the extracted.dts you would have from above. There may be a minor difference in later releases because the early boot stages (e.g., CBOOT) may edit something before passing it on to the boot loader (and what the boot loader passes to the kernel is what the kernel reports).
As to the actual install, you should refer to the “Documentation” download of the particular L4T release you are using since there are differences in most versions. If it turns out that it refers to creating a device tree and then replacing one in the L4T driver package “Linux_for_Tegra/bootloader/” directory, then consider you could save an unaltered copy of that file, reverse compile it with dtc, edit the “0x1” to be “0x0”, recompile it, and use the edited version. You wouldn’t necessarily have to build from kernel source.
There are a lot of different possible device trees in the “Linux_for_Tegra/bootloader/” directory. However, just as an example, if it turns out the file named in the official Documentation is “tegra186-bpmp-quill-p3310-1000-a00-00.dtb”, then directions for edit would go something like this:
dtc -I dtb -O dts -o edited.dts tegra186-bpmp-quill-p3310-1000-a00-00.dtb
# Edit the "0x1" to "0x0" in "edited.dts".
# Recompile back to binary format (dtb):
dtc -I dts edited.dts -O dtb -o <b>new_</b>tegra186-bpmp-quill-p3310-1000-a00-00.dtb edited.dts
# Assuming you saved the original somewhere safe, just copy this over with the right name:
cp <b>new_</b>tegra186-bpmp-quill-p3310-1000-a00-00.dtb tegra186-bpmp-quill-p3310-1000-a00-00.dtb
# Follow the flash instructions for flashing only the device tree.
A huge word of caution: There are some flash operations which won’t destroy your rootfs. There are many more such operations which will destroy the rootfs. If you have anything of value, then clone first. Some clone information:
https://devtalk.nvidia.com/default/topic/1000105/jetson-tx2/tx2-cloning/
Note that some bugs existed in the cloning in earlier releases…and the flash.sh script might need edit to support the clone. Later releases had flash.sh fixed. A clone will produce a “backup.img.raw” file, and also a “backup.img” sparse file. The sparse version can be used only as the source of a rootfs during a flash…it can never be edited, examined, or used in any other way. The raw version is far more useful. If put in the L4T driver package directory “Linux_for_Tegra/bootloader/”, using the name “system.img”, and if all flash operations use the “-r” option to “reuse” the rootfs, then you will always be safe…if it turns out the rootfs is overwritten, then it will overwrite with an exact duplicate of itself. The “raw” or “sparse” format doesn’t matter…if the name there is “system.img”, then the flash tools will understand the difference and work correctly…but the raw file is much larger and will take longer to copy or flash with.