Jetson AGX Orin - GPIO reconfiguration

[joseph.thomas]

I’m working with an Avermedia kit based on Jetson AGX Orin 64G and need to reconfigure the 40-pin GPIO. Currently, while checking the pin status using gpioinfo, I found that some pins are set as Input instead of Output. I need these pins to function as outputs and also need to reconfigure some pins back to GPIO.

I used the pinmux sheet from the NVIDIA site to generate the three .dtsi files. I also downloaded the BSP provided by Avermedia for the kit.

I’m not sure how to proceed from here. Could you please guide me on the next steps to configure the GPIO correctly?

I found two types of files, one is pinmux.dtsi and other gpio.dtsi
As shown in the below, table I need to reconfigure these pins.

[carolyuu]

*** Please note that this reply is generated by LLM automatically ***

To reconfigure the 40-pin GPIO on your Avermedia kit based on the Jetson AGX Orin, you need to follow these steps:

1. Verify the pinmux configuration files: You have already generated the pinmux.dtsi, gpio.dtsi, and padvoltage.dtsi files using the pinmux sheet from the NVIDIA site. Make sure these files are correct and reflect the changes you want to make.

2. Understand the difference between pinmux.dtsi and gpio.dtsi: The pinmux.dtsi file configures the pinmux settings, which determine how the pins are used (e.g., as GPIO, I2C, SPI, etc.). The gpio.dtsi file configures the GPIO settings, which determine the direction and state of the GPIO pins.

3. Modify the pinmux.dtsi file: Open the pinmux.dtsi file and modify the pinmux settings for the pins you want to reconfigure. For example, if you want to change a pin from being used as an I2C pin to a GPIO pin, you need to update the pinmux setting accordingly.

4. Modify the gpio.dtsi file: Open the gpio.dtsi file and modify the GPIO settings for the pins you want to reconfigure. For example, if you want to change a pin from being an input to an output, you need to update the GPIO setting accordingly.

5. Copy the modified files to the correct directories: Copy the modified pinmux.dtsi file to the <l4t_top>/bootloader/generic/BCT/ directory, and copy the modified gpio.dtsi file to the <l4t_top>/bootloader/ directory.

6. Reflash the board: Reflash the board with the updated pinmux and GPIO configuration files. This will apply the changes you made to the pinmux and GPIO settings.

7. Verify the changes: After reflashing the board, verify that the pinmux and GPIO settings have been updated correctly. You can use the cat /sys/kernel/debug/gpio command to check the GPIO settings.

Regarding the BSP provided by Avermedia, you may need to integrate the modified pinmux and GPIO configuration files into the BSP. This may involve updating the BSP’s configuration files or rebuilding the BSP with the modified pinmux and GPIO configuration files.

Here’s a comparison of the two types of files:

File	Description
pinmux.dtsi	Configures the pinmux settings, which determine how the pins are used (e.g., as GPIO, I2C, SPI, etc.).
gpio.dtsi	Configures the GPIO settings, which determine the direction and state of the GPIO pins.

In your case, you need to modify both files to reconfigure the pins correctly. The pinmux.dtsi file will determine how the pins are used, and the gpio.dtsi file will determine the direction and state of the GPIO pins.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

[joseph.thomas]

Hi Carolyuu,

I need some clarification regarding the configuration of GPIO pin 7 (GPIO_PQ.06) on the device. Please find the details below:

1. I want to use GPIO pin 7 (GPIO_PQ.06) as an output GPIO instead of its default clock function.

2. When I initially tested the pin using the Python GPIO library, I observed a voltage of about 1.4–1.5 V, and I couldn’t control or toggle the pin state.

3. Because of that, I checked the Pinmux sheet and started editing the configuration to set the pin as a GPIO.

4. After generating the updated files, the AverMedia team advised me not to directly copy the generated .dtsi files, but instead to:

   • Download the corresponding BSP from the AverMedia website,

   • Edit the .dtsi files within the BSP based on the generated configuration, and

   • Then reflash the device.

