How do I flash an image along with a custom DTB with flash.sh?

Hi,

I can’t seem to figure out how to specify a custom device-tree when flashing a TX2 with flash.sh.

I know there is a separate command e.g.:

flash.sh -d foo.dtb -k kernel-dtb jetson-tx2 mmcblk0p1

which will flash the DTB partition.

But my issue is that I wish to write the device-tree image as well as flashing the main image/partition.

What’s the trick to doing this?

If you know which tree under either “Linux_for_Tegra/bootloader/” or “Linux_for_Tegra/kernel/” provides the content, then just replace that with yours and flash normally. If you log a flash you’ll be able to just look at the log and know the answer more or less:
sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt

It can be confusing because there can be more than one tree depending where in boot and which release of L4T. The log will clear that up (just be sure to save a copy of the original). This also means signing will work. If you are worried about losing something, then you can clone first. Just be sure that if you are mixing flashing just some content and keeping some old content you use the same L4T release for compatibility across components.

I want to flash MY OWN device-tree that I have created outside of the tree entirely.

Why does flash.sh even take -d | --dtb flags any way if it can only flash what’s in the Linux_for_Tegra directory? I want to override the DTB with my own file completely.

Needing to replace the file in the tree is very odd to me.

This can change depending on release. Which L4T release are you using? Someone else will need to answer based on that, but there are actually kernel device trees and bootloader device trees (earlier releases did not need to pass device trees to early boot stages, but now the tree is used early on and passed as an argument).

Additional issues may occur if your tree is larger and a partition is used, where that partition is too small for the signed dtb you have named. Depending on parameters of flash (which may name a carrier board) the choice of dtb used may change as well. You may want to clarify which release you are using, and what parts of the dtb are changed.

I’m using L4T 32.2. There are a few parts of the DT I have changed but mainly to change the USB/PCIE lane mappings so I can get USB 3.0 and to get 2x1, 1x1, 1x1 pcie lane configuration.

When you write jetson-tx2 in your flash command, flash.sh adds .conf to it and then runs source on jetson-tx2.conf. Looking at other such .conf files in the same directory, I noticed that some of them define a DTB_FILE= line that specifies the DTB file to use.

Perhaps you might have some success by copying the stock jetson-tx2.conf to my-jetson-tx2.conf and adding your desired DTB file there. You would have to call flash.sh with my-jetson-tx2 instead of jetson-tx2 though.

I think you would still have to deploy your DTB in the kernel/dtb directory though, but at least you wouldn’t have to clobber the stock dtb file.

What @BareMetalCoder said is probably a good way to test. Basically I was thinking of replacing the stock dtb file, while his method changes the pointer to the dtb file. As long as the flash script signs your dtb file and installs that it doesn’t matter how the script found the file…but there is some advantage to having a repeatable custom configuration file.

The part NVIDIA may need to answer is that USB/PCIE lane mappings may matter prior to reaching load of the Linux kernel. Possibly the kernel-dtb and another dtb need to both change for this. Early boot stages sometimes need this information. If this were just something run by Linux, then I think just kernel-dtb would be the answer, but I do not know for this use case.

1 Like