Difference between kernel-dtb and DTB partitions?

What is the difference between flashing the kernel-dtb partition and flashing the DTB partition?

I see both referenced in different places. For instance this page at elinux.org suggests to use DTB for TX1 and kernel-dtb for TX2. Is this correct?

I don’t know if I’m entirely technically correct about this, but normally, if there is a device tree listed via “/boot/extlinux/extlinux.conf” via a DTB FDT entry, then this is used, but if that entry is not there, then the partition is used instead. If security fuses are burned for secure boot, then only the partition version can be used (which must be signed). You’re almost always better off making adjustments via the file listed in the DTB FDT entry of extlinux.conf when developing (versus trying to flash a signed partition).

I don’t know the details, but some of the pre-Linux content has had some changes in how it gathers boot parameters depending on release, especially depending upon what has changed in the secure boot options. There are places where device tree content is read by those stages, and then there is the device tree content used by the Linux kernel…they might differ.

To illustrate partition versus file read of device tree, look at your extlinux.conf. Note that there is a kernel command line option with “${cbootargs}”. CBoot is a boot stage prior to U-Boot, and is sometimes a complete replacement to U-Boot (Xavier AGX and NX don’t use U-Boot). This stage pre-Linux boot stage can be looking at the device tree node “chosen->bootargs” (check the output of “cat /proc/device-tree/chosen/bootargs”). The “${cbootargs}” expands as an environment variable as the Linux kernel loads. In this case it is possible that the pre-Linux boot stages either passed the device tree content unaltered or else edited the content prior to passing it to the Linux kernel.

If you really want to know details, then you have to look at the documentation for the specific release since how boot flow works changes with release version. Just look for the “boot flow” documents. For R32.5.1 docs are listed here:
https://developer.nvidia.com/embedded/linux-tegra-r3251

Within that the TX2 example document would be the " Jetson TX2 Platform Adaptation and Bring-Up" document. Inside that document it actually lists content for more than just the TX2, but the TX2 URL for “boot flow” is this:
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/bootflow_tx2.html

The boot flow for your particular release version would be the place to start for understanding details of partition versus file read for device tree. If you don’t have a reason to work through partitions for device tree, then stick to the DTB FDT entry method for naming the device tree as a file in “/boot” and your life will be simplified. You can even go so far as having a duplicate boot entry with nothing changed except the DTB FDT entry as a “safe” way to test changes.

2 Likes

As I came upon that topic recently, allow me to add some notes:

The partition holding the kernel dtb is called differently on different platforms (and maybe even l4t versions). They should be listed in docs, but currently there seems to be a replacement error. The docs list names that I consider place holders from /Linux_for_Tegra/bootloader/t???ref/cfg/ files. flash.sh replaces these, but in docs they are not replaced:
KERNELDTB-NAME → kernel-dtb
DXB → DTB
There you have your elinux.org partition names (for TX2/Xavier and TX1)

For reference: The option not using partitions, but loading a dtb file through extlinux.conf, uses a setting called FDT (also explained in the bootflow docs linked by linuxdev).

I should have abbreviated using the extlinux.conf notation. I’m glad you pointed out “FDT” instead of “DTB”. I guess I was thinking of device tree (or partition) notation instead of extlinux.conf notation. For those interested, “FDT /boot/some/file.dtb” is how one names use of a device tree in extlinux.conf which is from a file instead of being from a partition. Partition naming itself is not particularly intuitive.