topic i.MX8M Plus: Linux kernel panic (Asynchronous SError) after bootaux M7 firmware execution in i.MX Processors

i.MX8M Plus: Linux kernel panic (Asynchronous SError) after bootaux M7 firmware execution

dskim2 — Mon, 20 Apr 2026 05:47:58 GMT

Platform:
i.MX8M Plus EVK (LPDDR4)
Linux kernel: 5.10.72
U-Boot: SPL 2023.04-lf_v2023.04+gaf7d004eaf

Issue:
Linux kernel crashes with Asynchronous SError Interrupt when Cortex-M7 firmware is executed via U-Boot bootaux command before Linux boot completes.

Steps to reproduce:
1. Load M7 firmware in U-Boot:
fatload mmc 2:1 0x48000000 rpmsg_lite_str_echo_rtos.bin
cp.b 0x48000000 0x7e0000 0x20000
bootaux 0x7e0000

2. Boot Linux:
boot

Result:
Kernel panic occurs during booting:

Observation:
- U-Boot operation is stable
- Issue only occurs during Linux boot when M7 firmware is already running

Please see attached full log file and m core project file ( mcuxpresso for vs code ).

Best Regards

Re: i.MX8M Plus: Linux kernel panic (Asynchronous SError) after bootaux M7 firmware execution

EmbeddedExpertise — Mon, 20 Apr 2026 21:54:48 GMT

Hi,

Looks like a resource conflict between the processor domains. Did you check that the base address of the shared memory matches on both sides?

On the M7 you have something like
# define RPMSG_LITE_SHMEM_BASE (0x55000000U)

And this must match the rpmsg carveout defined in the device tree on the Linux side.

I'm sorry to not be more accurate, as this is quite old in my memory.

As a side note, loading the m7 binary in U-Boot definitely works (I did it successfully in a couple of projects) but is not the recommended way any longer. Remoteproc is. Remoteproc can take care of loading the binary, resetting the remote, and setting up the communication channels. This saves quite a lot of synchronization headaches on startup, or when one domain unexpectedly resets.

Cheers,
--
Thierry
emb-exp.com

Re: i.MX8M Plus: Linux kernel panic (Asynchronous SError) after bootaux M7 firmware execution

Manuel_Salas — Thu, 23 Apr 2026 18:57:32 GMT

Hello @dskim2

I hope you are doing very well.

As @EmbeddedExpertise mentioned, It is highly recommended to use Remoteproc instead of load the Binary from U-boot.

But, you can to run the environment variable in U-boot called prepare_mcore:

u-boot=> run prepare_mcore

If the issue is still there, we can start to check device tree for conflict of resources and IOMUX from the Cortex M application.

Best regards,

Salas.