Losing GPIO interrupt on M4 by LINUX OS booting

Technical Support
, , ,
1

Hi,

So we are trying to access the LSIO__GPIO0 / 14U (SODIMM 66 GPIO 0.14) from the Cortex-M4 part, however on booting up and stopping the system on UBoot then flashing the M4 software in, the interrupt works fine till the point we boot the Linux OS up which results to losing the interrupt on this defined GPIO.

However, we have checked the gpio list under imx8x-colibri.dtsi where the address &lsio_gpio0 included SODIM_66 that is build up on other node that is defined under imx8-ss-lsio.dtsi.

lsio_gpio0: gpio@5d080000 {
   reg = <0x5d080000 0x10000>;
   interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>;
   gpio-controller;
   #gpio-cells = <2>;
   interrupt--controller;
   #interrupt-cells = <2>;
   power-domains = <&pd IMX_SC_R_GPIO_0>
}

Yet even after disabling the node &lsio_gpio0 by an overlay, it still making the same issue.

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

&lsio_gpio0 {
       status = "disabled";
};

Please check the attachment as you can see the part where our M4 trying to access the defined GPIO.

  • Note: a question about interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>; under lsio_gpio node, can you please explain what 136 means?

Thanks in advance.

Software summary

Bootloader: U-Boot
Kernel version: 5.15.148-6.7.0-devel+git.bfdbfb2c85fb #1 SMP PREEMPT Thu Jun 20 15:59:41 UTC 2024
Kernel command line: root=PARTUUID=fde2e373-02 ro rootwait console=tty1 console=ttyLP3,115200 consoleblank=0 earlycon video=imxdpufb5:off video=imxdpufb6:off video=imxdpufb7:off
Distro name: NAME=“TDX Wayland with XWayland”
Distro version: VERSION_ID=6.7.0-devel-20240704105404-build.0
Distro variant: -
Hostname: TPS500-M4_EVAL1-06843592

Hardware info

HW model: Toradex Colibri iMX8DX on Colibri Evaluation Board V3
Toradex version: 0052 V1.0D
Serial number: 06843592
Processor arch: aarch64

2

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

Did you like my answer?

:+1: :-1:

Hello,

Thank you for reaching out with your question. The issue you’re encountering, where the GPIO interrupt on the Cortex-M4 is lost after booting Linux, is likely due to the Linux kernel reconfiguring the GPIO during its initialization process. Let’s go through some steps to address this:

  1. Understanding the Interrupt Configuration:

    • The line interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>; in your device tree specifies the interrupt setup for the GPIO. Here, GIC_SPI refers to a Shared Peripheral Interrupt in the Generic Interrupt Controller. The number 136 is the interrupt number assigned to this GPIO, and IRQ_TYPE_LEVEL_HIGH indicates that the interrupt is triggered on a high-level signal.

  2. Disabling GPIO in the Device Tree:

    • You’ve attempted to disable the GPIO node using a device tree overlay. Ensure that this overlay is correctly applied and that the Linux kernel is not re-enabling or reconfiguring the GPIO. Double-check the syntax and application of your overlay.
    • After modifying the device tree, rebuild and deploy it to ensure the changes take effect.

  3. Preventing Linux from Reconfiguring the GPIO:

    • Verify that no other parts of the device tree or kernel configuration are setting up the GPIO for use by Linux. This includes checking for any pinctrl settings or other GPIO configurations that might be applied during boot.
    • Consider using a custom kernel or device tree configuration that explicitly leaves the GPIO unconfigured or reserved for the M4 core.

  4. Testing and Validation:

    • After applying these changes, test the system to ensure the M4 core can maintain control over the GPIO without interference from Linux.
    • Monitor the boot logs to see if there are any messages related to GPIO configuration that might indicate where the conflict arises.

By following these steps, you should be able to maintain control over the GPIO from the M4 core even after Linux boots. If issues persist, further investigation into the specific kernel and device tree configurations may be necessary.

Best regards,
Toradex AI Assistant

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

Conflict between SPI and GPIO.

3

Hi @pkg_su ,

The issue is that Cortex-M and Cortex-A cannot share the same GPIO bank simultaneously.

This means that besides disabling the node using the SODIMM_66 (GPIO bank 0 line14) pin, you need to disable all nodes that use a GPIO pin from bank 0.

Note that you will likely need to disable many interfaces. If any of these interfaces are required for your project, you’ll need to select a different GPIO bank on the Cortex-M side, always checking if the interfaces will be disabled will not affect your project.

The Toradex AI’s answer about the GIC is correct. For more information on how this block works, you can check the iMX8DX SoC Reference Manual.

If you manage to get the interrupt working, please let us know!

Best Regards,
Otávio