Jetson Nano (SD DevBoard) 32.5.1 PinMux Changes?

I have followed the instructions to use the Excel sheet to modify the PinMux for the Jetson Nano. Since we eventually will move off of a DevBoard we are using the full PinMux file and not the 40 Pin one.

I copy the files into the Linux dev box under the hardware source tree and run:
make ARCH=arm64 tegra_defconfig
make ARCH=arm65 dtbs

then I copy the arch/arm64/boot/dts/tegra210-p3448-0000-p3449-0000-b00.dtb to the kernel/dtb/

then I run jetson-disk-image-creator,sh -b jetson-nano -r 300

This creates an image that I can flash onto the sd card and boot the Jetson Nano with.

However the GPIO pins do not behave as we expect them to and if I inspect the /proc/device-tree/ with dtc I see very different configurations then what we are expecting, but they seem to match the signals we see on the board.

The easy check is that we disable Pin8 in our PinMux but it is still being pulled up after inserting the SD card and booting.

I feel like I am missing a piece of the puzzle here or not understanding how to tell if our changes are working. (Our pin is not being pulled to 0 when it has an external source so that much is definitely still broken. The same circuit works on a RPi)

I did try another document that explained how to change the u-boot configuration and recompile it with the csv. I tried this and still no change, but I was reading that u-boot changes don’t need to be made in 32.5, is this true?

I would really appreciate some help with this.

hello joseph-jonathan.salzano,

you may Flashing a Specific Partition instead of flashing the whole device by using the command line, ‑k switch.
for example,
it’s $ sudo ./flash.sh -k DTB ... to update device tree blob for the Nano platforms.

Make sure the /boot/extlinux/extlinux.conf file in your image doesn’t have an FDT entry or that you copy your customized tegra210-p3448-0000-p3449-0000-b00.dtb to /boot/ in the image and set the FDT entry to point to it.

We were not using the flash script because we don’t currently have the 5V jack. We were doing all of our flashing to the SD card and then inserting it into the DevBox.

Is this the issue? Do I have to use the flash script for this to work? I have a 5V jack ordered and will try again when it gets here.

The custom dtb file is deffinitly in /boot/ and I can uncompile it and confirm it is the one I generated with the PinMux spreadsheet. I don’t see an FDT entry in extlinux.conf either. I will try and add it. I didn’t see this step anywhere in the user guides for PinMux. Is this something that I should just know? Linux Kernel building is a relatively new area for me personally.

This could also be the issue. R32.5 changes the default location for the bootloader files from the SDcard to the internal 4MB QSPI-NOR flash. If you’re flashing to an SDcard connected to the host, you won’t be loading your DTB. Use parted ( or another partitioning tool ) to look at the layout of the SDcard and post the result here.

Given the above, adding the FDT entry will probably fix the issue for you. Just having it in /boot doesn’t do anything by itself.

I was able to get the flash.sh script to flash my Jetson Nano. I had to switch to a different USB chord before it would detect my devboard.

Anyway, I performed the flash and the cat of /proc/device-tree/nvidia,dtsfilename still shows the one from git-master_linux and not the one that I generated. The dtbbuildtime also still shows February when my dtb was built today. I used a multimeter and I am still seeing 3.3V on pin 8 which we disabled.

I then edited the extlinux.conf file to include:
FTD /boot/tegra210-p3448-0000-p3349-0000-b00.dtb

I rebooted the Jetson and when it comes back up the extlinux file is still changed but nothing else has. The /proc/device-tree/ values are the same and I still see 3.3V on pin8

hello joseph-jonathan.salzano,

you have a typo, it should be FDT.
please also check kernel logs to confirm which device tree is used,
for example, $ dmesg | grep DTS

Sorry that was a typo on the forum. I doublechecked and I do have FDT on the Jetson.

The output from dmesg | grep DTS is:

[    0.232824] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-b00.dts
[    0.445082] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-b00.dts

