Pinmux updating but gpio export misleading

I’m working with updating pinmux for Jetson Xavier NX. I follow the threads and the documentaion and I tried to update pinmux.

  • From excel → dtsi files
  • From pinmux tool inside sdk —> cfg file
  • Update system using “”

I have a question regarding the command line export for the new configuration inside /sys/class/gpio. It seems that the pinmux direction remain the old one. I’m able to change manually but I want to understand why this happen.

Take GPIO01 for example. His references are:

  • GPIO01 on schematic
  • SOC_GPIO41 Ball name
  • Letter Q, position 5 → offset 133
  • Base GPIO: 288
  • Gpio command line to export: 421

In the original pinmux .cfg file (tegra19x-mb1-pinmux-p3668-a01) this was an input

pinmux.0x02430028 = 0x0000005a; # soc_gpio41_pq5: rsvd2, pull-up, tristate-enable, input-enable, io_high_voltage-disable, lpdr-disable

In new config file this is an output

pinmux.0x02430028 = 0x00000406; # soc_gpio41_pq5: rsvd2, pull-down, tristate-disable, input-disable, io_high_voltage-disable, lpdr-disable

I checked if I really applied these modifications (if pinmux really was updated using flash) typing the following command on command line:

root@videosystems-jnx-ing:/home/videosystems# cat /sys/kernel/debug/tegra_pinctrl_reg | grep "soc_gpio41"
Bank: 0 Reg: 0x02430028 Val: 0x00000406 -> soc_gpio41_pq5

As I see, the configuration is applied. Going to /sys/class/gpio, I exported the gpio421. As I see the gpio is configured as “Input” and not like I’m expected “Output”.

root@videosystems-jnx-ing:/sys/class/gpio/gpio421# cat direction 

I checked all the others (from GPIO01 to GPIO14) and all are compliant with the original gpio configuration not with my new configuration.

Where is my mistake?

hello f.ortolano,

may I know your detail command to re-flash the target, did you exclude -r options to fully flash the device?


./ -k MB1_BCT jetson-xavier-nx-devkit-emmc mmcblk0p1

hello f.ortolano,

you cannot use partition update, please have full flash to update board configuration file,
i.e. $ sudo ./ jetson-xavier-nx-devkit-emmc mmcblk0p1

ok, but…I can’t understand in this case why the configuration is actually set using

cat /sys/kernel/debug/tegra_pinctrl_reg

but not using export. It’s to better understand the system. Taking in account, this means that pinmux cfg file is used in an another part of the “flash” script that “reads” the same and writes something in an other partition. Is it right? But in this case, what “tegra_pinctrl_reg” show me? Is that a real configuration?

Also, in all of this, I can’t understand also if this configuration is modified by other kernel fragments. For example, I see in the file


this code that point to the GPIO12 (aka TOUCH_CLK aka touch_clk_pcc4)

			hdr40-pin15 {
				nvidia,pins = "touch_clk_pcc4";
				nvidia,function = "gp";
				nvidia,pin-group = "pwm4";
				nvidia,pull = <TEGRA_PIN_PULL_NONE>;
				nvidia,tristate = <TEGRA_PIN_DISABLE>;
				nvidia,enable-input = <TEGRA_PIN_DISABLE>;
				nvidia,lpdr = <TEGRA_PIN_DISABLE>;

So, this code could overwrite pinmux settings?

hello f.ortolano,

the basic concept is cboot to load pinmux configuration to apply pin settings.
when device boot into linux kernel, it loads device tree to update the GPIO settings.

ok the chain is clear. One could ipotetically “change” pinmux configuration using kernel fragments in dts, is it true? what I mean, if a pin for example is defined INPUT in pinmux, trought the kernel could be changed to OUTPUT like the Pinmux updating but gpio export misleading - #6 by f.ortolano example?
And regarding “tegra_pinctrl_reg”, what this show me? Is it the real configuration or only a read of pinmux, that means that after init this states could by changed by somene else?

verified that also reflashing all, the direction status of the gpios remains the same as original configuration, not updating using pinmux. So this seems to not work.
Any suggestions?

hello f.ortolano,

would like to confirm which JetPack release version you’re using.
please check $ cat /etc/nv_tegra_release for confirmation.

videosystems@videosystems-jnx:~$ cat /etc/nv_tegra_release 
# R32 (release), REVISION: 7.2, GCID: 30192233, BOARD: t186ref, EABI: aarch64, DATE: Sun Apr 17 09:53:50 UTC 2022

hello f.ortolano,

tegra_pinctrl_reg it’s the register descriptions give the offset of each register within the PinMux address range.
the pin settings is able to alter by kernel, it’s device tree to update/overwrite the pin settings.

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