Disabling Selected GPIO Pins on Colibri iMX8X without Affecting Entire GPIO Controller

[adel7b]

Hello Toradex Community,

I’m working with a Colibri iMX8X module and aiming to disable individual GPIOs on the Linux side while keeping them accessible for the Cortex-M4 core. Specifically, I need to disable GPIO1_IO21 and others so that the Linux kernel doesn’t take control of it, but I want the Cortex-M4 to be able to access it directly.

Is there a proper method to disable a specific GPIO pin in the device tree for the Colibri iMX8X, allowing it to remain accessible to the Cortex-M4?

I tried to disable the GPIO pin using overlays but without any success.

here are the device information:

------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           5.15.148-6.8.0+git.8c5c2dcbf6ba #1-TorizonCore SMP PREEMPT Tue Aug 6 10:01:59 UTC 2024
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/b830c7ab88ae53cb2f19de8bf79676c7f748e53872eac244416117852fc7c0e2/0
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.8.0-build.22
Distro variant:           VARIANT="Docker"
Hostname:                 colibri-imx8x-15339097
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Colibri iMX8QXP on Colibri Evaluation Board V3
Toradex version:          0038 V1.0E
Serial number:            15339097
Processor arch:           aarch64
------------------------------------------------------------

I’m testing the GPIO LED output example from the SDK for the Cortex M4 on an i.MX8X module. My goal is to control an LED from the M4 core (to be able to use this pin and others for further processing later), even when Linux is running on the A-core. However, I’m encountering an issue where the LED stops blinking once the Linux kernel starts, even though I’ve disabled the GPIO block in my overlay.

Here’s the overlay I’m using:

/dts-v1/;
/plugin/;

/{
    compatible = "toradex,colibri-imx8";
};

&lsio_gpio1 {
    status = "disabled";
};

When I run gpioinfo in Linux, the GPIO block appears disabled, and the specific pin (SODIMM_21) I’m using for the LED is not listed, which suggests Linux isn’t accessing it. However, the M4-controlled LED still stops blinking once Linux starts.

Any guidance or example overlays that successfully disable specific GPIOs for this platform would be greatly appreciated. Thanks in advance for any insights you can offer!

[ToradexAI]

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

---

To disable specific GPIO pins on the Colibri iMX8X for Linux while keeping them accessible to the Cortex-M4, you need to modify the device tree overlay to target only the specific GPIO pins rather than disabling the entire GPIO block. Here are some steps and considerations:

1. Modify the Device Tree Overlay: Instead of disabling the entire lsio_gpio1 block, you should specify the individual GPIO pins you want to disable. Unfortunately, the context does not provide a specific example of how to do this, but you can try to modify the overlay to target specific pins.

2. Ensure Proper Initialization: Make sure that the initialization sequence for the GPIOs is set up correctly so that the Cortex-M4 can access the GPIO pins after the Linux kernel starts. This might involve ensuring that the M4 firmware is correctly configured to take control of the GPIOs.

3. Community Support: Since the context suggests seeking guidance from the Toradex community, it would be beneficial to look for examples or ask for advice on the Toradex community forums. Other users may have faced similar issues and could provide practical solutions or alternative methods.

4. Check for Conflicts: Ensure there are no conflicts in the device tree or in the M4 firmware that might cause the GPIOs to be reconfigured or disabled when Linux starts.

If you continue to face issues, reaching out to the Toradex community or support might provide additional insights or examples that have been successfully implemented by other users.

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

Repurposing GPIOs in Device Tree - Disable LCD

Hi, I’m having trouble with repurposing GPIO Pins (to Output Pins), which are mapped/used by the Colibri IMX8X to/for the LCD display. I’m working with Bitbake and therefore I built my own device tree extension. It seems like that it is a common problem, but I’m not getting it to work. To disable the LCD, I deactivated the device driver in ther kernel config (menuconfig). I also disabled all nodes, which are related to the LCD. Next, I created a new iomux-config (see similar topic ). You can…

Problems loading M4 firmware on Colibri iMX8QXP 2GB WB IT using U-Boot

Hi all, I’m using a Colibri iMX8QXP plus an Iris Carrier board 2.0 First I have compiled the example proyect “Hello World” provided by NXP in their MCUXpresso SDK Dashboard HelloWorld.zip (2.0 MB) [SDK_2.9.0_MIMX8QX6xxxFZ] Then, with an USB stick connected to Iris, writing the commands “usb start”, “usb reset” and “ls usb 0” I get this on my terminal [image] … so I understood that I might load the “HelloWorld.bin” file with “fatload usb 0 $loadaddr HelloWorld.bin && dcache flush && bootau…

