Custom Carrier Board Pinmux and DTS 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

1 Like

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.

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.

logs_plus.zip (101.2 KB)
So far, I have re-compiled the kernel according to the instructions https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/adaptation_and_bringup_nano.html#wwpID0E0WN0HA. 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 logs_plus.zip 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:
NV_Jetson_Nano_Module_Pinmux_Config_Template.xlsm

Jerry,

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!

I don’t see a solution checked now. Maybe one of the moderators made the change.

hello james.rhodes,

I’d already share the steps in the previous comments,
how about you list all your steps and please share the failure you’ve seen.
thanks

Please review post #18.

After compiling and implementing the device tree .dtb, we are not able to actually use the pinmux changes within the OS.

When we cat /sys/kernel/debug/gpio the gpio still shows the default configuration.

This is the output from …/debug/gpio: http://git.groesz.org/NED/nanotools/raw/branch/master/debug/What%20is%20There.txt

We aren’t seeing the changes we made in device tree be reflected in the OS/Kernel.

1 Like

hello sgroesz,

the steps looks correct, and it’s DTB to define the pin settings.
may I know what’s the pins you’re try to configure without success?
thanks

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

We need to be able to use the pin definitions as seen here:

// Tegra GPIO groups for math below
#define TEGRA_GPIO_BANK_ID_A 0
#define TEGRA_GPIO_BANK_ID_B 1
#define TEGRA_GPIO_BANK_ID_C 2
#define TEGRA_GPIO_BANK_ID_D 3
#define TEGRA_GPIO_BANK_ID_E 4
#define TEGRA_GPIO_BANK_ID_F 5
#define TEGRA_GPIO_BANK_ID_G 6
#define TEGRA_GPIO_BANK_ID_H 7
#define TEGRA_GPIO_BANK_ID_I 8
#define TEGRA_GPIO_BANK_ID_J 9
#define TEGRA_GPIO_BANK_ID_K 10
#define TEGRA_GPIO_BANK_ID_L 11
#define TEGRA_GPIO_BANK_ID_M 12
#define TEGRA_GPIO_BANK_ID_N 13
#define TEGRA_GPIO_BANK_ID_O 14
#define TEGRA_GPIO_BANK_ID_P 15
#define TEGRA_GPIO_BANK_ID_Q 16
#define TEGRA_GPIO_BANK_ID_R 17
#define TEGRA_GPIO_BANK_ID_S 18
#define TEGRA_GPIO_BANK_ID_T 19
#define TEGRA_GPIO_BANK_ID_U 20
#define TEGRA_GPIO_BANK_ID_V 21
#define TEGRA_GPIO_BANK_ID_W 22
#define TEGRA_GPIO_BANK_ID_X 23
#define TEGRA_GPIO_BANK_ID_Y 24
#define TEGRA_GPIO_BANK_ID_Z 25
#define TEGRA_GPIO_BANK_ID_AA 26
#define TEGRA_GPIO_BANK_ID_BB 27
#define TEGRA_GPIO_BANK_ID_CC 28
#define TEGRA_GPIO_BANK_ID_DD 29
#define TEGRA_GPIO_BANK_ID_EE 30
#define TEGRA_GPIO_BANK_ID_FF 31
#define TEGRA_GPIO(bank, offset) ((bank * 8) + offset)
//
// Reset to the safety board, output
#define RESET_OUT TEGRA_GPIO(TEGRA_GPIO_BANK_ID_G, 3) // SODIMM pin 209, GPIO3_PG.00
#define RESET_OUT_DIRECTION e_OUTPUT
// SW1
#define SW1_IN TEGRA_GPIO(TEGRA_GPIO_BANK_ID_B, 4) // SODIMM pin 104, GPIO3_PB.04
#define SW1_IN_DIRECTION e_INPUT
#define SW1_IN_LEVEL e_BOTH
// SW2
#define SW2_IN TEGRA_GPIO(TEGRA_GPIO_BANK_ID_B, 6) // SODIMM pin 106, GPIO3_PB.06
#define SW2_IN_DIRECTION e_INPUT
#define SW2_IN_LEVEL e_BOTH
// VOLUP
#define VOLUP_IN TEGRA_GPIO(TEGRA_GPIO_BANK_ID_B, 5) // SODIMM pin 108, GPIO3_PB.05
#define VOLUP_IN_DIRECTION e_INPUT
#define VOLUP_IN_LEVEL e_BOTH
// VOLDN
#define VOLDN_IN TEGRA_GPIO(TEGRA_GPIO_BANK_ID_B, 7) // SODIMM pin 110, GPIO3_PB.07
#define VOLDN_IN_DIRECTION e_INPUT
#define VOLDN_IN_LEVEL e_BOTH
// ID0
#define ID0_IN TEGRA_GPIO(TEGRA_GPIO_BANK_ID_G, 0) // SODIMM pin 203, GPIO3_PG.00
#define ID0_IN_DIRECTION e_INPUT
// ID1
#define ID1_IN TEGRA_GPIO(TEGRA_GPIO_BANK_ID_G, 1) // SODIMM pin 205, GPIO3_PG.01
#define ID1_IN_DIRECTION e_INPUT
// ID2
#define ID2_IN TEGRA_GPIO(TEGRA_GPIO_BANK_ID_G, 2) // SODIMM pin 207, GPIO3_PG.02
#define ID2_IN_DIRECTION e_INPUT
// Laser Disable
#define LASDIS_OUT TEGRA_GPIO(TEGRA_GPIO_BANK_ID_V, 0) // SODIMM pin 206, GPIO3_PV.00
#define LASDIS_OUT_DIRECTION e_OUTPUT
// NANOSW
#define NANOSW_IN TEGRA_GPIO(TEGRA_GPIO_BANK_ID_Z, 0) // SODIMM pin 216, GPIO3_PZ.00
#define NANOSW_IN_DIRECTION e_INPUT
// Speaker Enable
#define SPKREN_OUT TEGRA_GPIO(TEGRA_GPIO_BANK_ID_Y, 2) // SODIMM pin 218, GPIO3_PY.02
#define SPKREN_OUT_DIRECTION e_OUTPUT
// PWRSW
#define PWRSW_IN TEGRA_GPIO(TEGRA_GPIO_BANK_ID_X, 5) // SODIMM pin 240, GPIO3_PX.05
#define PWRSW_IN_DIRECTION e_INPUT

