can GPIO8, GPIO9 and GPIO17 be drived as GPIO?
Those signal are pin 16, 32 and 22 on 40pin header.
I execute “gpioset -m signal x y=1“ , where (x,y)=(1,9),(1,8),(0,96) , the signals does not be drived high.
I also try to define like below in tegra234-p3737-0000+p3701-0000-hdr40.dts :
soc_gpio23_pp4: hdr40-pin22 {
nvidia,pins = “soc_gpio23_pp4”;
nvidia,function = “gp”;
nvidia,pin-label = “gp17”;
nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
nvidia,enable-input = <TEGRA_PIN_ENABLE>;
};
The kernel reply:
tegra234-pinctrl 2430000.pinmux: invalid group “soc_gpio23_pp4” for function “gp” .
I wonder these 3 signals could be used as gpio?
*** Please note that this reply is generated by LLM automatically ***
Based on the provided context, it appears that you are trying to use GPIO8, GPIO9, and GPIO17 as GPIO signals on the Jetson AGX Orin module. These signals correspond to pins 16, 32, and 22 on the 40-pin header.
To determine if these signals can be used as GPIO, we need to check the pinmux configuration for these pins.
According to the provided table, the pinmux configuration for the Jetson AGX Orin module is as follows:
| Property | Jetson Orin NX and Nano | Jetson AGX Orin |
|---|---|---|
| Number of controllers | 1 | 2 |
| Controller base address | mttcan@c310000 |
mttcan@c310000 mttcan@c320000 |
| Pins on Jetson carrier board | J17: CAN_RX: [1] CAN_TX: [2] |
J30 (40-pin header): CAN0_DIN: [29] CAN0_DOUT: [31] CAN1_DIN: [37] CAN1_DOUT: [33] |
The table does not explicitly mention GPIO8, GPIO9, and GPIO17. However, we can try to find the corresponding pinmux configuration for these pins.
Assuming that the pinmux configuration for GPIO8, GPIO9, and GPIO17 is similar to the configuration for CAN0_DIN, CAN0_DOUT, CAN1_DIN, and CAN1_DOUT, we can try to define the pinmux configuration for these pins in the device tree file (tegra234-p3737-0000-p3701-0000-hdr40.dts).
However, the kernel reply indicates that the group “socgpio23pp4” is invalid for the function “gp”. This suggests that the pinmux configuration for GPIO8, GPIO9, and GPIO17 is not defined or is not compatible with the GPIO function.
To resolve this issue, you may need to consult the NVIDIA team or check the pinmux configuration for the Jetson AGX Orin module to determine if these pins can be used as GPIO.
In summary, based on the provided context, it appears that GPIO8, GPIO9, and GPIO17 may not be usable as GPIO signals on the Jetson AGX Orin module due to pinmux configuration issues. Further investigation and consultation with the NVIDIA team may be necessary to resolve this issue.
Here is a comparative analysis of the pinmux configuration for the Jetson Orin NX and Nano modules versus the Jetson AGX Orin module:
- The Jetson Orin NX and Nano modules have a single controller with a base address of
mttcan@c310000. - The Jetson AGX Orin module has two controllers with base addresses of
mttcan@c310000andmttcan@c320000. - The pinmux configuration for the CAN signals on the Jetson AGX Orin module is defined in the device tree file, but the configuration for GPIO8, GPIO9, and GPIO17 is not explicitly mentioned.
- The kernel reply indicates that the group “socgpio23pp4” is invalid for the function “gp”, suggesting that the pinmux configuration for GPIO8, GPIO9, and GPIO17 is not defined or is not compatible with the GPIO function.
Overall, the pinmux configuration for the Jetson AGX Orin module appears to be more complex than the configuration for the Jetson Orin NX and Nano modules, and further investigation may be necessary to determine if GPIO8, GPIO9, and GPIO17 can be used as GPIO signals on this module.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Hi artiewang,
Are you using the devkit or custom board for AGX Orin?
What’s the Jetpack version in use?
Yes, those 3 pins should be able to be used as GPIO.
Please configure them in pinmux spreadsheet as Output/Drive 0 first.
GPIO8 → PIN16 → PBB.01
GPIO9 → PIN32 → PBB.00
GPIO17 → PIN22 → PP.04
Please try running the following commands to control them. (PBB.01 as example)
# gpioset --mode=wait `gpiofind "PBB.01"`=1
# gpioset --mode=wait `gpiofind "PBB.01"`=0
i am using devkit, and deploy jetpack 36.4 on it
your command still doesn’t drive pin16 on 40 pin header to high
Do you confirm that you’ve done for this correctly?
The pinmux configuration is required to use a PIN as GPIO/Output.
For Jetpack 6.1(r36.4.0), please also apply the following patch to check if it could help.
40hdr - SPI1 gpio padctl register bit[10] effect by gpiod tools in JP6 - #20 by KevinFFF
I do the patch, it still does not work, and I capture the configuration of PBB.01 from pinconf-groups, is it correct?
20 (can1_en_pbb1):
pull=1
tristate=1
enable-input=1
open-drain=0
io-reset=0
rcv-sel=0
io-hv=0
schmitt=0
pull-down-strength=0
pull-up-strength=0
drive-type=2
gpio-mode=1
function=rsvd0
Hi sirs,
Do you have any advise to control pin16,32 and 22 of 40 pin header as GPIO?
I roughly look pinctrl-tegra.c , there is a variable “sfsel_in_mux“ to judge setting sfsel or not, but this variable is defined in struct tegra_pinctrl_soc_data tegra234_pinctrl in pinctrl-tegra234.c not parsing from device-tree and defualt value is true.
Seems, some SFIO like I2C. SPI and PWM still could be drived as GPIO by gpioset command , but pin 16,32,22 cannot be drived as GPIO by gpioset?
Hi
Have you get the solution to control pin16,22,32 of 40 pin header via gpioset command?
For PIN16 of 40-pins expansion header (PBB.01), please run the following command to check its pinmux configuration.
$ sudo busybox devmem 0x0c303048
Do you mean the following commands still can not control PBB.01?
# gpioset --mode=wait `gpiofind "PBB.01"`=1
# gpioset --mode=wait `gpiofind "PBB.01"`=0
If so, please also get a scope to check its state.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.