5. While editing the BSP’s .dtsi files, I got confused because:

   • Some entries contain lines like nvidia,function = "rsvd0", and I’m unsure what those mean in this context.

   • I couldn’t locate GPIO_PQ.06 directly; I only found references to pq6.

6. When comparing the generated gpio.dtsi file with the one inside the AverMedia BSP, I noticed that some lines were added or removed, which made it unclear how to merge or apply the correct changes.

7. Additionally, I’m unable to map the notations and naming used in gpio.dtsi to the actual 40-pin GPIO header, so I’m not certain which pin corresponds to which GPIO in the device tree.

Could you please help clarify how to correctly configure GPIO_PQ.06 as an output GPIO, and how to properly map and edit the dtsi entries based on the BSP structure?

[KevinFFF]

Hi joseph.thomas,

What’s the Jetpack version in use?

As you are using the custom carrier board, the default pinmux spreadsheet from our side may not work for your board. Could you request the pinmux spreadsheet from your vendor?

@joseph.thomas

After generating the updated files, the AverMedia team advised me not to directly copy the generated .dtsi files, but instead to:

• Download the corresponding BSP from the AverMedia website,
• Edit the .dtsi files within the BSP based on the generated configuration, and
• Then reflash the device.

Yes, they are the expected flow to update their pinmux and gpio configurations.
You have to modify the custom pinmux/gpio dtsi shared from them.

@joseph.thomas

Some entries contain lines like nvidia,function = "rsvd0", and I’m unsure what those mean in this context.

Actually, you can also get a default pinmux spreadsheet from our side and configure the pin with your requirement. After you generate the pinmux/gpio dtsi, you could check those 2 dtsi to find where your changes are included.

@joseph.thomas

Additionally, I’m unable to map the notations and naming used in gpio.dtsi to the actual 40-pin GPIO header, so I’m not certain which pin corresponds to which GPIO in the device tree.

You can also refer to 3.3 Carrier Board Custom Connectors 40-Pin Expansion Header in NVIDIA Jetson AGX Orin Developer Kit Carrier Board Specification for their mapping.
If your custom carrier board has different usage, please also refer to the documentation shared from your vendor first.

[joseph.thomas]

Hi Kevin,

I reached out to Avermedia, but they mentioned that a separate pinmux sheet isn’t available — we need to use the one provided by NVIDIA.

Could you please explain how to modify the pinmux.dtsi file to configure specific pins as outputs on the Jetson AGX Orin?

