Sdkmanager, jetpack 3.3.3 and custom board : where can I provide my dtb?

Hello,

I have installed jetpack 3.3.3 on a Jetson TX2 devkit and it went flawless.

Now I would like to install jetpack 3.3.3 on a Jetson TX2 custom board.
When and where can I provide my own dtb in sdkmanager ?

I am not a “custom board guy”, but consider flashing on command line (you can always run SDKM later and set it to just install optional packages). If you were to flash normally, and were to log that flash, then this would be something like (from the “~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/” subdirectory):
sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | log_flash.txt

Then you could see which actual reference tree was copied to where, signed, and then flashed. You would essentially replace the original reference tree with your tree. There are other ways to do this though, e.g., perhaps through a “.conf” file. Other docs will tell you more about this (I can’t since I don’t work on custom carriers). Regardless, you will find it very useful to always have a reference log to a command line flash (don’t lose it).

Sdkmanager will download a folder Linux_for_Tegra on your host.

If you are going to try customization, then please do not use sdkmanager anymore but directly use the tool under this path.

The L4T developer guide and quick start guide in our download center and provide you some tutorial.

OK :) Thank you both. That’s what I have done, but as the main page about jetpack-3.3.3 tells exclusively to use sdkmanager, I wondered if I had missed a button somewhere.

JetPack 3.x is very old, is there a reason why you are using this, e.g., you must use its version of CUDA? A list of releases can be found here (you might need to login and then go to the URL again):
https://developer.nvidia.com/embedded/jetpack-archive

I know, but we have a big base of 3.3-based boards installed at custormer’s sites and upgrading to 3.3.3 is less disrupting than going to 4.4. Unfortunately it’s not really easy either.

If you flashed JetPack3.3.3, then it implies L4T R28.4 is installed. You could verify if this is correct:
head -n 1 /etc/nv_tegra_release

For those older releases, you could verify other related files are of a valid release via:
sha1sum -c /etc/nv_tegra_release

Had you manually downloaded the R28.4 driver package and sample rootfs and properly installed the sample rootfs (including the correct apply_binaries.sh), then this one-time setup would allow you to flash as much as you want without repeating those steps. For the case of a custom device tree, then you should be able to see a flash log and replace the correct file with your tree prior to flash, after which every flash would already include the correct tree. There are some conf files which could perhaps be edited with a custom target, but I have not set that up.

A typical flash to get a command line flash log is this from the “Linux_for_Tegra/” directory, and assumes “Linux_for_Tegra/rootfs/” is correctly installed:
sudo ./flash.sh jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt

It would be up to you to find which of the dtb files being flashed contains your custom content. You would then find that file in the reference dtb files, and replace it with your edited version.

Note that you can examine a dtb file by reverse compiling it to source format, the dts:

dtc -I dtb -O dts -o original_source.dts /where/ever/it/is/orginal_binary.dtb