GPIO export at Apalis iMX8QP

Technical Support
, , ,
1

Hi,

I want to use some MXM3 pins as GPIOs which are controlled via the sysfs. Now i am struggling to understand the GPIO mapping of the iMX8. Lets take the MXM3 pin number 185. According to the Apalis iMX8 datasheet the X1 pin 185 is “LSIO.GPIO2.IO30” which translates to sysfs GPIO pin number 446 (see here). Now exporting this pin in sysfs is not possible as it is in use.
The output of “cat /sys/kernel/debug/gpio” is (partially) shown in the block quote below. According to that output the gpio-446 is used as PCIe reset which explains why i cannot use it. However gpio-382 is named “MXM3_185” and can be exported. Is there some kind of remapping done somewhere? This approach was consistent for the iMX6 and TK1 but now it seems like i am lost on the way… Any help would be appreciated.

BR

Setup:
Apalis iMX8QP 2GB WP
Ixora Carrier V1.2A
Torizon 6.6.7

gpiochip4: GPIOs 352-383, parent: platform/5d0a0000.gpio, 5d0a0000.gpio:
gpio-352 ( )
gpio-353 ( )
gpio-354 ( )
gpio-355 ( )
gpio-356 ( )
gpio-357 ( )
gpio-358 ( )
gpio-359 (MXM3_198 )
gpio-360 (MXM3_35 )
gpio-361 (MXM3_164 )
gpio-362 ( )
gpio-363 ( |enable ) out hi
gpio-364 ( )
gpio-365 ( )
gpio-366 (MXM3_217 )
gpio-367 (MXM3_215 )
gpio-368 ( )
gpio-369 ( )
gpio-370 (MXM3_193 )
gpio-371 (MXM3_194 )
gpio-372 (MXM3_37 )
gpio-373 ( )
gpio-374 (MXM3_271 )
gpio-375 (MXM3_273 )
gpio-376 (MXM3_195 )
gpio-377 (MXM3_197 )
gpio-378 (MXM3_177 )
gpio-379 (MXM3_179 )
gpio-380 (MXM3_181 )
gpio-381 (MXM3_183 )
gpio-382 (MXM3_185 |sysfs ) in hi
gpio-383 (MXM3_187 )

gpiochip3: GPIOs 384-415, parent: platform/5d090000.gpio, 5d090000.gpio:
gpio-384 ( |sysfs ) in lo
gpio-385 ( |usb3503 intn ) out lo
gpio-386 ( |usb3503 reset ) out hi ACTIVE LOW
gpio-387 ( )
gpio-388 (MXM3_286 )
gpio-389 ( )
gpio-390 (MXM3_87 )
gpio-391 (MXM3_99 )
gpio-392 (MXM3_138 )
gpio-393 (MXM3_140 )
gpio-394 (MXM3_239 )
gpio-395 ( |PHY reset ) out hi ACTIVE LOW
gpio-396 (MXM3_281 )
gpio-397 (MXM3_283 )
gpio-398 (MXM3_126 )
gpio-399 (MXM3_132 )
gpio-400 ( )
gpio-401 ( )
gpio-402 ( )
gpio-403 ( )
gpio-404 (MXM3_173 )
gpio-405 (MXM3_175 )
gpio-406 (MXM3_123 )
gpio-412 ( |regulator-module-wif) out hi
gpio-414 ( |CONNECTOR_IS_HDMI ) out hi
gpiochip2: GPIOs 416-447, parent: platform/5d080000.gpio, 5d080000.gpio:
gpio-416 (MXM3_279 )
gpio-417 (MXM3_277 )
gpio-418 (MXM3_135 )
gpio-419 (MXM3_203 )
gpio-420 (MXM3_201 )
gpio-421 (MXM3_275 )
gpio-422 (MXM3_110 )
gpio-423 (MXM3_120 )
gpio-424 (MXM3_1/GPIO1 )
gpio-425 (MXM3_3/GPIO2 )
gpio-426 (MXM3_124 )
gpio-427 (MXM3_122 )
gpio-428 (MXM3_5/GPIO3 )
gpio-429 (MXM3_7/GPIO4 )
gpio-430 ( )
gpio-431 ( )
gpio-432 (MXM3_4 )
gpio-433 (MXM3_211 )
gpio-434 (MXM3_209 |sysfs ) in lo
gpio-435 (MXM3_2 )
gpio-436 (MXM3_136 )
gpio-437 (MXM3_134 )
gpio-438 (MXM3_6 )
gpio-439 (MXM3_8 )
gpio-440 (MXM3_112 |sysfs ) in lo
gpio-441 (MXM3_118 |sysfs ) in lo
gpio-442 (MXM3_114 |sysfs ) in lo
gpio-443 (MXM3_116 |sysfs ) in lo
gpio-445 ( |sysfs ) in lo
gpio-446 ( |PCIe reset ) out hi
gpio-447 ( |usb3503 connect ) out lo ACTIVE LOW

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello,

Understanding GPIO mapping on the iMX8 series, including the Apalis iMX8QP, can indeed be complex due to the sophisticated pin multiplexing capabilities of the SoC. The iMX8 series uses a different approach compared to previous generations like the iMX6 or TK1, where the mapping was more straightforward.

In the iMX8 series, each pin can serve multiple functions, and the function a pin performs at any given time is determined by the system’s configuration, specifically the device tree settings in Linux. The device tree configures the hardware and how Linux interacts with it, including which pins are used for what purpose.

The situation you’ve described, where gpio-446 is already in use (as PCIe reset in this case), but gpio-382 is named “MXM3_185” and can be exported, is likely a result of how the device tree has been configured for your specific setup. This configuration dictates that gpio-382 corresponds to the physical pin MXM3_185 on the Apalis iMX8QP module and is available for use as a GPIO.

The “remapping” you’re referring to isn’t remapping in the traditional sense but is instead a reflection of the device tree configuration. The device tree specifies the function of each pin at boot time, and this configuration is what you’re observing through the sysfs interface.

For your specific case, if you need to use MXM3 pin number 185 as a GPIO and it’s currently available (as indicated by gpio-382 being exportable), you can proceed to use it as such. However, if you need to change the function of a pin that’s currently in use (like gpio-446), you would need to modify the device tree to disable its current function and reconfigure it as a GPIO. This involves:

  1. Disabling the current function of the pin in the device tree (e.g., disabling PCIe reset for gpio-446).
  2. Configuring the pin as a GPIO in the device tree.
  3. Recompiling and deploying the updated device tree to your device.

It’s important to carefully review the device tree and understand the implications of making changes, as incorrect configurations can lead to hardware malfunctions or conflicts between peripherals.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

GPIO (Linux) | Toradex Developer Center.

3

Hello @qojote,

The use of the sysfs GPIO interface is not recommended, as this interface has been deprecated for some time.
We recommend that you use libgpiod instead: How to Use GPIO on Torizon OS | Toradex Developer Center

Regarding the inconsistency you saw for pin 185, the table and the information on that page is not completely up to date.
This assignment can change between BSP versions and really should not be used.

The correct pin assignment is the one you see in /sys/kernel/debug/gpio.

Best Regards,
Bruno