Since Aster Carrier Board doesn't have buttons and LEDs available for debbuging purposes, we present two alternatives to test GPIOs: the first connects two GPIOs configured as input and output respectively; whereas the second alternative uses an external button and LED to achieve a better user experience, however, the following items are required:

1x LED

1x Button

1x Transistor BC548

2x 2k2Ω Resistor

1x 470Ω Resistor

1x Breadboard

Jumper wires

Note: On this getting started we are going to use 2x Resistor 2k2Ω, but you can use anyone between 1kΩ and 10kΩ. For Resistor 470Ω, you can use anyone between 100Ω and 1kΩ. For the transistor BC548, you can use any switch component you want, as MOSFET, just change the circuit according to the component.

To find out which GPIO number to use in the Linux sysfs interface, you have to know the correspondence between available pins in the carrier board, number of the correspondent pins on the SODIMM connector of the Colibri computer on module and number of the pins on Linux.

Download or open in a web browser the Colibri Evaluation Board and the Colibri T30 datasheets from the respective products pages of the developer website:

For this introduction guide, some pins configured by default as GPIO in the Toradex BSP were chosen. The choice of pins was made based on their availability on all the carrier boards covered by the getting-started guide. This module will not go through the configuration of other pins as GPIO, although it is possible.

First of all, you need to find the correspondence between the SODIMM and the connectors exposed for the developer on the Aster Carrier Board. Consult the Aster Carrier Board datasheet and fill the table below based in the example provided:

Note: The notation CONNECTOR.PIN will be employed in this lesson, e.g. X12.5 means pin 5 of the X12 connector.

Have a look at the table available in the "List Functions" chapter of the Colibri T30 datasheet. It provides a list of most of the Tegra pins available on the SODIMM connector.

The SODIMM pins we are interested at are connected to the Tegra SoC and have names defined by the Tegra Pin Name function. Each pin is multiplexed to have a specific function - among them GPIO, therefore the GPIO function is the column that we are interested at.

Having a look at the GPIO Alphanumeric to GPIO Numeric Assignment article, the correspondence between GPIO and the Linux numeric representation of the GPIO pins is provided as a table. To find it from the GPIO it is possible to use the formula below:

GPIO-(Character).Digit

Linux numeric representation = 8 x (Character - 'A') + Digit

Either by consulting the table from the article pointed above or calculating it, the previous table with the correspondence between Aster Carrier Board pins and SODIMM pins can be extended to have the Tegra pin name (GPIO), formed by GPIO character and digit, as example GPIO-T.02, and the Linux numeric representation. Fill the table below based in the example provided:

The Toradex Linux pre-built image comes with a tool named Toradex GPIO tool meant for debugging pins configuration. It can also be used to determine the correspondences found in the previous step. We will use it to test the hardware connections.

Note: You need a display and a mouse connected to the system in order to use the GPIO tool. Please go to the beginning of the getting-started guide for more information about assembling the peripherals.

The steps below will use the following pins (Linux GPIO number) to toggle an LED and read the value of a switch:

201 for SW

196 for LED

Use jumper wires to connect GPIO 196 to 2k2Ω resistor, connect the resistor to transistor base pin, connect pin X16.12 (5V) from iris to 470Ω resistor, connect the resistor to one LED and connect to transistor collector pin, connect the transistor emitter pin to pin X16.2 (GND) on Iris Carrier Board. Use jumper wires to connect pin X16.33 (3,3V) to 2k2Ω resistor, connect the resistor to one switch and to GPIO 201, and connect the node to pin X16.21 (GND) on Iris Carrier Board.

There is a debug interface provided by the kernel debugfs for GPIO, which holds information about GPIO pins already reserved for drivers, as well as pin configuration and state. See the example below for the Colibri T30, and try it yourself:

root@colibri-t30:~# cat /sys/kernel/debug/gpio

GPIOs 0-255, tegra-gpio:

gpio-10 (SODIMM pin 154 ) in lo

gpio-17 (SODIMM pin 81 ) in lo

gpio-23 (sdhci_cd ) in lo

gpio-26 (THERMD_ALERT ) in hi

gpio-29 (sysfs ) out hi

gpio-67 (SODIMM pin 130 ) in lo

gpio-70 (SODIMM pin 132 ) in lo

gpio-85 (USBC_DET ) in lo

gpio-86 (KEY_MENU ) in hi

gpio-90 (sysfs ) out lo

gpio-91 (sysfs ) out hi

gpio-94 (sysfs ) out hi

gpio-110 (SODIMM pin 162 ) in lo

gpio-111 (hdmi_hpd ) in lo

gpio-144 (SODIMM pin 73 ) in lo

gpio-153 (EN_MIC_GND ) out hi

gpio-157 (KEY_BACK ) in hi

gpio-158 (KEY_HOME ) in hi

gpio-168 (TOUCH_PEN_INT ) in hi

gpio-169 (KEY_POWER ) in lo

gpio-170 (BL_ON ) out hi

gpio-171 (SODI-85, Iris X16-18) out lo

gpio-178 (usb_host_vbus ) out lo

gpio-181 (SODIMM pin 75 ) in lo

gpio-188 (SODIMM pin 134 ) in lo

gpio-190 (102, I X13 ForceOFF#) in lo

gpio-191 (104, I X14 ForceOFF#) in lo

gpio-196 (sysfs ) out lo

gpio-197 (sysfs ) out lo

gpio-198 (sysfs ) out lo

gpio-199 (sysfs ) out hi

gpio-201 (sysfs ) out lo

gpio-220 (SODIMM pin 166 ) in lo

gpio-221 (SODIMM pin 168 ) in lo

gpio-222 (SODIMM pin 170 ) in lo

gpio-223 (SODIMM pin 172 ) in lo

gpio-226 (KEY_FIND ) in lo

gpio-230 (KEY_VOLUMEDOWN ) in hi

gpio-231 (SODIMM pin 94 ) in lo

gpio-232 (LAN_RESET ) out hi

gpio-234 (LAN_V_BUS ) out hi

gpio-237 (SODIMM pin 69 ) in hi

gpio-238 (SODIMM pin 65 ) in hi

gpio-239 (KEY_VOLUMEUP ) in hi

GPIOs 256-264, i2c/4-002d, tps6591x, can sleep:

gpio-262 (fixed_reg_en_hdmi ) out lo

See that the pins 201 and 196, configured as input and output in the previous steps, are the only ones taken by sysfs and are correctly configured as in and out respectively.

Export, unexport, configure and toggle the GPIO pins as you read the debugfs information to see the changes.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the Toradex nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL Toradex BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The GPIO sysfs interface enables the use of interrupts from user space, as long as it is supported by the underlying hardware. Read the sysfs GPIO documentation, have a look at the poll system call and try to implement an application that handles the interrupt. Have a look at the source code below for reference:

You have to browse the computer on module datasheet and/or device-tree in order to verify that the pin can be configured as GPIO. After that, you must customize the system device-tree in order to change the pin configuration.

If there isn't a kernel driver that suits your needs, you can access GPIO from kernel space rather than user space, and use the gpio.h kernel library.

There are other ways to access GPIO registers directly either from user space (using mmap) or kernel space (using ioremap). Those are problematic since they bypass the kernel handling of the GPIO controllers and might lead to unexpected behavior.