// A LOT OF UNUSED GPUO!!
// GPIO @ pin 89 NOT USED
#define GPIO_PIN89 TEGRA_GPIO(TEGRA_GPIO_BANK_ID_C, 0) // SODIMM pin 89, GPIO3_PC.00
#define GPIO_PIN89_DIRECTION e_INPUT
// GPIO @ pin 91 NOT USED
#define GPIO_PIN91 TEGRA_GPIO(TEGRA_GPIO_BANK_ID_C, 2) // SODIMM pin 91, GPIO3_PC.02
#define GPIO_PIN91_DIRECTION e_INPUT
// GPIO @ pin 93 NOT USED
#define GPIO_PIN93 TEGRA_GPIO(TEGRA_GPIO_BANK_ID_C, 1) // SODIMM pin 93, GPIO3_PC.01
#define GPIO_PIN93_DIRECTION e_INPUT
// GPIO @ pin 95 NOT USED
#define GPIO_PIN95 TEGRA_GPIO(TEGRA_GPIO_BANK_ID_C, 3) // SODIMM pin 95, GPIO3_PC.03
#define GPIO_PIN95_DIRECTION e_INPUT
// GPIO @ pin 97 NOT USED
#define GPIO_PIN97 TEGRA_GPIO(TEGRA_GPIO_BANK_ID_C, 4) // SODIMM pin 97, GPIO3_PC.04
#define GPIO_PIN97_DIRECTION e_INPUT
// GPIO @ pin 88 NOT USED
#define GPIO_PIN88 TEGRA_GPIO(TEGRA_GPIO_BANK_ID_C, 6) // SODIMM pin 88, GPIO3_PC.06
#define GPIO_PIN88_DIRECTION e_INPUT
// GPIO @ pin 118 NOT USED
#define GPIO_PIN118 TEGRA_GPIO(TEGRA_GPIO_BANK_ID_S, 5) // SODIMM pin 118, GPIO3_PS.05
#define GPIO_PIN118_DIRECTION e_INPUT
// GPIO @ pin 195 NOT USED
#define GPIO_PIN195 TEGRA_GPIO(TEGRA_GPIO_BANK_ID_J, 5) // SODIMM pin 195, GPIO3_PJ.05
#define GPIO_PIN195_DIRECTION e_INPUT

hello sgroesz,

here’s re-definition that might got confused.
for example,
$L4T_Sources/r32.5.1/Linux_for_Tegra/source/public/kernel/kernel-4.9/include/dt-bindings/gpio/tegra-gpio.h

48  #define TEGRA_GPIO(port, offset) \
49  	((TEGRA_GPIO_PORT_##port * 8) + offset)

there’s marco for TEGRA_GPIO(), and the pin, GPIO3_PG.00 should be defined as TEGRA_GPIO(G, 0) in the code.
please have a try,
thanks