GPIO issues in Jetpack 6.0 with Linux 36.3

Continuing the discussion from How to dynamically set GPIO in Jetpack 6.0DP

Yesterday I flashed the newest Jetpack release (36.3) on a Jetson Orin AGX 32GB, and I still cannot dynamically set the GPIO pins as in the aforementioned thread. In Jetpack 5.0, this worked with both the /sys/class/gpio interface and the gpioset commands.

In Jetpack 6, the /sys/class/gpio interface has been removed, and the gpioset commands do not work. I had previously tested the Jetpack 6.0 (36.2) release, and it did not work there either.

My understanding is that Jetpack 6.0 (36.3) production release. As such, I would expect the GPIO ports to be useable out of the box, or to be easily enabled via sdkmanager or something similar.

Please provide us detailed instructions for how to enable the GPIO pins on the Orin AGX. In my particular case, I just want to expose the GPIO09 (pin 32) in this diagram:


Source:

1 Like

What do you mean with enable or expose?
This pin is by default configured as a GPIO pin as shown in the pinmux spreadsheet.

I have 3 of the same Jetson Orin AGX 32GB machines on my desk.

I had Jetpack 5 on 2 of them, and Jetpack 6 (36.2) on one of them. A colleague told me that the GPIO outputs where not working on his Jetpack 6 device. I tried it on my Jetpack 6 device, and confirmed that it indeed was not working. It did, however, work on the Jetpack 5 devices. This is the script I used to test the GPIO output:

#!/bin/bash
# Define the gpiochip and correct line number
GPIOCHIP="gpiochip1"
GPIOLINE=8  # Adjust this based on `gpioinfo` output

# Run for 10 seconds
END=$(($(date +%s) + 10))
while [ $(date +%s) -lt $END ]; do
    # Set GPIO high
    sudo gpioset --mode=time -u 100000 $GPIOCHIP $GPIOLINE=1

    # Set GPIO low
    sudo gpioset --mode=time -u 100000 $GPIOCHIP $GPIOLINE=0
done

When I say that the GPIO was “working” on Jetpack 5, but not 6, I mean that I hooked up the oscillioscope to the pin in question (pin 32), and see the nice square wave on Jetpack 5, but nothing on Jetpack 6.

For documentation sake, I am getting the GPIOCHIP and LINE by first looking at the PIN diagram on page 32 here:

Jetson_AGX_Orin_DevKit_Carrier_Board_Specification_SP-10900-001_v1.1.pdf (1.1 MB)

which indicates that PIN 32 is called GPIO09. Page 34 of that document indicates that GPIO09 is SoC GPIO
Port # PBB.00. gpioinfo then tells us this:

...
gpiochip1 - 32 lines:
...
	line   8:     "PBB.00"       unused   input  active-high

As I mention, this works in the Jetpack 5 devices, but not the Jetpack 6 devices.

In the process of investigating, I came across this post, where the moderator says that the pinmux needs to be manually changed, and the device reflashed: How to dynamically set GPIO in Jetpack 6.0DP

To investigate further, I flashed one of my Jetpack 5 devices with Jetpack 6 (specifically the new production release 36.3). So now I have 3 different devices to test. The outputs of cat /etc/nv_tegra_release look like
:

# R35 (release), REVISION: 2.1, GCID: 32413640, BOARD: t186ref, EABI: aarch64, DATE: Tue Jan 24 23:38:33 UTC 2023
# R36 (release), REVISION: 2.0, GCID: 35084178, BOARD: generic, EABI: aarch64, DATE: Tue Dec 19 05:55:03 UTC 2023
... 
# R36 (release), REVISION: 3.0, GCID: 36106755, BOARD: generic, EABI: aarch64, DATE: Thu Apr 25 03:14:05 UTC 2024
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

The aforementioned script works on the Jetpack 5 device, but fails on both of these Jetpack 6 devices. By that I mean that the oscilloscope output is flat.

One thing that I find peculiar is that on the Jetpack 6 devices, the gpioinfo output seems to indicate that it should be working. But the oscilloscope output is flat. Specifically, under normal conditions,

matt@ubuntu:~$ gpioinfo | grep PBB.00
line 8: “PBB.00” unused input active-high

But when I run the script, then I see that change to :

matt@ubuntu:~$ gpioinfo | grep PBB.00
line 8: “PBB.00” “gpioset” output active-high [used]

1 Like

There’s nothing you need to investigate at all.
You need to modify the pinmux spreadsheet to make the pin you want to use an output pin.
That is required on JetPack 6 because GPIO sysfs has been removed.

This is meaningless. Please just ignore it.
It says output but the pin is still an input pin.

Then you should know how to modify it by reading the post.

