I am working with various Orin Nanos and recently upgraded from Jetpack 5 to Jetpack 6.0GA with l4t 36.3 and all of my scripts that control the GPIOs is no longer working.
I was reading that Jetpack 6 deprecated the sysfs driver and GPIO pins direction is no longer dynamic.
Which leads me to these following questions.
Will the deprecation of sysfs driver affect the 12c pins on the Nano pinouts?
I am working with other people that helped setup Jetpack 36.3 on the nano and was reasured that 36.3 should not cause any GPIO issues.
Is there any documentation about the differences between JP 36.0 and JP 6.3 regarding GPIOs on the Nano pinouts?
Final questions, if I need to now manually set GPIO pin directions and can no longer change them dynamically. What is the best resource for learning how to do so?
Currently there are ways to update the PINMUX configs using spreadsheets/csv files but this won’t work on my test system since every machine I am working with is Linux based. Is there any tool I can use to read/set the current direction of the GPIO? and what is a great resource to tracing back which pin is connected to which register (there are many resources I have looked into and much of the documentation is confusing.)
Thank you in advance for your help and time.
Edit: I am currently using libgpio but all scripts are failing.
Can libgpio work with pins that were converted to input and turn them into output or is that not possible?
I used the gpioinfo and gpioset commands to control the GPIO11
using gpiochip 0 and line 43 for the pin.
gpioset gpiochip0 43=1
Which does set it high within the script, but as soon as the script finishes then the PIN reverts back to LOW and is not listed as an output.
I need to have the pins persist between scripts, currently they only persists when the script loops the call or if I use --mode=wait
I have generated a new PINMUX config using the given spreadsheet and integated it to the kernels source code then re-flashed the board. That seems to allow me to have the states of the pin persist. However, it is not ideal to have to re-build/re-flash the kernel onto a board in order to use the pins. Has there been any update on setting the pins and have them persist that is not at the kernel level?
since it’s pinmux configuration, you’ve to re-flash the target to apply the pin settings.
regrading to persist the pin status, you might give it a try to add some implementation in kernel layer to keep the pin toggle high.
I have been making these changes within the kernel level. But it does not seem intuitive to have to flash a system to change the state of a pin.
Is there any other way to dynamically change the pin state?
(I know sysfs driver was depricated but is there a work around to change the pin state in place rather than re-flashing?)
And what are the current default state of each pin that is currently on the Orin Nano Devkit? What is the best way to read the current state of the pins?
The pinmux spreadsheet has them all set to GPIO input and when requesting gpioinfo it gives me states that do not match the state I changed on the kernel level.
If the changes can only take place on the kernel level, I am noticing some additional issues.
I am currently testing a custom RT kernel and am trying to incorporate the pinmux that I generated.
The pinmux I generated works on a generic orin nano kernel. The proper pins are set to output and can persist at a high state. The board is able to work as expected when connected to the system it needs to control.
When that same Pinmux is integrated into the RT kernel, everything appears to work. The pins output 3.3v and the state persists. That is until the board is integrated into a the rest of the system.
When the board is hooked up, the pins that were set as outputs no longer output any voltage and the pins that were set to input cannot detect any siugnals.
The only difference between the generic kernel and the RT kernel I am using is that I am using custom ethernet drivers that is unrelated to the pinmux configs. And as stated above, the pinmux works with a generic kernel but fails with the RT kernel.
Is there anything I should take into consideration when integrating a custom pinmuc config file to an RT kernel?
let’s taking AON GPIO, PBB.03 as an example,
you may using below to check pin status. # gpioinfo gpiochip1|grep PBB.03
here’s sample to toggle pin change, # gpioset --mode=exit --drive=push-pull gpiochip1 11=1
FYI, pinmux configuration is used by bootloader stage for pin initialization.
let’s open another new threads for tracking if this is the issue with RT kernel only.