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
Prerequisites
•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 source_sync.sh script:
$ ./source_sync.sh
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 ./source_sync.sh, 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
Where:
•<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?

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 source_sync.sh 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)
thanks

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!

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 flash.sh to update DTB partition to include the changes.

so,
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 flash.sh”. I have no idea where to get flash.sh, 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.

BTW,
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 flash.sh 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.
thanks

Jerry,

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

Use the flash.sh 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 ./flash.sh -r -k DTB jetson-nano mmcblk0p1

besides,
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.
thanks

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 flash.sh

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. flash.sh -k DTB) for updating uboot binary.