IMX8MP GPIO interrupts for M7

Good day.
I’ll say right away that I read similar topics on the forum, took all the suggestions from there, but never achieved the result.

What I’m trying to do is implement GPIO interrupts for the M7 while the A53 is running Linux on the IMX8MP. My current points:

  • Yocto multimedia image.
  • I’m using RPMSG for intercore communication, so I need to run M7 firmware from u-boot for intercore communication registration.
  • I also need a lot of memory for firmware, so we are using DDR space (MIMX8ML8xxxxx_cm7_ddr_ram.ld).
  • I disabled whole GPIO in Linux DTS:

&gpio3 {
status = “disabled”;
};

  • Then I need to use RDC for correct recourses sharing. And I used an example from SDK - \evkmimx8mp\driver_examples\rdc, modified it - added interrupt for button and output msg. by UART.

After this there are several possible options:

  1. I load the u-boot, start debugging the firmware via JTAG and continue loading Linux. In this case, the M7 firmware starts, but freezes at a certain point after loading Linux.
  2. I load Linux and after that I start debugging the firmware via JTAG - in this case, the interruption for M7 works in parallel with Linux (but RPMSG does not work, since the firmware was loaded after Linux was loaded)
  3. If the same firmware is loaded using u-boot at system startup (m7boot=ext4load mmc 2:2 ${loadaddr} ${m7image}; cp.b ${loadaddr} 0x80000000 ${m7image_size}; dcache flush; bootaux 0x80000000), all firmware works, interrupts do not work.
  4. When loading an ELF file through a remoteproc, a crash occurs (I haven’t figured this out much yet)

In the example for the DRC, it is indicated that resource management does not work under u-boot and for the DDR version. I did the same for MIMX8ML8xxxxx_cm7_ram.ld - the result is the same. It is possible that from the u-boot level this will not work at all - what to do with RPMSG in this case?(

But I also found on the NXP forum an indication that you need to manually register the RDC in the u-boot:

into imx_rdc_cfg in imx8mp_bl31_setup.c:

RDC_PDAPn(RDC_PDAP_GPIO3, D1R | D1W)

But before it’s necessary to build the ARM trusted firmware - the ATF/TF-A Branch is lf_v2.6 and add RDC resources there.

Will this help or not and what could be the problem?
Regards, Stanislav.

I’m not sure if this suggestion works for you, but as I explained here I was able to set the value for one of the RDC_PDAPn (in my case RDC_PDAP105) from u-boot

Verdin iMX8MP # mw.l 0x303d05a4 0xff

without having to customize and rebuild the ARM trusted firmware

Thank you @vix

I integrated ATF into u-boot, made changes for GPIO3 (0x303d0408) and RDC (0x303d0474), also changed this registers manually for u-boot as you described - mw.l 0x303d0408 0x0C. Tested any variants - set and for A and for M - the same result - GPIO interrupt for M7 dosn’t work.

Do you know what registers can also be reset via JTAG debug?

ATF resolved the current issue. I mixed up the files and added RDC_PDAPn in imx8mm_bl31_setup.c. When I recompiled ATF with changes in imx8mp_bl31_setup.c - interrupts started to work.
Thanks, Stanislav.

Hi @Stan88
I’ve just found exactly the same issue on my Verdin iMX8M-Plus (i.e., when I run my application from u-boot, interrupts on M7 are fired; when I run it while Torizon Os is running, interrupt on M7 core are not fired anymore).

I read that you were able to fix the issue rebuilding ATF, but it’s not 100% clear to me what is the real reason for this behavior.

Can you explain a little bit this?

What do you mean with

Then I need to use RDC for correct recourses sharing. And I used an example from SDK - \evkmimx8mp\driver_examples\rdc, modified it - added interrupt for button and output msg. by UART.

Thanks a lot.

Hello @vix,

Please check if my answer here helps: Interrupts not fired on M7 when Torizon OS is running - #5 by rudhi.tx