Custom Carrier Board Pinmux and DTS Process

I have spent many hours trying to just use your documentation to create a new pinout for my new custom carrier board for my Nano, which right now I have the tegra210-p3448-0000-p3449-0000-b00.dts devicetree map in place, which is what comes out of the box for this SODIMM.

I have these links to follow, and have been all day trying to “decode” what is really needed.
NVIDIA Jetson Linux Developer Guide : Platform Adaptation and Bring-Up | NVIDIA Docs
NVIDIA Jetson Linux Developer Guide : Kernel Customization | NVIDIA Docs
NVIDIA Jetson Linux Developer Guide : Kernel Customization | NVIDIA Docs

Each and every one of those links above, if you try to follow them, end up in a frustration because the directory, the file, the whatever is not what the documentation says.

For example,
## Obtaining the Kernel Sources with Git
•You have installed Git. Install Git with the following command:
$ sudo apt install git-core
•Your system has the default Git port 9418 open for outbound connections.
To sync the kernel sources
•Get the kernel source by running the script:
$ ./
When prompted enter a ‘tag’ name, as provided in the release notes.
You can sync to any Linux tag you like. However, the tag provided in the release notes syncs the sources to the same source revision the release binary was built from. To see a list of the available release tags, use:
$ git tag –l tegra-l4t*

which is right out of the documentation , leads you to NOT be able to locate ./, which is of course how the build all happens. Without that script, nothing.

So I go and download the source and do find public_sources.tbz2, which is great, but after following

5.Copy the generated .dtsi files from the directory that contains the spreadsheet to the following locations:
jetson_nano_module-pinmux.dtsi to <src_path>/hardware/nvidia/platform/t210/porg/kernel-dts/porg-platforms/tegra210-porg-pinmux-p3448--.dtsi
jetson_nano_module-gpio.dtsi to <src_path>/hardware/nvidia/platform/t210/porg/kernel-dts/porg-platforms/tegra210-jetson-cv-gpio-p2597-2180-a00.dtsi
•<src_path> is the pathname of the kernel sources that you downloaded in step 1.
•jetson_nano_module is the filename prefix that you entered in step 7 of To customize the pinmux spreadsheet. If you did not use the recommended default, change the filenames accordingly.
• is the module’s SKU number. You must specify it as a four-digit number, i.e. 0000 or 0002.
• is the version of the Jetson Nano device tree that you identified in step 3.

but guess what, there is no "hardware"dir, much less the entire tree is not accurate.

I am stuck I just need to engage the new pinmux and be on my way, and the entire day has been all like this, get something, extract it, and it is NOTHING like what the documentation says it is.

I am on a timecrunch, as everyone else is, and this is not supposed to happen. Why put up instructions that are not accurate?

1 Like

Moving this to the Jetson Nano forum for greater visibility.

hello james.rhodes,

you need to specify the l4t release version to the git command, i.e. tegra-l4t-r32.5
you’ll see below three folders of the available sources if you’re using to fetch the code,
for example,

├── hardware
├── kernel
└── u-boot

these will also sync the code to the r32.5 release, you’ll see .git/ folder for each repository, and the git commands also works there. for example, you’re able to review all check-in changes with git log --oneline within the repository.

there’s other approach to download the code,
please see L4T | NVIDIA Developer page for the driver details.
it’s L4T Driver Package (BSP) Sources, download as public_sources.tbz2 package.
once you untar the package, it’s kernel_src.tbz2 to include kernel and device tree sources; there’ll be hardware/ folder for the device tree source files.

once you locate the path,
please refer to Kernel Customization chapter to setup your build environment, you shall merge the device tree files and build the *.dtb for your target.
you need to know the revision number of your platform. this info also shown when you flashing the board.
it’ll pop-up in the flashing messages. for example, Board ID(3448) version(200)

Jerry, thank you for the reply. I do not follow, perhaps you have a document that takes me through the process of creating whatever it is that I need to make my pinmux changes from the Excel spreadsheet that you have created for me to us.