I think we need to see the bootloader messages from the UART/TCU port on the front panel header.

Very early in the bootloader process you should see something like…

[0001.761] Debug Init done
[0001.764] Marked DTB cacheable
[0001.767] Bootloader DTB loaded at 0x83000000
[0001.772] Marked DTB cacheable
[0001.774] Kernel DTB loaded at 0x83100000
[0001.778] DeviceTree Init done

Then just before u-boot starts the kernel, you should see…

## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
ERROR: reserving fdt memory region failed (addr=0 size=0)
ERROR: reserving fdt memory region failed (addr=0 size=0)
   Using Device Tree in place at 0000000083000000, end 000000008303e659
copying carveout for /host1x@50000000/dc@54200000...
copying carveout for /host1x@50000000/dc@54240000...

If you see Flattened Device Tree blob at 83000000 like above, then the kernel is using the FDT that was supplied in the extlinux.conf file. If you see address 83100000, then it’s using the one c-boot loaded from the QSPI-NOR flash.

Either way, check for error messages.

but both the one on QSPI and the FDT one should be the same right?

How do you get the bootloader messages?

hello joseph-jonathan.salzano,

according to comment #11, it seems kernel still uses the default device tree blob instead of yours.
btw, you should follow https://www.jetsonhacks.com/2019/10/10/jetson-nano-uart/ to setup serial console to gather bootloader messages.
thanks

I don’t have access to extra hardware right now. Getting a 5V jack was hard enough where I am right now. So I won’t be able to get the bootloader messages for at least a couple weeks.

However, I want to make sure that my steps are correct to change the PinMux because so far it seems that the documentation isn’t complete if we have to be changing the extlinux.conf file.

If we have a brand new environment this is what I assumed has to happen:

  1. Make changes to NV_Jetson_Nano_Module_Pinmux_Config_Template.xlsm
  2. Generate the DT file with the button in excel
  3. Copy tegra210-jetson_nano_module-gpio-default.dtsi to Linux_for_Tegra/sources/hardware/nvidia/platform/t210/porg/kernel-dts/porg-platforms/tegra210-porg-gpio-p3448-0000-b00.dtsi
  4. Copy ‘tegra210-jetson_nano_module-pinmux.dtsi’ to Linux_for_Tegra/sources/hardware/nvidia/platform/t210/porg/kernel-dts/porg-platforms/tegra210-porg-pinmux-p3448-0000-b00.dtsi
  5. In Linux_for_Tegra/sources/kernel/kernel-4.9/ run:
    make ARCH=arm64 tegra_defconfig
    make ARCH=arm65 dtbs
    
  6. Copy Linux_for_Tegra/sources/kernel/kernel-4.9/arch/arm64/boot/dts/tegra210-p3448-0000-p3449-0000-b00.dtb to Linux_for_Tegra/kernel/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb
  7. run sudo ./flash.sh jetson-nano-qspi-sd mmcblk0p1
  8. Boot the Jetson Nano
  9. The disabled pin #8 should read 0V
  10. The value of /proc/device-tree/nvidia,dtbbuildtime should read the day I built the kernel
  11. The value of /proc/device-tree/nvidia,dtsfilename should show my directory structure

Are these steps correct? This seems to be what is required from reading the documentation. If I am missing a step can you tell me so I can try it while I wait to get access to a serial cable?

You’d think so.

They appear to be but lets test a few things…

In the L4T/bootloader directory, you should see these files…
kernel_tegra210-p3448-0000-p3449-0000-b00.dtb
kernel_tegra210-p3448-0000-p3449-0000-b00.dtb.sb
tegra210-p3448-0000-p3449-0000-b00.dtb

The .sb file should be the dtb file you compiled. Make sure it is.
The two .dtb files are the signed versions.

If you do hexdump -Cn1500 on the .sb file you should see something like…

