On the i.MX 8MP platform, when the M-Core (Cortex-M7) requires access to GPIO pins, resource conflicts often arise with the Linux-based A-Core (Cortex-A53).

Why Release Pins?

In a dual-core system (A-Core + M-Core), GPIO pins are typically managed by the A-Core (Linux drivers) by default. When the M-Core needs to access a specific GPIO (e.g., for interrupt input, control signals, etc.), and the A-Core still holds that pin, the following issues may occur:

GPIO cannot respond to interrupts

• M-Core access failures

• GPIO cannot respond to interrupts

• System resource conflicts or abnormal output

Therefore, it is essential to release the pin multiplexing and any associated device node references on the A-Core side.

Release Method

The process primarily involves two steps:

1. 1. Comment out the pinmux (pin multiplexing) configuration;
2. 2. Comment out all device nodes that reference the GPIO.

Detailed Steps

Comment Out Pinmux Configuration

Taking a button GPIO as an example, locate the following in the device tree file:

OK8MP-linux-kernel/arch/arm64/boot/dts/freescale/OK8MP-C.dts

Find the pinctrl_gpio_key node and comment out the multiplexing configuration for the target GPIO.

pinctrl_gpio_key: gpiokeygrp {
    fsl,pins = <
        /*MX8MP_IOMUXC_SAI2_TXFS__GPIO4_IO24    0x159
        MX8MP_IOMUXC_SAI1_TXD6__GPIO4_IO18  0x159*/
    >;
};

For other GPIOs, you can refer to the official Pin Multiplexing Table (Pinmux Table) to identify and modify the corresponding configurations.

Annotate the calls to GPIO in the device tree

Simply commenting out the pin multiplexing is not enough. If there are still nodes in the device tree that reference these GPIOs (for example, in gpio-keys), the Linux kernel will still attempt to claim these pins during boot.

Continue to search in OK8MP-C.dts for the keys node and comment out its GPIO pin references.

keys {
    compatible = "gpio-keys";
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_gpio_key>;
    
    up {
        label = "GPIO Key UP";
        linux,code = <103>;
        debounce-interval = <20>;
        /*gpios = <&gpio4 24 GPIO_ACTIVE_LOW>;*/
    };
    down {
        label = "GPIO Key DOWN";
        linux,code = <108>;
        debounce-interval = <20>;
        /*gpios = <&gpio4 18 GPIO_ACTIVE_LOW>;*/
    };
};

Additional Steps for M-Core GPIO Interrupt Usage

When the M-Core needs to use a GPIO for interrupts (and the pin does not belong to the GPIO1 group), the A-Core must not only release that specific GPIO but also comment out the entire GPIO controller node for that group in the device tree.

Taking gpio2 as an example, edit the file:

OK8MP-linux-kernel/arch/arm64/boot/dts/freescale/imx8mp.dtsi

Comment out the relevant section as shown below:

/*gpio2: gpio@30210000 {
    compatible = "fsl,imx8mp-gpio", "fsl,imx35-gpio";
    reg = <0x30210000 0x10000>;
    interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>,
                 <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
    clocks = <&clk IMX8MP_CLK_GPIO2_ROOT>;
    gpio-controller;
    #gpio-cells = <2>;
    interrupt-controller;
    #interrupt-cells = <2>;
};*/

Note: After commenting out this node, Linux will no longer register this GPIO controller, completely releasing it for M-Core use.

Verification

After applying the above modifications, recompile and flash the kernel. At this point:

The A-Core will no longer occupy the relevant GPIOs;

The M-Core can access and configure them normally, for example as interrupt inputs;

There will be no resource conflicts or device tree loading warnings.

By following the methods outlined in this document, you can safely release GPIOs from the OK8MP A-Core, providing the M-Core with an independent and controlled resource access channel.