I dont see them in the JetPack 4.2 folder structure…are they on the target?
Power supply changes
tegra194-power-tree-p2888-0001-p2822-1000.dtsi
Regulator parameter changes
tegra194-spmic-p2888-0001.dtsi
ODM data based feature configuration
tegra194- plugin-manager-p2888-0000.dtsi
NVIDIA SoC controller state to enable/disable a controller
soc/t19x/kernel-dts/tegra194-soc/
Panels related .dts files
platform/tegra/common/kernel-dts/panels/
“.dtsi” files are “include” files for device tree source files. They’re in the kernel source, not the JetPack4.2 code. If you were to compile custom device trees, then one way is to set kernel source config correctly and then build the dtbs target. Once you had the binary it would be up to you to copy it to the correct location in your JetPack directory prior to flashing.
Note that your “Linux_for_Tegra/” directory has file “source_sync.sh”. You can download both in-tree and out-of-tree content for the Xavier R32.1 like this:
# Use sudo if your location is owned by root.
./source_sync.sh -k tegra-l4t-r32.1
This produces directory “sources/”. The code is within that.
Thanks for the tip!
I saw this on this website before, but had abandoned that flow because it was for JetPack 4.1.1
Is this a good set of instructions for making a custom device tree? It’s my understanding for a custom carrier board we need a custom device tree which needs to be modified pretty significantly.
Most documents on the process of changing a device tree are the same and universal. As release versions change you may find differences in adding that change to the actual Jetson, e.g., in more recent releases you need to use the flash tool due to signing. The actual content or edits to the device tree are very specific to the particular carrier board, and you’ll need that information from the carrier board manufacturer. The manufacturer will provide a “Board Support Package” (“BSP”) which can be directly copied into the “Linux_for_Tegra/” directory to overlay their version of device tree on top of the default content (editing wouldn’t be required in most cases, just file copy prior to flash). Each L4T/JetPack/SDKM release would require a different BSP (well, exceptions maybe if it is just a bug fix release).
Understood on the custom BSP required - hence my questions.
I designed a very complex carrier for the SOM, and am trying to go through the process of rebuilding the device tree and BCT etc.
As primarily a hardware designer, who knows enough about Linux to get in trouble, I am sort of flubbing my way through it.
I appreciate the explanation.
Our boards are due to arrive in the coming weeks, so we are just trying to get ramped up on the process for rebuilding/recompiling/reflashing as we will no doubt be mucking around in this for a while.
In your situation some extended information might be useful as well.
The tool which actually converts between various formats of device tree files is the device tree compiler, “dtc”. This tool is architecture independent and does not require any changes to operate on different architectures. The tool on a desktop PC works perfectly with files being shared across architectures. You can install this directly, and you might already have it in your path.
The kernel source also ships with this, and if you build a device tree there, the kernel simply compiles dtc and then puts the device tree together after taking into account which dts and dtsi files are named in your config. The dtc which comes with the kernel is the same as what you might install separately, and I’ve not seen version changes in a very long time.
The kernel target to build a device tree binary is “make dtbs” (though you’d probably want to use other options to build in a separate location and not pollute the local kernel source). The dtbs target is completely independent of the kernel build, but the two arrive together because the kernel drivers are what use the device tree…if you do or don’t build a particular component, then you will or will not need the related device tree code (this separates drivers from hardware-dependent arguments). Always configure for the kernel you are using before building the device tree target. You might need some extra package installed to build dtbs target in the kernel, but I don’t recall off hand which extra package might be needed.
dtc can convert between formats. “.dtb” is binary, “.dts” is source. The filesystem can also represent this as a tree of directories. Some examples:
# Extract source from a running system, create the source from the running kernel:
dtc -I fs -O dts -o extracted.dts /proc/device-tree
# Convert a dtb to a dts:
dtc -I dtb -O dts -o source.dts original.dtb
# Compile a dts to dtb:
dtc -I dts -O dtb -o new.dtb original.dts
If you happen to have a device tree binary in your flash software area (somewhere in a subdirectory of “Linux_for_Tegra/” (some content exists in both the “kernel/” and “bootloader/” subdirectory), then rather than going through the full kernel rebuild you can just convert the binary to source, edit, and then recompile back to binary (and presumably backing up the original, followed by copying the edit over the original).
You will find that the device tree reported in “/proc/device-tree/” is mostly a match for what is flashed, but this is not 100%. The reason is that the tree is used in earlier boot stages, and CBoot will edit this slightly prior to passing it on to the Linux kernel. This is also why the device tree is no longer a simple file copy…earlier boot stages do not know how to read the ext4 filesystem, plus signing is performed. If you do replace a dtb and signing is not correct, then the dtb would be rejected. You shouldn’t have issues with signing if you follow the docs to place the tree in the right place and then use the flash.sh tool to install the tree.