Where can I find a list of mappings between GPIO header pins and sysfs port numbers for the TX1, similar to what’s provided for the TK1 here?: Jetson/GPIO - eLinux.org
This isn’t the full answer but there is a list of all the pin names for J21 (Expansion header 1) on page 23 of the Jetson TX1 Developer Kit Carrier Board Specification available here: Jetson Download Center | NVIDIA Developer
I have been unable to figure out the link between the pin names there and how I would actually access them in code. If anyone figures that out I would like to know.
At least for TK1 there is a list in kernel source arch/arm/mach-tegra/gpio-names.h. The numerical part of the define is the index used in sysfs for TK1, while the text (such as “TEGRA_GPIO_PU1”) cross-references to the TK1 TRM (the “PU1” in the example). There is also some intersection with the TK1 pinmux files, e.g., drvers/pinctrl/pinctrl-tegra.c or drivers/pinctrl/pinctrl-tegra124.c, since K1 is a tegra124). I think for TX1 this converts in naming as a tegra210, so cross-references to drivers/pinctrl/pinctrl-tegra210.c, while sharing pinctrl-tegra.h…I have not experimented with this yet.
I do not see the gpio-names.h equivalent for tegra210, this is possibly moved somewhere else, e.g., in firmware files.
If you cross-reference the Carrier Board specification with the JTX1 Pinmux and TX1 TRM, user GPIO is accessible through the
/sys/class/gpio directory. We’ll have to do a community tutorial on it. Using the GPIO19/AUD_RST & GPIO20/AUD_INT signals from J21 (GPIO Expansion Header, pins 29 & 13) might be the easiest place to start. There are also generic GPIO signals available through the fine-pitched camera and display connectors, however 0.1" (2.54mm) J21 header is easy to clip on to.
[quote=“dusty_nv”]
Yes please!
I wanted to check if I read the materials correctly. Are the following correct?
On J21:
There are two Bidirectional GPIO:
- gpio20 pin 13 GPIO_PE6
- gpio11 pin 33 GPIO11_AP_WAKE_BT
There are two Input GPIO: - gpio16 pin 18 GPIO16_MDM_WAKE_AP
- gpio9 pin GPIO9_MOTION_INT
There are two Output GPIO: - gpio19 pin 29 GPIO19_AUD_RST
- gpio8 pin 37 GPIO_ALS_PROX_INT
I have a little table/diagram of the header: NVIDIA Jetson TX1 J21 Header Pinout - JetsonHacks
Did I miss anything?
You weren’t even close, loser.
Here’s what I have so far:
All Pins are on the Jetson TX1 J21 Header.
Pin number, sysfs gpio number, Jetson TX1 Signal Name, Device Tree Pin Name
Pin 13 - gpio38 - GPIO_PE6 - pe6
Pin 16 - gpio37 - AO_DMIC_IN_DAT_LVL - dmic3_dat_pe5
Pin 18 - gpio184 - GPIO16_MDM_WAKE_AP - modem_wake_ap_px0
Pin 29 - gpio219 - GPIO19_AUD_RST - gpio_x1_aud_pbb3
Pin 31 - gpio186 - GPIO9_MOTION_INT - motion_int_px2
Pin 32 - gpio36 - AO_DMIC_IN_CLK - dmic3_dat_pe5
Pin 33 - gpio63 - GPIO11_AP_WAKE_BT - ap_wake_nfc_ph7
pin 37 - gpio187 - GPIO8_ALS_PROX_INT - als_prox_int_px3
There is a more colorful version of this information at: http://jetsonhacks.com/nvidia-jetson-tx1-j21-header-pinout/
The Device Tree Pin Name is the name that is used in the kernel source code to refer to the given signal.
All of these pins work correctly as Outputs, I attached an LED to each output and was able to toggle it on and off.
After playing around with this for far too long, I realized I have no idea how to make them work as Inputs. So far the things that I have tried have not worked. I wired a tactile switch with an appropriate 10K pull down resistor and exported the given pin with an “in” direction. All read commands used ‘sudo’ for permissions.
Pressing the button changes the value from low to high. However, releasing the button does not pull the GPIO line back to low. Sometimes the GPIO line stays high, sometimes it stays high for about 30 seconds and then comes back down to low. Hopefully somebody can set me straight on how to get it to work correctly.
TX1 pad have internal pull up/pull down configable in pinmux register(check http://developer.nvidia.com/embedded/dlc/tegra-x1-technical-reference-manual section 9.15).
Not sure how you connect the tactile switch, but if it’s conflict with internal pull up/pull down, you may won’t get the value you want.
If you already make GPIO out work as expect, suggest use a GPIO out as source to test another input pin.
Don’t forget to confirm the pinmux register E_INPUT and PUPD setting of input pin first.
@JimWang I was fortunate enough to have @yermin point out that there was a 4K resistor in the level shifter that was causing my issue.
The next question is, in the pinmux table has an associated group and the naming suggests that the pin is associated with a signal. For example in the pinmux spreadsheet:
gpio38 - GPIO_PE6 - pe6 - AUD-INT - GPIO20/AUD-INT
The group for GPIO is ‘RSVD0’
Does that mean that the pin is actually being used by the audio subsystem, and needs to be removed from the audio system before being used as a general purpose GPIO pin?
The intent here is that I would like to wire a button up and have the TX1 read the button state. At the same time, this should not effect other subsystem functions, such as causing the audio system issues. Is that the intent of GPIO pins on the J21 header, or is the thinking that extra GPIO functions should be brought out to the J26 header?
With the exception of DMIC3_CLK and DMIC3_DAT which are labeled ‘Generic GPIO’, everything appears to be assigned to a given function. Does this mean that there are two general GPIO pins available, everything else is taken and should not be reassigned?
The expansion header “Usage/Description” on the carrier board spec (table 16) lists J21 pin 13 both by signal name and by pin name, then describes usage. GPIO_PE6 is a pin name, what its actually used for and its description (by nature of being general function and not special/specific function) just depends on how its configured. My assumption, given that “Usage/Description” names audio i2s, would be that default configuration is for audio. On the other hand, if you’ve used GPIO functionality successfully through sysfs, it would seem that audio is not yet configured on that pin. The acid test will be to see what happens when wiring those pins for use in i2s.
Here has the pinmux document : http://developer.nvidia.com/embedded/dlc/jetson-tx1-module-pinmux
Use GPIO_PE.06 as example to explain, column A is TX1 pin name, the full name of this pin is “GPIO20/AUD_INT”, this pin only have GPIO function in column G, no SFIO function in column H~K.
The name “GPIO20/AUD_INT” mean when nvidia design chip, want this pin to be use as audio interrupt, and if reference desgin or customer design have a audio interrupt, frist choice suggest use this pin. But it’s doesn’t mean this is dedicated, all GPIO is generic, just treat it normal and make sure no conflict in your system or code, it should OK to use per function you need.
Ball name DMIC3_CLK/DMIC3_DAT, full name of pin AO_DMIC_IN_CLK/AO_DMIC_IN_DAT also only have GPIO function, name just mean nvidia want use this pins to that function, but you know, desgign changes, name just a name, plese check pinmux to find it’s real usage.
The group of GPIO is just a software classify to help pin management.
@JimWang Thank you for the clarification! This is very useful information.
Here’s an article about sysfs GPIO mappings to the J21 Header that I have written along with a demo:
Kangalow,
It seems that the gpio path has changed within the kernel since you wrote your article.
Have you gotten your demo working on the latest SDK from Nvidia?
Brian
Which pins are you having trouble with?
Sorry for the late reply. I thought I’d get notification but didn’t.
When I run your code I get this output:
ubuntu@tegra-ubuntu:~/Orb_Tests/jetsonTX1GPIO$ ./exampleGPIOApp
Testing the GPIO Pins
gpioExport unable to open gpio219: Permission denied
gpioSetDirection unable to open gpio219: No such file or directory
Setting the LED on
gpioSetValue unable to open gpio219: No such file or directory
Setting the LED off
etc…
If I examine the directory you are accessing:
ubuntu@tegra-ubuntu:~/Orb_Tests/jetsonTX1GPIO$ ls -Rlah /sys/class/gpio
/sys/class/gpio:
total 0
drwxr-xr-x 2 root root 0 Apr 18 09:20 .
drwxr-xr-x 65 root root 0 Apr 18 09:20 …
–w------- 1 root root 4.0K Apr 18 09:20 export
lrwxrwxrwx 1 root root 0 Apr 18 09:20 gpiochip0 → …/…/devices/platform/6000d000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 Apr 18 09:20 gpiochip1008 → …/…/devices/platform/7000c400.i2c/i2c-1/1-0074/gpio/gpiochip1008
lrwxrwxrwx 1 root root 0 Apr 18 09:20 gpiochip984 → …/…/devices/platform/7000d000.i2c/i2c-4/4-003c/max77620-gpio.0/gpio/gpiochip984
lrwxrwxrwx 1 root root 0 Apr 18 09:20 gpiochip992 → …/…/devices/platform/7000c400.i2c/i2c-1/1-0077/gpio/gpiochip992
–w------- 1 root root 4.0K Apr 18 09:20 unexport
I’m still learning how the code functions. It just occurred to me that the pin may not be available until the code runs. I was expecting to see it from a bash prompt, but may have been wrong with that assumption.
I’ll be spending more of today learning the ropes on the GPIO. Any hints you can offer will be greatly appreciated.
FYI, the “Permission denied” is either because “sudo” was needed (root authority), or else the attempted file operation in question is a read of a write-only file or a write of a read-only file. In the case of using “ls -l” on a symbolic link, the link permissions are always full, but the file pointed to by the link is the real permission set (“ls -l” of a link is a bad indicator of whether the final file target linked to can be read from or written to).
Existence of a “/sys” files require a driver be loaded, and possibly also configuration adjusted. A GPIO pin not used will not show up in “/sys”, and must be exported (e.g., via “/sys/class/gpio/export”); once exported, you may need to configure as read or write, so on.
Thanks. The sudo fixed it. I should have thought of that.
I’ll spend more time learning the code now.
Question: is there a direct way to control the pin drive strength using the kernel /sys/class/gpio tree? Or is there another way? Or do I have to mmap the CPU registers and bang on them myself?
Thanks.
Never mind. I added switching mosfets and they are doing the job nicely.