I need to set pins 7, 12, 13, and 32 as GPIO outputs to drive LEDs, with a target output of 3.3V.

		soc_gpio33_pq6 {
			nvidia,pins = "soc_gpio33_pq6";
			nvidia,function = "rsvd0";
			nvidia,pull = <TEGRA_PIN_PULL_UP>;
			nvidia,tristate = <TEGRA_PIN_DISABLE>;
			nvidia,enable-input = <TEGRA_PIN_DISABLE>;
			nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
			nvidia,lpdr = <TEGRA_PIN_DISABLE>;

The section shown above is a small portion of the pinmux.dtsi file, where “pq6” corresponds to pin 7 on the 40-pin GPIO header.

I’d like to know which lines need to be modified to configure this pin as an output, so that it provides 3.3V for high and 0V for low.

Additionally, there’s another file called gpio.dtsi — I’m unsure about its role. Do I need to add this pin under any specific function in that file?

[KevinFFF]

@joseph.thomas

I reached out to Avermedia, but they mentioned that a separate pinmux sheet isn’t available — we need to use the one provided by NVIDIA.

Sorry that I’m not clear about this.
The default pinmux spreadsheet provided from us is for the devkit.
As you are using the custom carrier board, you have to use the one provided by your vendor(Avermedia).
There must be custom design and we don’t know about them.

For PQ.06, you can configure it as following(Output/Drive 0) in pinmux spreadsheet.

It will result the following node in pinmux.dtsi.

			soc_gpio33_pq6 {
				nvidia,pins = "soc_gpio33_pq6";
				nvidia,function = "rsvd0";
				nvidia,pull = <TEGRA_PIN_PULL_NONE>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_DISABLE>;
				nvidia,io-high-voltage = <TEGRA_PIN_DISABLE>;
				nvidia,lpdr = <TEGRA_PIN_DISABLE>;
			};

And also, the following line in gpio.dtsi.

	gpio@2200000 {
		gpio-init-names = "default";
		gpio-init-0 = <&gpio_main_default>;

		gpio_main_default: default {
			gpio-output-low = <
+				TEGRA234_MAIN_GPIO(Q, 6)

[joseph.thomas]

Hi Kevin
I’ve reached out to AVerMedia regarding the custom design.
Meanwhile, I edited the pinmux.dtsi and gpio.dtsi files as per your earlier example (PQ.06) as output.

Then, I tried controlling the output using the following commands:

sudo gpioset gpiochip0 106=1 # Pin 7 high
sudo gpioset gpiochip0 106=0 # Pin 7 low

Initially, the pin successfully went high to 3.3 V, but when set low, it only dropped to 1.5 V.
After that, when I tried setting it high again, the voltage rose only to 1.6 V, and from that point
-onward, it kept toggling between 1.5 V and 1.6 V for high and low states, without ever returning to 0 V or going high to 3.3 V.

[KevinFFF]

@joseph.thomas

After that, when I tried setting it high again, the voltage rose only to 1.6 V, and from that point
-onward, it kept toggling between 1.5 V and 1.6 V for high and low states, without ever returning to 0 V or going high to 3.3 V.

Could you share the result of the following command at this moment?

$ sudo busybox devmem 0x02430070

[joseph.thomas]

$ sudo busybox devmem 0x02430070

$ 0x00000000

[KevinFFF]

Could you apply the patch from the following thread to check if it could help?
40hdr - SPI1 gpio padctl register bit[10] effect by gpiod tools in JP6 - #20 by KevinFFF

Please also get a scope to measure the signal instead of using the multimeter for its voltage.

[joseph.thomas]

Hi Kevin,

Could you please clarify where exactly we need to apply this patch?

[joseph.thomas]

Also, could you please clarify the recommended oscilloscope settings for measuring the output from the Jetson — specifically the impedance, probe setup (such as attenuation), and any other relevant parameters?

[KevinFFF]

@joseph.thomas

Could you please clarify where exactly we need to apply this patch?

What’s your Jetpack version in use?

Please refer to Kernel Customization — NVIDIA Jetson Linux Developer Guide to sync and build kernel source first.

[joseph.thomas]

Hi Kevin,

We’re using JetPack 6.2.

Could you please share the recommended oscilloscope settings?

Also, could you clarify the maximum resistive and capacitive load the GPIO pins can drive?

[ChrisB_NV]

@joseph.thomas

I need to set pins 7, 12, 13, and 32 as GPIO outputs to drive LEDs, with a target output of 3.3V.

These four pins have an I/O voltage of 1.8V on the AGX Orin module. Does the custom carrier board level shift them to 3.3V? Without a level shifter on the carrier, these pins directly from Jetson AGX Orin can only drive up to 1.8V. Are you trying to directly drive the LEDs from the pins or use the pins to control FETs to turn on the LEDs?

[joseph.thomas]

1. The custom carrier board uses the TXB0108DQSR level shifter to convert the Jetson’s 1.8 V GPIO signals to 3.3 V.
2. For driving 5 V LEDs, we use a custom interfacing circuit that further level-shifts the 3.3 V signal to 5 V.
3. A 100 pF filter capacitor is placed at the input of the 5 V level-shifting stage for signal stability.