Hi guys, We are struggling to understand if and how the device tree gets updated on a Jetson-TX2. A rootfs image created by yocto (“zeus”) does not seem to update the device tree when updating through mender. How can we update the device-tree partition(s)? Thanks!

Yep, that’s the problem. I think this is due to some recent commits in meta-tegra that need some corresponding changes in the meta-mender-community/meta-mender-tegra layer. I have some changes on a branch in my fork of that repository that should fix this. In particular, this commit .

Not the same board, but some inspiration: Updating a Raspberry boot partition So, it requires the dtb to be present in your rootfs.

@dwalkes probably knows this better, but I believe on the NVIDIA boards the nv_update_engine is used to update U-boot/kernel/dtb. With this state-script containing the gist of it: mendersoftware/meta-mender-community/blob/zeus-test/meta-mender-tegra/recipes-mender/tegra-state-scripts/files…

thanks for your reply! We tried running the nv_update_engine. It didn’t update the device tree. But my understanding is that the devicetree is not part of the BUP? If it helps we get the following entry_table in the /opt/ota_package directory after running nv_update_engine: root@jetson-tx2:~# cat…

Parts of the BUP payload, like the DTB, are specific to a version of the TX2 module you have in your device. Only if a copy in the payload matches the version of your module will nv_update_engine install it. The version information it uses for matching is in /etc/nv_boot_control.conf on the TNSPEC …

Thanks for your help! Here is the requested output [2020-06-30 13:57:57] root@jetson-tx2:~# cat /etc/nv_boot_control.conf [2020-06-30 13:57:59] TNSPEC 3310-D00-1000-F.0-1-0-jetson-tx2-mmcblk0p1 [2020-06-30 13:57:59] TEGRA_CHIPID 0x18 [2020-06-30 13:57:59] TEGRA_OTA_BOOT_DEVICE /dev/mmcblk0boot0 …

and for what it’s worth I get this when I grep for 3310 in the bl_update_payload (not sure if it’s relevant): root@jetson-tx2:~# strings /opt/ota_package/bl_update_payload | grep 3310 3310-1000-B00-A

Yes, that’s the problem, then. If you’re using the zeus branch in meta-tegra (based on L4T R32.2.3), BUP payloads built only support a single board revision. The zeus-l4t-r32.3.1 branch builds multi-spec BUP payloads, and it should be including the necessary artifacts for the revision D00 FAB.

We are on the zeus-l4t-r32.3.1 branch, actually. Is there a specific (recent) commit that we need to be aware of? Is is possible to misconfigure/misuse this feature somehow on our end? Can I check something in my build to verify the generation of the payload works as expected? Thanks!

I tried to dig a bit deeper. But to be honst I don’t quite understand how the different bup payloads are getting build and deployed. I see multiple payloads being deployed in the images directory (e.g. u-boot-dtb.bin.bl_only.bup-payload) but they all contain only the 3310-1000-B00-A string. But the…

Jetson-TX2 - updating device-tree

General Discussions

mirzak June 30, 2020, 11:20am 5

Ok, then I am not sure how it works. So will defer to @dwalkes or @madisox who have primarily been involved in the tegra integrations…

Topic		Replies	Views
Nvidia Jetson L4T Integration Debian family nvidia , jetson	23	9208	June 6, 2025
NVIDIA Tegra Jetson Xavier NX Yocto Project nvidia , dunfell	25	6991	May 4, 2022
Mender standalone update from warrior to zeus (or dunfell) Board Integrations yocto , warrior	8	1228	April 17, 2021
NVIDIA Tegra Jetson Nano Yocto Project yocto , nvidia , warrior	31	12410	May 2, 2024
Nvidia Jetson Orin L4T image Update Board Integrations nvidia , jetson , l4t	3	2803	April 1, 2026

Jetson-TX2 - updating device-tree

Related topics