https://community.nxp.com/t5/i-MX-Processors/IMX8M-Mini-Sharing-GPIO-block-between-A53-and-M4/m-p/969766.

[alex.tx]

Access permissions are assigned to entire GPIO banks rather than to specific GPIO lines within those banks.

Therefore, if you need to allocate specific GPIO lines to the Cortex-M core , you must assign entire GPIO banks accordingly. This approach ensures that each core has exclusive access to its designated GPIO banks, preventing conflicts.

For detailed information on configuring the RDC and managing GPIO access, refer to the i.MX8X Reference Manual, particularly the section on the Resource Domain Controller.

[adel7b]

Thank you, Alex, for the guidance.

I attempted to disable the entire lsio_gpio1 bank in my overlay, as you suggested, but I’m still facing the same issue. Specifically, I’m using the pin LSIO.GPIO1.IO23 in its default configuration as GPIO pin. However, the LED stops blinking as soon as the Linux kernel starts, despite the bank being set to “disabled” in the overlay.

I’m unsure why this is happening. Could there be any additional steps or configurations I might be missing?

Thanks again for your help!

[alex.tx]

@adel7b

&lsio_gpio1 {
    status = "disabled"

By doing this, you exclude lsio_gpio1 from being handled by the Linux GPIO driver. However, there are multiple references to LSIO_GPIO1 in the &iomuxc node that you’ll need to remove to complete the process

[adel7b]

Hi Alex,

Thank you for the detailed guidance! I followed your instructions, disabling the entire lsio_gpio1 bank and removing the relevant references in the &iomuxc node. Unfortunately, I’m still encountering the same issue where the LED stops blinking on the Cortex-M4 once the Linux kernel starts.

Here’s my current overlay:

/dts-v1/;
/plugin/;

/ {
    compatible = "toradex,colibri-imx8x";
};

fragment@0 {
    target = <&iomuxc>;
    __overlay__ {
        /delete-property/ pinctrl_gpio_hpd;
        /delete-property/ pinctrl_lvds_converter;
        /delete-property/ pinctrl_lpspi2;
    };
};

&lsio_gpio1 {
    status = "disabled";
};

Is there anything else I might be missing to ensure exclusive access of lsio_gpio1 for the Cortex-M4?

Thank you again for your assistance!

[adel7b]

Additionally, it would actually be fine for my project if the GPIO remained accessible to Linux, so long as the Cortex-M4 can still control it. The main reason I tried disabling the entire GPIO block was because it wasn’t working as expected while Linux was running, so I thought a device tree overlay might resolve the issue.

Any suggestions on how to allow both cores to access the GPIO, is that even possible? or if there’s another approach to keep the M4’s control active would be greatly appreciated!

[adel7b]

To further test the GPIO functionality on the Linux side, I removed the previous overlay and selected three pins that are set to GPIO mode by default: SODIMM_35, SODIMM_55, and SODIMM_32. According to the Colibri iMX8X datasheet (pages 25-26), these pins are configured as type: GPIO in default mode: ALT4 (LSIO.GPIO).

Using the arm64v8-gpiod Docker container provided by Toradex, I tested these pins with gpioset to toggle the LEDs. Here’s what I observed:

• The LED connected to SODIMM_55 worked as expected; I was able to toggle it on and off.
• However, the LEDs connected to SODIMM_32 and SODIMM_35 stayed on and did not respond to the gpioset commands.

Here are the commands I used:

gpioset 2 16=1 18=1 20=1  # Attempt to turn all LEDs on
gpioset 2 16=0 18=0 20=0  # Attempt to turn all LEDs off

Is there additional configuration needed for specific GPIOs to be controlled from the Linux side even if the default mode is set to GPIO?

[collin.tx]

Dear @adel7b,

Thank you for your detailed description. I have been checking out the GPIOs you are trying to use and figured out that two of them (SODIMM_32/GPIO1.IO16 and SODIMM_35/GPIO1.IO20) are already in use by:

• UART0 ← SODIMM_32
• UART3 ← SODIMM_35

their default mode is defined as ALT4, which means that the default SoC will use this functionality. However, the Uboot device tree and the device tree for Linux overwrite this, which can be seen in the Datasheet with the yellow markings. Essentially what this means is that in order to use those specific pins, you will have to alter the device trees for Uboot and linux, where you will have to disable lpuart0/3 and uart0/3. Only then will you be able to use those specific pins as gpios.

The reason SODIMM_55 is working, is that it is not used in any other place in the device tree.

Best regards,
Collin

[adel7b]

Dear Collin,

Thank you for the explanation. This solve my issue, thank you again

[collin.tx]

Dear @adel7b,

Thank you for confirming and I’m glad I could be of service

Best regards,
Collin