new gpio (change of pinmux)


I’ve seen in documentation description how to create dtsi files for new board’s pinmux, which are then used for creation of .cfg files.
But I don’t see in this procedure that the same files are used for u-boot/kernel , as normally these is used with dts files.

Does it mean that the change in kernel dts is done manually ?

Thank you,

In newer releases the device tree is in a partition and must be added through the flash software. In older releases it was just a file copy. The issue is that currently early boot stages need access to the tree, but those stages do not read the ext4 file system type.


Can let me know which file to be copy? We designed a custom carrier board for production Nano SOM. I follow the Nano SOM bring-up and flash it. The gpio pin did not chage to the new pinmux after:

  1. generated 2 dtsi files, and transfer to a host /Linux_for_Tegra/source/public/hardware/…/prog-platform/tegra210-prog-pinmux-p3448-0002-b00.dtsi and the other file to the same directory tegra210-prog-gpio-p3448-0002-b00.dtsi.
  2. cross compile per instruction"export CROSS_COMPILE=…-linug-gnu-"
  3. Rebuilt the device tree also following the instruction
    cd <Linux_for_Tegra/source/…/kernel-4.9/
    make ARCH=arm64…
    make ARCH=… dtbs
    (after above step it generates .config file and arch/arm64/boot/dts/tegra210-p3448-0002-p3449-0000-b00.dtb file and other files)
  4. Copy one new “arch/arm64/boot/dts/tegra210-p3448-0002-p3449-0000-b00.dtb” file to the following directory for flashing
  5. flash the taget (SOM)

Can you tell me what did I do wrong from the above instructions?
Which step did the 2 dtsi files are used?


This is a very old thread and some of the information might be too out of date for current releases. Keep in mind that it is usually better to start a new thread versus extending a thread that is a couple of years out of date.

Currently, if the “FDT” key/value pair in “/boot/extlinux/extlinux.conf” is named, then that device tree is used. If not, then the one in the partition is used. You should be able to test without flashing unless you’ve burned a fuse (which mandates signed content, and this in turn is for partitions).

I could not tell you which specific tree file to use. If you log a flash, then you’ll see which trees were used, and then you can flash again after replacing that tree. You can either browse “/proc/device-tree/” to verify your changes are in, or create a “.dts” source file to browse based on the “/proc” content, and then verify your change made it in. From the Jetson:

sudo apt-get install device-tree-compiler
sudo dtc -I fs -O dts -o extracted.dts /proc/device-tree

FYI, a “.dtsi” file is combined with other device tree files to create the end “.dtb” binary in a kernel dtbs build target. Which files to combine depends on the kernel’s configuration, and I do not know which one it is for your case.

If I were to log a flash to find out which trees are used, then I’d use something like this to flash:
sudo ./ jetson-tx2 mmcblk0p1 2>&1 | tee log_flash.txt

Someone else may know which specific dtb file to use.