00000000  d0 0d fe ed 00 03 b6 5a  00 00 00 48 00 03 6f bc  |.......Z...H..o.|
00000010  00 00 00 28 00 00 00 11  00 00 00 10 00 00 00 00  |...(............|
00000020  00 00 46 9e 00 03 6f 74  00 00 00 00 80 00 00 00  |..F...ot........|
00000030  00 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 01 00 00 00 00  |................|
00000050  00 00 00 03 00 00 00 48  00 00 00 00 6e 76 69 64  |.......H....nvid|
00000060  69 61 2c 70 33 34 34 39  2d 30 30 30 30 2d 62 30  |ia,p3449-0000-b0|
00000070  30 2b 70 33 34 34 38 2d  30 30 30 30 2d 62 30 30  |0+p3448-0000-b00|
00000080  00 6e 76 69 64 69 61 2c  6a 65 74 73 6f 6e 2d 6e  |.nvidia,jetson-n|
00000090  61 6e 6f 00 6e 76 69 64  69 61 2c 74 65 67 72 61  |ano.nvidia,tegra|
000000a0  32 31 30 00 00 00 00 03  00 00 00 04 00 00 00 0b  |210.............|
000000b0  00 00 00 01 00 00 00 03  00 00 00 04 00 00 00 1c  |................|
000000c0  00 00 00 02 00 00 00 03  00 00 00 04 00 00 00 2b  |...............+|
000000d0  00 00 00 02 00 00 00 03  00 00 00 15 00 00 00 37  |...............7|
000000e0  46 65 62 20 32 36 20 32  30 32 31 00 32 32 3a 35  |Feb 26 2021.22:5|
000000f0  34 3a 34 36 00 00 00 00  00 00 00 03 00 00 00 05  |4:46............|

That;s the start of a normal dtb file.

If you do hexdump -Cn1500 on each of the dtb files, you should see something like…

00000000  00 00 00 00 44 54 42 00  60 ba 03 00 00 00 00 00  |....DTB.`.......|
00000010  b1 ba ef be ad de ed fe  aa aa aa aa aa aa aa aa  |................|
00000020  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
...
00000450  00 00 00 03 00 00 00 48  00 00 00 00 6e 76 69 64  |.......H....nvid|
00000460  69 61 2c 70 33 34 34 39  2d 30 30 30 30 2d 62 30  |ia,p3449-0000-b0|
00000470  30 2b 70 33 34 34 38 2d  30 30 30 30 2d 62 30 30  |0+p3448-0000-b00|
00000480  00 6e 76 69 64 69 61 2c  6a 65 74 73 6f 6e 2d 6e  |.nvidia,jetson-n|
00000490  61 6e 6f 00 6e 76 69 64  69 61 2c 74 65 67 72 61  |ano.nvidia,tegra|
000004a0  32 31 30 00 00 00 00 03  00 00 00 04 00 00 00 0b  |210.............|
000004b0  00 00 00 01 00 00 00 03  00 00 00 04 00 00 00 1c  |................|
000004c0  00 00 00 02 00 00 00 03  00 00 00 04 00 00 00 2b  |...............+|
000004d0  00 00 00 02 00 00 00 03  00 00 00 15 00 00 00 37  |...............7|
000004e0  46 65 62 20 32 36 20 32  30 32 31 00 32 32 3a 35  |Feb 26 2021.22:5|
000004f0  34 3a 34 36 00 00 00 00  00 00 00 03 00 00 00 05  |4:46............|

The first part is the signature, then at offset 00000450 should be the start of the dtb which should look exactly like the dump from the .sb file.

So I’d verify those first.

Then , on the running nano run the following commands…

sudo mtdpart add /dev/mtd0 RP1 851968 327680
sudo mtdpart add /dev/mtd0 DXB 2555904 327680
cat /proc/mtd

Those commands will create device nodes in /dev for the two partitions in the QSPI-NOR flash that contain the dtb.

Now run…

hexdump /Cn1500 /dev/mtd1
hexdump /Cn1500 /dev/mtd2

Both partition contents and both .dtb files should match exactly.