- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software:
The objective of this FAQ is for someone with a TI EVM to enable using GPIOs in Linux. This guide will walk through how to setup a GPIO in the Linux Device Tree and how to toggle it in user space. This guide will also cover some common questions and issues someone may run into.
This applies to Linux SDK 10.0+ for AM64x, AM62x, AM62A, AM62P, AM62L.
TI EVMs have RPI headers that are exposed on the board which includes Main Domain GPIOs and some MCU GPIOs. Refer to the schematic of the TI EVM to see what pins are connected to the RPI header.
Refer to the common links to see the EVM product pages where the schematics can be found.
The RPI headers are usually labeled as "User Expansion Connector" and "MCU Header". Here is an example for SK-AM62B-P1:
Refer to the device's datasheet to see which signals can be used as GPIOs. Some pins are labeled for a different function, but still can be used as GPIOs.
Use this information to select a GPIO to use and then it can be enabled in the Linux device tree.
After the device tree is configured, compiled and loaded, the next step is to control the GPIO in userspace after the Linux kernel has booted. In userspace, we can use the GPIO SYSFS (deprecated) or the libgpiod command set. Important to note that you should only use one of these userspace methods, not both at the same time.
In later Linux SDK versions, its recommended to use Libgpiod userspace commands. This tool set and API are not written by TI so please refer to the Github repo: https://github.com/brgl/libgpiod
In the default Linux SDK, this is enabled, but refer to the menuconfig entry if needed:
As seen in the sample device tree, its recommended to add 'gpio-line-names' parameter in the device tree because it makes calling the GPIO in userspace easier. See below for an example of enabling GPIO0_38:
Just be aware when daemonizing the GPIO command, trying to change the GPIO again will return a 'Device or resource busy error' so kill the PID of the existing command.
In case a GPIO doesn't have a name, follow this process for GPIO0_38:
For the most up to date commands, refer to the man page for the GPIO command or use the --help flag.
For an example of using the libgpiod commands in Linux SDK versions 9.0 and prior, refer to this FAQ: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1260373/faq-transitioning-the-gpio-userspace-interface-from-sysfs-to-chardev
GPIO SYSFS has been deprecated as noted in the Documentation: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/Documentation/admin-guide/gpio/sysfs.rst?h=ti-linux-6.6.y
In the case that it needs to be re-enabled, refer to Kernel config below:
Once the kernel config is updated, refer to the Linux documentation for compiling a Kernel Image.
For this example, GPIO0_38 will be enabled. GPIO0's memory mapped address is 0x600000.
The first field is the PADCONFIG register address offset which is the last 3 hex bits defined in the device's TRM and datasheet. This tells Linux which pin these settings apply to.
The second field controls the input/output buffer which will be discussed in the next section. This does not define if a GPIO is input/output direction.
The third field is the Mux Mode of the pad. Typically, GPIOs use Mux Mode 7 but refer to the device's datasheet for complete information.
At a hardware level, for each pad on the SoC, there is a PADCONFIG register to control the settings of the Pad. See Pad Configuration Registers Section in the device's TRM for more information.
Each Pad as a Transceiver (Bit21) and Receiver (Bit18) buffer like the diagram below. By using the independent enable signals on each buffer, we can allow the pad to receive and/or transmit. These buffers allow the capability to receive and transmit data. This is true for most pads on the SoC, but refer to the datasheet for complete information.
So how does Linux configure the hardware? Refer to k3-pinctrl.h which defines the pin control bindings: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-pinctrl.h?h=ti-linux-6.6.y
The definitions are the exact same as the PADCONFIG registers bit fields seen in the TRM Section named 'Pad Configuration Registers'. Linux will use PIN_INPUT/PIN_OUTPUT and any other parameters to configure the pin when Linux is booting.
Notice the following:
This means in the device tree, PIN_INPUT means both the input buffer and the output buffer is enabled. PIN_OUTPUT means only the output buffer is enabled and input buffer is disabled. Remember, enabling the buffers allow for the functionality to receive and transmit on the pad.
This also means that configuring the PIN_INPUT/PIN_OUTPUT does not impact the GPIO state.
