How to update device tree on TX2

Found a solution of DTB live update for R28.1 it doesn’t require going thru the flash process from a host.
[url]https://devtalk.nvidia.com/default/topic/1019936/jetson-tx1/jetpack-3-1-how-to-select-different-dtbs/[/url]

It’s for TX1 though. Not sure if it works for TX2 as well. Could anyone confirm?

Ideally, it would be nice to have the whole flow of extracting/patching device tree for TX2, such as the one on elinux.org for TX1: [url]Jetson/TX1 SPI - eLinux.org

hello tmx3,

here’s external wiki page to describe how to update the TX2 device tree. thanks
[url]http://elinux.org/Jetson/TX2_DTB[/url]

@JerryChang, thanks for the direction.

I checked out the instruction on elinux.org,

Replace your own build DTB with 

JetPack/3.1/64_TX2/Linux_for_Tegra_64_tx2/kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb


flash the DTB partition with 

sudo ./flash -r -k kernel-dtb jetson-tx2 mmcblk0p1

However it doesn’t provide the information regarding the source text for the DTB binary and the instruction to compile. Can you help to fill in the data?

Besides, any comment on linuxdev’s live-update approach? I believe the approach doesn’t require to flash the target from the host, if I understand it correctly. Apparently, using dt compiler and FDT directly on Jetson is convenient, particularly for debugging.

Hi tmx3,

If you want to update the DTB without getting into recovery mode, please refer to the “dd” method in this thread: How to use UART0 as normal uart port on R28.1? - Jetson TX2 - NVIDIA Developer Forums

For me, it worked. And it was verified by Arlen0615.

1 Like

It is sad that we have to use hacks like dd-ing the device tree into the mmcblk0p15 partition. These would stop working the second they add more things in that partition. I really hope nVidia brings back a simpler way to update out the device tree without needing a Ubuntu x86 host machine.

1 Like

Lack of a simple/quick way to update device tree is indeed a headache. TX2 is such a powerful intelligence supercomputer, and the dev kit has been made into be a complete system. Debug and trial-and-error are routine tasks in the development. Ideally, you’d wish not to hook up another computer and flash every time when a minor change is made to the code.

Camera module, for example, is a peripheral module. Frankly, I don’t understand why the driver has to be integrated into the kernel so that, in consequence, we have to recompile and reflash the kernel for different cameras. I’m still holding a hope that I might have missed the existence of easy ways to handle the addition of peripheral modules.

70% of engineering time is on debugging. Fellows would imagine you flash once when you are done with your coding. Well, it was never the case, unfortunately.

hello tmx3,

FYI, please refer to this similar topic that loading the camera module and get it works,
[url]https://devtalk.nvidia.com/default/topic/973087/jetson-tx1/error-compiling-ov5693-driver-as-module-on-l4t-24-2/post/5014011/#5014011[/url]

we’re looking another ways to update device tree without flashing the board.
thanks

Just want to resurrect this old topic. I hope Nvidia will put back support for loading device tree from file in the upcoming Jetpack release.

-albertr

Hi JerryChang,

any updates on alternatives to update the device tree?

hello Benjamin_Caro,

we’ll need to flash the DTB partition for updating the device tree on release 28.1
please check this external wiki page for reference: [url]https://elinux.org/Jetson/TX2_DTB[/url]
thanks

For 28.2, the update of the dtb as describe in Jetson/TX2 DTB - eLinux.org does not work.
I have decompiled the dtb in the tx2 located in /boot/dtb using

dtc -I dtb -O dts -o original.dts original.dtb

Made changes to the dev name for e3326 and compiled using

dtc -I dts -O dtb -o new.dtb new.dts

Copy to host and type (tx2 in recovery mode)

sudo ./flash -r -k kernel-dtb jetson-tx2 mmcblk0p1

After reboot, the /boot/dtb file does not change.

When compile system.img using

sudo ./flash jetson-tx2 mmcblk0p1

This updates the /boot/dtb files.

Does the dtb files in /boot get used?

Hi JerryChang,

having to use the flash.sh tool to update the device tree works but isn’t really a great story for deployment or customization.

I own a Tx2 based platform to which we add custom hardware drivers over time. I would like to be able to tell my customers to simply untar a new kernel (with a new device tree specified in extlinux.conf) at the root level and reboot.

I would also like to be able to allow my customers to select different kernels/device tree configurations from uboot.

Having to flash a device tree instead of being able to select one from a multitude on the file system is not ideal and does not improve on what we were previously able to do with the Tx1 (Jetson/TX1 SPI - eLinux.org)

Thanks,

Benjamin

DTB files in “/boot” are not used. Documentation for newer releases gives information on using flash.sh to update device tree (things change depending on release). Example of an update via flash.sh:

sudo ./flash.sh -r -k DTB -d <path/to/device tree> mmcblk0p1 jetson-tx2

Selecting kernels at boot time requires a serial console. Editing “/boot/extlinux/extlinux.conf” allows adding multiple entries.

I don’t know what to tell you for allowing customer flashes of dtb since this is more or less tied to flash.sh now (there seems to be some sort of signature added at the start of the dtb in R28.2, but there are many parts of this mechanism I have not looked at so maybe there is a solution).

Hello all,

I managed to be able to use FDT in /boot/extlinux/extlinux.conf simply by using flash.sh of jetpack-3.0 to install binaries from l4t 28.2 :)

It is a little bit tricky, as flash.sh configuration is not consistent :)

cd ~/jetpack30/64_TX2/Linux_for_Tegra_tx2
 LINUX=<my-kernel-image>
 FDT=<my-dtb>
 ROOTFS=~/jetpack33/64_TX2/Linux_for_Tegra/rootfs
 RTCPUFW=~/jetpack33/64_TX2/Linux_for_Tegra/bootloader/camera-rtcpu-sce.bin
 SPEFW=~/jetpack33/64_TX2/Linux_for_Tegra/bootloader/spe.bin
 # Do not use the '-K' option; '-K' option replaces u-boot, not Image, by
 # '-K's argument !!!
 sudo DFLT_KERNEL_FS=${LINUX} SCEFILE=${RTCPUFW} SPEFILE=${SPEFW} ./flash.sh -d ${FDT} -R ${ROOTFS} jetson-tx2 mmcblk0p1

Yes, the older releases still used the FDT entry in extlinux.conf (ahh, the good old days!). The device tree itself from R28.2 probably hasn’t changed much (if any). Mostly what changed is the method of installation.

so what is the procedure to edit and upgrade a dtb for r32.3.1
Terry

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.

1 Like

can I use " -d --------- device tree file." in flash.sh to point at my device tree file?

instead of chasing the log garbage you talked about.

Terry

linuxdev,

If the documentation had the information in it, you would not have to add 4-5 paragraphs of explanation. Why do you guys keep pointing at the incomplete documentation?

Terry

hello terrysu50z,

you may review the developer guide and check the Flash Script Usage.
for your information,
-d option would only specify the location of dtb file, this also perform whole flashing process to flash the board.
if you would like to replace dtb file only, please use -k options and following with partition names.
thanks