Testing pinmux procedure & modifying GPIO value

We connected a small LED to GPIO3_PAG.05 (gpio 509) and it lights by default upon power up.

I wish to verify the followings to make sure we understood correctly:

  1. We can’t modify its value since its not part of the 40 pin header (using the GPIO tools). We can read its value using the debugfs as stated here:
    Jetson AGX Orin Platform Adaptation and Bring-Up — Jetson Linux<br/>Developer Guide 34.1 documentation
    Can we modify it by writing values to specific register?

  2. In order to test it my only option is to disable this gpio entirely and see the LED turned off upon power up.

is that correct?

In addition, when reading its value via debugfs, I get 0 instead of 1 even tough the LED is turned on. Is that ok?

EDIT: the GPIO3_PAG.05 is configured as SFIO in the excel sheet.
If I want to toggle it during “runtime” by writing to specific register - should I configure it as a GPIO?


I can’t answer most of this. I will say though that the GPIO does not have the power output capability to drive an LED directly. It is almost certain that you need a buffer between the GPIO and the LED before there is any chance it will work.

It’s a very small LED and currently it lights as long as the devkit is powered on.

Is it possible to flash the pinmux settings without deleting all the nvme? maybe flashing device tree only? MB1 only? ( I know there are GPIOs configured by the MB1 Configuration Table)

See Flashing to only qspi-nor for OrinNX - #11 by KevinFFF

Note that if you have a full serial console boot log, then it will very likely tell you the exact device tree being loaded. That includes whether it is loaded from QSPI, eMMC, SD, NVMe, so on. You can use that same boot log to find out which extlinux.conf is used (if your model has eMMC, then it is probably from that prior to switching to the NVMe, but perhaps not). The extlinux.conf, if it has an FDT entry, then this is the highest priority device tree, and it will in fact tell you the file to replace (usually you would copy that file, decompile, put the replacement in with a new name, and then edit the FDT entry to name the new file to allow reverting). No flash at all is required if the FDT entry is used.

If security fuses are burned, then you must use the partition-based device tree, and flashing is mandatory due to signing requirements. If there is no FDT entry in extlinux.conf, then you could export the existing tree from “/proc/device-tree”, edit, convert it to binary format, and then add the FDT entry. No flash.

thank you for your answers.

I can confirm that its possible to do the followings:

  1. edit the pin settings via writes to its suitable register (for example changing from sfio to gpio)
  2. change the gpio value using debugfs by changing its direction first and its value later.

It works.

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