Can't update DTB after update from JetPack 4.4DP to 4.4 on Xavier

Hi All.

I’m having an interesting behavior :-(

I’m working on a custom board. I installed SDK manager 4.4DP on a host machine and managed to port all needed stuff to custom board.
Everything was nice and straightforward.
Lately I executed an update on my custom board and ,I guess , as a result of this my DTB file was changed (updated).

On my host machine I’m executing the following command:

/ -r -k kernel-dtb jetson-xavier mmcblk0p1

My DTB file tegra194-p2888-0001-p2822-0000.dtb located under “Linux_for_Tegra/kernel/dtb/”
The flash process is passing and board is rebooting. Some finals lines:
[ 8.5211 ] tegradevflash_v2 --reboot coldboot
[ 8.5219 ] Bootloader version 01.00.0000
[ 8.5347 ]
*** The [kernel-dtb] has been updated successfully. ***

But my DTB file is not loaded. Here are some prints from dmesg:

[ 0.816200] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t19x/galen/kernel-dts/common/tegra194-p2888-0001-p2822-0000-common.dtsi
[ 0.816216] DTB Build time: Jul 9 2020 23:09:18

This is not my path and not the date.

Please advice.

Thanks in advance

A small update.

From the same folder on host, this time I executed
./ -r jetson-xavier mmcblk0p1
This time the DTB is burned correctly, but it also burned system.img (which is taking a long time).
This is kind of work around ( a long one, but working).

hello dshtaingus,

since JetPack-4.4 is available now, it’s the latest production release, supporting all Jetson modules.
suggest you have software upgrade to update JetPack Developer Preview to latest release.

there’s documentation for your reference.
please refer to CBoot chapter, you may check [Kernel Boot Sequence Using extlinux.conf] session to modify the boot sequence.

we had confirmation based-on JP-4.4;
that device tree update works by (1) Flashing kernel-dtb partition, or, (2) Loads the kernel-dtb binary file from FDT entry.

1 Like

Hi Jerry,

Thanks for the answer. I’ll test my setup to figure out why it was not working.
I have one more question for you.
How I can close the automatic update for DTB? ( I really do not want it to happen at the customer site).

Thanks again

hello dshtaingus,

please check documentation for the Over-the-Air (OTA) Update chapter.
it’s a deb file, nvidia-l4t-kernel-dtbs, which may refresh by using command update, i.e. $ sudo apt upgrade.

if you would like to avoid customer update it by accidentally.
you may modify the source.list to avoid it fetch nvidia sever i.e.
please maintain your own repository as an alternative approach.

1 Like

Hello Jerry,

Thanks again for your outstanding support! I really mean it.

I took a look at your link and I still got a small question for you.
There is a list of packages called: Basic Packages for L4T
It contains something like 20 packages.
I do want my customer to be able to update all the listed packages, except “nvidia-l4t-kernel-dtbs” .
According to the /etc/apt/sources.list.d/nvidia-l4t-apt-source.list file, I can only control 2 deb entries.
Question is: can I eliminate only 1 entry from the update list? If yes, how?


hello dshtaingus,

it’s not recommend to exclude “nvidia-l4t-kernel-dtbs” package, since it usually depends-on kernel updates.
please remove those two lines from nvidia source list to avoid OTA upgrade from NV server.
i.e. /etc/apt/sources.list.d/nvidia-l4t-apt-source.list

Not trying to thread hijack, but you are working a problem similar to me… Custom carrier, trying to get my head around how to take the pinmux spreadsheet dtsi output and carry it into the dtb, with a plan for OTA updates eventually… I have the generated dtsi and I have seen conflicting details on how one uses those in support of generating a dts/dtb, given you are at a similar spot would you mind recapping how you jumped from pinmux spreadsheet output to dtb suitable for kernel-dtb flash.

Not exactly what you want, but you might consider creating a “.deb” package which depends on the known working release of the “nvidia-l4t-kernel-dtbs” as a dependency. If that package cannot be updated, and depends on the kernel-dtbs package, then any update attempt would refuse to update “nvidia-l4t-kernel-dtbs”. Then if any package depending on “nvidia-l4t-kernel-dtbs” would also be refused update. If it happens that your company has a package server which can be added to the apt repository list it would mean your company could update that one file after testing particular “nvidia-l4t-kernel-dtbs” releases (making a new custom dependency package which allows that “nvidia-l4t-kernel-dtbs” to be updated would release all of the dependencies in the chain of dependencies).


Thanks to everybody for their respond.
I think that this AOT update mechanism is a really cool ad-on.
On the other hand, I guess, more customers are using their custom design boards and not evaluation kits.
As soon as I’m updating all the NVIDIA stuff, at my next boot I’m loosing display, USB and all my I2C devices.
This is what I can’t allow at customer site :-)
I can’t tell for sure, but probably all the updates are software related and not Kernel & DTB.
I don’t know how and I can’t propose a solution. I can only ask for some wishful thinking. Maybe, there is a possibility, in future, to add some kind of mechanism to AOT, that will avoid the DTB & Kernel changes - at least for existing JetPack version.