How to dynamically set GPIO in Jetpack 6.0DP

There is no gpio folder under the /sys/class/ directory. The old methods don’t seem to be working now. Is there any other way to dynamically set gpio?

please use gpiod instead.
https://kernel.googlesource.com/pub/scm/libs/libgpiod/libgpiod/+/v0.2.x/README.md

I’m not sure how to use libgpiod on jetson, can you give me an example?

There are lots of resources on the Internet, you could search it first.

What should I set OFFSET to in libgpiod? If I want to change gpio03.

Use gpiodetect and gpioinfo to find out your offset first.

This is my code for using libgpiod:
aimec@aimec-desktop:~$ python3
Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] on linux
Type “help”, “copyright”, “credits” or “license” for more information.
>>> import gpiod
>>> chip = gpiod.Chip(‘gpiochip1’)
>>> line = chip.get_line(13)
>>> line.request(consumer=‘my_gpio0’,type=gpiod.LINE_REQ_DIR_OUT)
>>> line.set_value(1)

This is the changed state of gpioinfo:
line 13: “PCC.01” “my_gpio0” output active-high [used]

But the actual gpio output has not changed. What am I doing wrong? I’d appreciate it if you could tell me and correct me.

Are you talking about the gpioinfo shows correct info but the signal from gpio is not correct?

That’s what I mean.

Please check /sys/kernel/debug/gpio and see if your gpio is in correct state

We’re experiencing the same issue. Using gpioset we are able to toggle the pin on and off (as shown in /sys/kernel/debug/gpio) but the voltage on the corresponding pin does not change. Strangely, on an oscilloscope we see occasional state changes and pulses on PP.04, regardless of the commanded state of the pin.

  1. Is it possible to re-enable the sysfs interface?
  2. Is there any special driver initialization or configuration needed for the gpiod interface to work?
  3. Were there significant changes made to the device tree that prevent correct operation of the GPIO?

As described by table 3-4 in Jetson_AGX_Orin_DevKit_Carrier_Board_Specification_SP-10900-001_v1.0.pdf, PP.04 corresponds to pin 22 on the header. We are using the following commands to cycle this pin, the offset of which (96) we found as per this guide.

gpioset --mode=time -s 1 /dev/gpiochip0 96=1
gpioset --mode=time -s 1 /dev/gpiochip0 96=0

When commanded high, we see this in /sys/kernel/debug/gpio:

 gpio-437 (PN.05               )
 gpio-438 (PN.06               )
 gpio-439 (PN.07               )
 gpio-440 (PP.00               )
 gpio-441 (PP.01               )
 gpio-442 (PP.02               )
 gpio-443 (PP.03               )
 gpio-444 (PP.04               |gpioset             ) out hi 
 gpio-445 (PP.05               )
 gpio-446 (PP.06               )
 gpio-447 (PP.07               )
 gpio-448 (PQ.00               )
 gpio-449 (PQ.01               )
 gpio-450 (PQ.02               )

Hi,

Does the issue happen only to one specific pin or any other GPIOs there?

I believe if /sys/kernel/debug/gpio shows the output hi, then it shall have signal out and if you don’t see anything, it may not be gpiod issue but something else.

Can you try to modify the pinmux of the output pin so that the output pin needs to be specified as output?

No OP but ran into (perhaps) this problem. Googled it and ended up here.

In my case the padctrl register was set to tristate mode. Wiping it (either settings it to all zeroes with busybox devmem … or reconfiguring the pinmux dts file) fixed the problem.

I’m not 100% sure but it seems with jetpack 5.x this somehow happened automatically?
I don’t have time right now to reflash back into jetpack 5.x so I can’t really verify but I have no recollection of having to do this when on jetpack 5.x.

1 Like

Hi,

Yes, we have identified this is due to the tristate mode. Previously this will be handled by driver if using sysfs. But on jetpack6 this does not happen.

In brief, the pinmux must be correct so that you can control the GPIO.

nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
1 Like

Thanks all for the replies! Can I update the pinmux on a system that’s already up and running, or will I need to reflash it? I did try decompiling the device tree, but I wasn’t sure where to start.

Sorry, need to reflash.

There is no help from decompiling either because pinmux was never in kernel dtb.

In brief, there are multiple kind of device tree blob on Jetson. What you always decompile is the kernel dtb. Not the one that has pinmux setting.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.