I have the two .dtsi files, and a Nano development platform, using the tegra210-p3448-0000-p3449-0000-b00 from the developer kit. I do not have the eMMC version, I am using an SDCARD to do this work. I also have a very expensive custom carrier board that I have minimal pin changes, but there are changes that are needed.

  1. assume that I have the two .dtsi files, a 32GB SDCARD, and the tegra210-p3448-0000-p3449-0000-b00 module
  2. what do I download, onto what?
  3. what do I flash, and to where am I flashing? Do I do this to the SDCard?

I was able to create a kernel image using my two .dtsi files, but I don’t see where I now apply the kernel image in my system

As I mentioned, I have been using devicetrees for years, and have done so on many systems with no problem using uboot and simply compiling the dts and linking that to uboot using the .env file. Pulling sources, compiling them, imaging them or flashing them without good documentation is where I am right now.

You guys have to have a step-by-step document on how to do this. Most of your help pages say things like “you must have this…” but no where, and I mean no where, does it tell you what that is, or where to get it. A good example of the “you must do this…” is in board naming, however no where can I find HOW to name my board. I don’t want you to focus on this, I need to get my pinmux data into this board, and fast.

I really need something that is not cryptic, and just walks a person through this process. Hard to believe that I am the only one asking for this, but maybe I am just not smart enough!

Hope that you can help!

1 Like

hello james.rhodes,

it’s simply to include the pinmux generated *.dtsi files to the sources and build the new device tree blob.
after that, having partition update with to update DTB partition to include the changes.

are you able to compile the release sources to generate device tree blob?
you should update the correct device tree binary, and using flash script to update it.
i.e. $OUT/Linux_for_Tegra/kernel/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb

Hi Jerry,

You have to remember that you live and breathe this stuff everyday, and you just take for granted when you say “update with”. I have no idea where to get, or where to run it from, or where it affects, or where to put the files so that it sees those. I don’t know what you even mean when you say “device tree blob”.

I am a programmer. I just need the pins to work.

You are an expert. This is my first time to use this method. Don’t you have a document that walks people through this process?

device tree blob it’s a binary file of device tree, used by platforms.

here’s NVIDIA Jetson Linux Developer Guide, the chapter I’ve point-out in comment #5 as included in this documentation.
you may go through the index for details. for example, Flashing and Booting the Target Device about usage.

assume you’re installing JetPack release via NVIDIA SDK Manager | NVIDIA Developer,
then it’ll also download the l4t release image and also necessary scripts to your local host, i.e. ~/nvidia/nvidia_sdk/
you’re able to perform the image flashing with the script files to deploy your implementation.


I have read that probably 25 times. Here is my trouble, this is the first section in that Flashing guide…

Use the helper script to flash the board with the bootloader and kernel, and optionally, flash the root file system to internal or an external storage device.
## Before You Begin
The following directories must be present:
•bootloader: Bootloader plus flashing tools, such as TegraFlash, CFG, BCT, etc.
•kernel: A kernel Image /vmlinux.uimg, DTB files, and kernel modules
•rootfs: The root file system that you download

This directory starts empty. You populate it with the sample file system.
•nv_tegra: User space binaries and sample applications
Additionally, before running these commands, you must have the USB cable connected to the recovery port.

WHERE is this stuff, where do I get it, where does it live on my SDcard? I know that the location is arbirary as long as the directories are relative, but the very first instructions are “YOU MUST…” but there is no method to “GET” the script!

Hi Jerry.
So we do have an updated “tegra210-p3448-0000-p3449-0000-b00.dtb” which should include the dtsi files. When you say to “flash” the device, do you mean we need to simply replace “/boot/dts/tegra210-p3448-0000-p3449-0000-b00.dtb” on the SD card? Could this be done manually by mounting the SD card and copy-replace the file manually?

It might be easier than trying to use a flash script if all we need to do is replace a single file on the SD Card.

check this, please setup develop environment to get the scripts.

hello sgroesz,

device tree blob is by default loaded from DTB partition, there’s partition update to flash it.
i.e. $ sudo ./ -r -k DTB jetson-nano mmcblk0p1

