THOR PM0 PF7 PB6 PP5 can not control

[541112]

hi,nvida

We have a custom carrier board designed to adapt to the NVIDIA T5000, running JetPack 7.1.

nvidia@tegra-ubuntu:\~$ cat /etc/nv_tegra_release
# R38 (release), REVISION: 4.0, GCID: 43443517, BOARD: generic, EABI: aarch64, DATE: Wed Dec 31 00:15:19 UTC 2025
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia
INSTALL_TYPE=openrm

Configuration is completed via the pinmux spreadsheet (pinmux.xlsx), followed by full system flashing. We want to utilize three GPIO signals for simple on/off control in user space. Based on previous experience(orin nx/ agx orin), after configuring them as BI (Input Enable), we set the initial drive state to Drive 0 or Drive 1 respectively.

K57 gp_pwm9_pm0

we configure in xls and paste into project include gpio and pinmux file.

after full flash into Thor, we take:

cat /sys/kernel/debug/pinctrl/810c281000.pinmux/pinconf-groups

32 (gp_pwm9_pm0):

        pull=1
        tristate=1
        enable-input=0
        open-drain=1
        io-reset=1
        rcv-sel=1
        io-hv=1
        schmitt=0
        pull-down-strength=8
        pull-up-strength=8
        drive-type=1
        gpio-mode=1
        function=rsvd1

root@tegra-ubuntu:/home/nvidia# sudo busybox devmem 0x810c282040
0x00203415

we set manually

root@tegra-ubuntu:/home/nvidia# gpioset --mode=wait `gpiofind “PM.00”`=1

root@tegra-ubuntu:/home/nvidia# gpioget `gpiofind “PM.00”`
0

The voltage level measured on the circuit board still remains low.

we also do the same test in : H52 pwm2_pf7

109 (pwm2_pf7):

pull=0
        tristate=0
        enable-input=0
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        schmitt=0
        pull-down-strength=8
        pull-up-strength=8
        drive-type=1
        gpio-mode=1
        function=gp_pwm2

root@tegra-ubuntu:/home/nvidia# gpioset  `gpiofind "PF.07"`=1
root@tegra-ubuntu:/home/nvidia# gpioget  `gpiofind "PF.07"`
0

we can’t control the pin to output High level. the other strange is function is still “gp_pwm2”

PB.06 : F54 soc_gpio113_pb6

21 (soc_gpio113_pb6):

pull=1
        tristate=1
        enable-input=0
        open-drain=1
        io-reset=1
        rcv-sel=1
        io-hv=1
        schmitt=0
        pull-down-strength=8
        pull-up-strength=8
        drive-type=1
        gpio-mode=1
        function=rsvd1

the same result, we can’t control it to output high

Please help to check , Thanks a lot

[KevinFFF]

Hi 541112,

@541112

Configuration is completed via the pinmux spreadsheet (pinmux.xlsx),

Please share the detailed steps how did you update the pinmux configuration.

Have you tried configuring Output instead of Bidirectional?

You can also check if those pins have been used by other driver.

[541112]

After posting this thread, we re-examined the entire device tree inclusion logic in our BSP and discovered it was a very simple, careless mistake.

From the very beginning, we had assumed that in R38.4, the naming would follow traditional conventions:

T5000: 0008
T4000: 0000

We were working on bring-up for the T5000.

When the first GPIO under our control failed to work—and given the limited documentation available, the inability to inspect using devmem as in previous platforms, and even similar posts on the forum about non-functional GPIOs—we thought there might be some special trick or undocumented knowledge involved.

We spent quite some time trying various permutations and combinations. However, we eventually started over from scratch to check the pinmux inclusion relationships, and found that in the board-level config file, the actual referenced pinmux file name was:

PINMUX_CONFIG=“tegra264-mb1-bct-pinmux-p3834-xxxx-p4071-0000.dts”;

But we always spent time in the file of “tegra264-mb1-bct-pinmux-p3834-xxxx-p4071-0008.dts”

after we change to modify the right file, gpio is ok now.

but . we still fnd a problem
"

1. gpioset gpiofind "PF.07"=1
   ok

2. gpioget gpiofind "PF.07"
   the read action will lead PF.07 to 0
   "

So, thanks a lot for your reply, we’ve learned a great deal along the way as well.

[KevinFFF]

@541112

• gpioset gpiofind "PF.07"=1
  ok
• gpioget gpiofind "PF.07"
  the read action will lead PF.07 to 0
  "

The GPIO state may be reverted to LOW state after gpioset finishes.
So, gpioget reports 0 is expected.