Googling JetPack 6 GPIO gives you a great bunch of posts indicating why this does not work and what you should do to make this work.

I do not get any good hits when googling “JetPack 6 GPIO”. Please provide a link for blog post that you think is relevant. I am not finding any good documentation from Nvidia for what I am supposed to do here.

You need this:
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html#pinmux-changes

The first sentence in this link is

If your board schematic differs from the schematic for the Jetson AGX Orin Developer Kit board, you must change the pinmux configuration applied by the software.

I don’t know what is meant by board schematic, but I am not using any customer hardware. I have an unmodified Orin AGX that I flashed with 36.3, and the GPIO pins seem to be disabled by default. It seems to me like either there is a bug, or this documentation is wrong.

You just change the input/output direction of whatever pins you want to use…
Nothing complicated at all, dude.

I understand that. I am trying to get this done. The issue I have is that the default behavior changed on the Orin boards, and it seems to me to be a bug that these pins are now disabled for output by default.

I also do not have Excel, and this does not work in LibreOffice. So now I have to search for a program that works with the macros in your Excel file.

Edit: This spreadsheet won’t work in OnlyOffice either or Free WPS Office

It’s 100% not a bug, dude… Or do you want me to emphasize it again?
A pin can only be either input or output at a time because there is no sysfs driver handling the change dynamically now.

YES, that spreadsheet only works with Excel on Windows.

I’m having the same issue controlling GPIO 7 in Jetpack 6. Using the same pinmux I generated that was woking in Jetpack 5. GPIO 13 appears to be working.

So I need a Windows license and a Microsoft Office Desktop license to enable all of the features on my Orin if I want to use Jetpack 6? That sounds like a bug to me. I have neither of those, and I don’t see those mentioned anywhere in the documentation.

2 Likes

I don’t consider it a bug.

For documentation purposes and other people that come across this, I have tried updating the pinmux template

https://developer.nvidia.com/embedded/secure/jetson/agx_orin/jetson_agx_orin_pinmux_config_template.xlsm

It does not work in:

  • Ubuntu 22 using LibreOffice, WPS Office (free), and OnlyOffice
  • Google Sheets
  • the default Excel version that is installed on a Windows 10 Intel NUC

@DaveYYY In the link you provide, it says that we can also modify the pin dynamically. For that we need to know the pin register. In my specific case, I want to modify GPIO09. But in the TRM, I don’t see any mention of that specific pin. There are entries for PADCTL_G3_SOC_GPIO35_0 and some others, but not 09. Could you please tell me how to find the offset for that?

I am looking in Orin-TRM_DP10508002_v1.2p.pdf from here:

Specifically, it seems like it should be listed in the section “8.4.4 G3 PAD Control Registers”.

I doubt we can just interpolate the offset because right before

PADCTL_G3_SOC_GPIO23_0
Offset: 0x20

is

PADCTL_G3_CAM_I2C_SCL_0
Offset: 0x18

Hi,

From the pinmux spreadsheet, you can find that the complete pin name of GPIO09 is CAN1_STB.
It’s stated in page 6382 and 6382 in TRM, named PADCTL_AO_HV_CAN1_STB_0, and with an offset of 0x40.
From page 6085, you can see the base address block of AO_HV is PADCTL_A15.
Finally, you can see from page 73 that the base address of PADCTL_A15 is 0x0c303000, so you have 0x0c303000 + 0x40 = 0x0c303040

However, please keep in mind that any changes done via directly modifying registers will be lost after reboot.
So you still need to do it with the excel spreadsheet if you want changes to be persistent.

Thank you. This was very helpful.

For anyone else that comes across this… I guess my eyes are bad. I was using the base address of

PADCTL_A0 0x02430000

from page 57, which is wrong in my case. Anyways. Problem solved.

Hi DaveYYY,

maybe the Nvidia Team does not consider this a Bug. But looking thru the Developer Forum, I see many Threads like this, where apparently people are struggling to get the Pinmux to work.
I mean what kind of Process is this, that you first need Windows to run Excel and then Ubuntu to run the Flashing Script or the SDK Manager. It seems like it is just not well thought threw. Also Releasing Jetpack 6 as a Production release without the implementation of the Linux pinctrl APIs is also not the best practice is my opinion.

Plus the Info you get from the gpioinfo command, that is apparently not Valid, is also very misleading.

Maybe Nvidia should get the message and implement some other tool. I understand that SYSFS is deprecated, but something like the jetson-io.py Tool, that can be directly Executed on the Hardware would be really helpful.

And for example, on my Jetson Nano, using libgpiod to get Interrupts on a GPIO, i did not needed to go thru this kind of process, on my Orin i have to.

I would be happy if you could direct this Feedback to your Developers.

Thanks and Best Regards
Tim

10 Likes