there’s CBoot functionality to include a default booting scan sequence.
please check /boot/extlinux/extlinux.conf, you can assign a FDT entry to specify the path of device tree blob. it makes CBoot to load *.dtb from the filesystem.

I have tried compiling the kernel using the .dtsi files generated by the Excel script.
I’ve replaced the kernel Image and the .dtb files (2 places: /boot/tegra210-p3448-0000-p3449-0000-b00.dtb, /boot/dtb/kernel_tegra210-p3448-0000-p3449-0000-b00.dtb)
I’ve replaced the DTB partitions (2 places) with the partition generated by

The only thing left I can see to try is to replace the U-Boot and C-Boot partitions, which would require rebuilding U-Boot from source. PDF document DA_09361-002 references a method to generate a header (pinmux-config-[board].h) to incorporate into the u-boot source tree. However, following the PDF instructions resulted in not being able to build the source. The web instructions for updating the u-boot image, Jetson TX1 Platform Adaptation and Bring-Up: Porting U-Boot, do not reference the header file generated from the Excel script. So, it appears that to incorporate our pin changes for our custom carrier board, we will need to modify the following u-boot source files:

  • include/configs/jetson-p2371-2180.h
  • arch/arm/dts/tegra210-p2371-2180.dts
  • configs/p2371-2180_defconfig
  • arch/arm/mach-tegra/tegra210/Kconfig
  • all files in board/nvidia/p2371-2180/

Once these files are modified to reflect our custom pinout and I am able to successfully build u-boot, I would then need to flash the update to the u-boot partition.

So, it seems to me it is necessary to modify both the kernel and u-boot, and there doesn’t seem to be a shortcut to modify u-boot short of manually editing the source by hand to make the pinmux changes we need. Do I have this right?

I also added an FDT entry to extlinux.conf but that didn’t seem to have an effect.

I am measuring success by evaluating “dmesg | grep -i dtb” and “cat /sys/kernel/debug/gpio”. The response I expect to see from dmesg is the timestamp for the DTB to match my updated device tree files, and the gpio output to reflect our custom pin configuration. So far, it doesn’t appear that my changes to just the kernel have had the result I am looking for, so the next thing for me to try is to modify U-boot…

I have identified the SD Image partitions as follows:

# image file partitions
# Device            Start      End  Sectors  Size Type             Description
# sd-blob-b01.img1  28672 27918335 27889664 13.3G Linux filesystem the rootfs
# sd-blob-b01.img2   2048     2303      256  128K Linux filesystem TegraBoot CPU-side binary
# sd-blob-b01.img3   4096     4991      896  448K Linux filesystem Bootloader DTB binary
# sd-blob-b01.img4   6144     7295     1152  576K Linux filesystem CBoot
# sd-blob-b01.img5   8192     8319      128   64K Linux filesystem warm boot binary
# sd-blob-b01.img6  10240    10623      384  192K Linux filesystem SC7 entry firmware
# sd-blob-b01.img7  12288    13055      768  384K Linux filesystem BPMP DTB binary
# sd-blob-b01.img8  14336    14463      128   64K Linux filesystem Reserved for fuse bypass
# sd-blob-b01.img9  16384    17279      896  448K Linux filesystem TOS binary
# sd-blob-b01.img10 18432    19327      896  448K Linux filesystem kernel DTB binary
# sd-blob-b01.img11 20480    22015     1536  768K Linux filesystem U-Boot
# sd-blob-b01.img12 22528    22655      128   64K Linux filesystem encrypted keys
# sd-blob-b01.img13 24576    24959      384  192K Linux filesystem BMP images for splash screen
# sd-blob-b01.img14 26624    26879      256  128K Linux filesystem XUSB firmware file

here’s a bug in JetPack-4.5.1 to update the u-boot binary to address this,
for example, Jetpack 4.5.1, TX2, BUG : FDT selected file loaded incorrectly by uboot - #16 by JerryChang
you should perform partition update to flash kernel partition (i.e. -k DTB) for updating uboot binary.

Where do I actually need to replace the device tree?

One file is under boot in the rootfs. Another is under boot/dts on the rootfs. And probably a third dtb file in boot/Image

Then there are two partitions on the SD card which contain the DTB.

I have replaced all these instances of the device tree, but the default DTB is still loading. I found two more copies of the device tree on a 4mb EEPROM. There are also 4 256GB NVRAM devices that I haven’t even started to look at.

Anyway, that’s at least 7 instances of the device tree on the system that I have identified so far. Despite other comments saying that the SD card is the only flash used to operate the NANO, the 4MB flash clearly affects it as well, as my attempt to change the DTB on the 4mb flash has failed.

So, I have followed the manual and recompiled the kernel and DTB files. I have REPLACED the stock DTB files for my SOM. On the SD card, I verified that every instance of the original DTB file was replaced - down to the physical binary level of the raw SD device. Yet for some reason, the system is still loading a stock DTB.

Ideas are welcome.

Bonus question: If someone can point me to a link to how to reflash the 4MB module to get the Nano to boot, that would save me some time. The 4MB module is identified as /dev/mtdblock0, and I saved the original contents of the module before I made any changes, so I can recover it if I can get access to the module. but my #1 concern is figuring out why the DTB blob that I want to load is not loading - and why are there no less than 7 copies of this same binary data??

Not pythonic. (101.2 KB)
So far, I have re-compiled the kernel according to the instructions This also generated a new device tree DTB.

To keep it simple, I am simply modifying the source code for p3448-0000-p3449-0000-b00 found in kernel/hardware/nvidia/platform/t210/porg/kernel-dts/porg-platforms in the kernel source code. I replaced the original dtsi files with the dtsi files from the excel script.

I flashed the generated kernel Image and .dtb file to the nano. I have finally gotten to a point where the modified devicetree seems to be loading. However, I am still unable to interact with the pins as they are configured.

What other files need to be changed to be able to interact with our custom pinmux?

the contains the .dtsi files generated by the excel script, the output of “dmesg” which shows that the correct .dts is being loaded during boot, the output of “cat /sys/kernel/debug/gpio”, the .dtb file generated after replacing the .dtsi files as described in my previous post, and the decompiled .dts file generated from the .dtb using dtc.

Tell me the steps I need to take to use the pinout I have defined in the excel script.

The excel script with the changes that need to be implemented can be obtained here:


We have been at this for more than a month, and this should not have taken this long. We really need your support, and as I had asked when I was posting here, we need a “step-by-step” process for this that works.

Perhaps the right answer from you all would be a document that starts with the Excel spreadsheet, then gives us very detailed and not obscure steps to get to the end result. We are capable of performing just about any task from simply using UBOOT to setup the pinmux, to whatever we need to do, including compiling our changes into the kernel, flashing EEPROM, etc.

We have used devicetrees for years on other platforms, across many projects, and not once did this take this monumental effort to get our I/O where we want it.

So, what I am asking is for a “step-by-step” method to start with the output from the Excel sheet, to success. Giving us small trinkets of information is not going to work, start from the beginning and get us to the endgame of having our pins work as we expect.

Thank you in advance.

1 Like

Nvidia team, we really need some help here. This is a significant volume, commercial product which is visible to your management, since our customer is pretty big, and all that I can tell them is that we are waiting on getting the pinmux setup right to check out the final board design before we go to the production version.

This cannot be this difficult to accomplish. As I asked two days ago, we need a step-by-step method/document that starts with the Excel pinout document, and gets us to a mapped pin function every time.

We had a goal of last Friday to release final board changes to the production team, but we missed that…and now the pressure is building. Please take this seriously as our timeline is well behind now, and next steps may be management asking me for “who they can call” to get this accomplished.

Thank you in advance.

I do not know how to turn off “Solution” on this thread, we are not SOLVED.

TomK, we noticed that this thread shows “Solution” checked, and not sure where this is in the main Nano forum, but we are still down and need help, 6 weeks now!