Blinking led application and kernel panic

slou26 · July 16, 2025, 11:47am

Hello,
We’re still working with Torizon OS Easy Pairing 7.2.0 and Verdin iMX8M Mini DualLite 1GB.

We’ve successfully built and launched the Gpio cpp example.
We launched the application from the Uboot (led is blinking)
and once , we start the kernel with the 'boot ’ command , we have an exception and kernel panic

Verdin iMX8MM # boot
MMC: no card present
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
969 bytes read in 1 ms (946.3 KiB/s)
## Executing script at 50280000
7044 bytes read in 2 ms (3.4 MiB/s)
66691 bytes read in 3 ms (21.2 MiB/s)
44 bytes read in 2 ms (21.5 KiB/s)
Working FDT set to 50200000
Applying Overlay: verdin-imx8mm_hmp_overlay.dtbo
1685 bytes read in 2 ms (822.3 KiB/s)
11459431 bytes read in 80 ms (136.6 MiB/s)
13131069 bytes read in 92 ms (136.1 MiB/s)
   Uncompressing Kernel Image to 0
## Flattened Device Tree blob at 50200000
   Booting using the fdt blob at 0x50200000
Working FDT set to 50200000
   Loading Device Tree to 000000007cec2000, end 000000007cef5fff ... OK
Working FDT set to 7cec2000
Modify /vpu_g1@38300000:status disabled
Modify /vpu_g2@38310000:status disabled
Modify /vpu_h1@38320000:status disabled
Modify /soc@0/blk-ctrl@38330000:status disabled
Delete node /cpus/cpu@2
Delete node /cpus/cpu@3
Update node /thermal-zones/cpu-thermal/cooling-maps/map0, cooling-device prop

Starting kernel ...

[    0.979306] imx-drm display-subsystem: no available port
Starting systemd-udevd version 255.17^
sysroot.readonly configuration value: 0 (fs writable: 1)
Using legacy ostree bind mount for /
[    8.685335] Unable to handle kernel paging request at virtual address ffffffc0829acfff
[    8.793890] Mem abort info:
[    8.855259]   ESR = 0x0000000096000007
[    8.891450]   EC = 0x25: DABT (current EL), IL = 32 bits
[    8.923597]   SET = 0, FnV = 0
[    8.927348]   EA = 0, S1PTW = 0
[    8.930802]   FSC = 0x07: level 3 translation fault
[    8.935883] Data abort info:
[    8.938783]   ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000
[    8.944273]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    8.960994]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    8.967097] swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000004978e000
[    8.980723] [ffffffc0829acfff] pgd=100000007ffff003, p4d=100000007ffff003, pud=100000007ffff003, pmd=100000004469d003, pte=0000000000000000
[    8.994681] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP
[    9.000981] Modules linked in: spi_imx nvmem_snvs_lpgpr(+) imx_sdma(+) imx8mm_thermal snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma imx_rproc(+) cfg80211 uio_pdrv_genirq uio openvswitch nsh nf_conncount nf_nat libcomposite galcore(O) fuse nfnetlink lontium_lt8912b ti_sn65dsi83 sec_mipi_dsim_imx display_connector sec_dsim
[    9.029461] CPU: 0 PID: 424 Comm: (udev-worker) Tainted: G           O       6.6.84-7.2.0-g87bfb710b6f1 #1-Torizon
[    9.039815] Hardware name: Toradex Verdin iMX8M Mini on Verdin Development Board (DT)
[    9.047647] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    9.054612] pc : rproc_handle_resources.constprop.0+0x78/0x1d0
[    9.060463] lr : rproc_boot+0x37c/0x57c
[    9.064306] sp : ffffffc0827836f0
[    9.067622] x29: ffffffc0827836f0 x28: ffffffc0829ad003 x27: 0000000000000000
[    9.074768] x26: 0000000000000000 x25: ffffff8003f51038 x24: ffffffc08149b4e0
[    9.081910] x23: ffffffc081c87130 x22: 00000000ffffffff x21: ffffff8003f51000
[    9.089053] x20: 00000000000003fd x19: ffffffc0829acfff x18: fffffffffffc6490
[    9.096197] x17: ffffffbfbe723000 x16: ffffffc080008000 x15: ffffffffffffffff
[    9.103342] x14: ffffffffffffffff x13: ffffffffffffffff x12: ffffffffffffffff
[    9.110487] x11: ffffffffffffffff x10: ffffffffffffffff x9 : ffffffffffffffff
[    9.117631] x8 : ffffffffffffffff x7 : ffffffffffffffff x6 : ffffffffffffffff
[    9.124775] x5 : ffffff8004b22800 x4 : 00000000000003fc x3 : ffffff8004b22780
[    9.131917] x2 : fffffffffffffff0 x1 : ffffffc0829ad000 x0 : ffffffc0829ad000
[    9.139061] Call trace:
[    9.141508]  rproc_handle_resources.constprop.0+0x78/0x1d0
[    9.147004]  rproc_boot+0x37c/0x57c
[    9.150498]  rproc_add+0x184/0x190
[    9.153904]  imx_rproc_probe+0x4b8/0x5c4 [imx_rproc]
[    9.158889]  platform_probe+0x68/0xc8
[    9.162561]  really_probe+0x188/0x3c4
[    9.166230]  __driver_probe_device+0x7c/0x16c
[    9.170590]  driver_probe_device+0x3c/0x110
[    9.174777]  __driver_attach+0xf0/0x1f8
[    9.178615]  bus_for_each_dev+0x7c/0xdc
[    9.182462]  driver_attach+0x24/0x30
[    9.186043]  bus_add_driver+0x110/0x234
[    9.189885]  driver_register+0x5c/0x124
[    9.193723]  __platform_driver_register+0x28/0x34
[    9.198434]  imx_rproc_driver_init+0x20/0x1000 [imx_rproc]
[    9.203935]  do_one_initcall+0x58/0x29c
[    9.207781]  do_init_module+0x58/0x1e4
[    9.211540]  load_module+0x20b0/0x2198
[    9.215292]  init_module_from_file+0x88/0xcc
[    9.219566]  __arm64_sys_finit_module+0x254/0x34c
[    9.224278]  invoke_syscall.constprop.0+0x50/0xec
[    9.228992]  do_el0_svc+0xa8/0xc8
[    9.232313]  el0_svc+0x40/0x12c
[    9.235477]  el0t_64_sync_handler+0x120/0x12c
[    9.239849]  el0t_64_sync+0x190/0x194
[    9.243520] Code: 8b36c033 9100127c 54000924 d503201f (b9400261)
[    9.249621] ---[ end trace 0000000000000000 ]---
[    9.254244] Kernel panic - not syncing: Oops: Fatal exception
[    9.259992] SMP: stopping secondary CPUs
[    9.263930] Kernel Offset: disabled
[    9.267421] CPU features: 0x0,00000000,00020000,1000420b
[    9.272736] Memory Limit: none
[    9.275797] Rebooting in 5 seconds..

Someone can help us
Thanks
Regards,

ToradexAI · July 16, 2025, 11:48am

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer?

Hello! Thank you for providing detailed logs and background.

What you are experiencing is a kernel panic occurring very early in the boot process, specifically within the remote processor (rproc) subsystem as it attempts to initialize the Cortex-M4 core on your Verdin iMX8M Mini. This is triggered during application of the verdin-imx8mm_hmp_overlay.dtbo device tree overlay, which enables Heterogeneous Multiprocessing (HMP) and the M4 core.

Key Observations

The panic appears in rproc_handle_resources within the imx_rproc_probe function—this means a resource-mapping or memory-setup issue during initialization of the imx_rproc driver for the Cortex-M4 (reference).
It only happens after you manually run the GPIO application from U-Boot and then launch the Linux kernel.

Possible Causes

HMP Overlay Side Effect:
The verdin-imx8mm_hmp_overlay.dtbo overlay enables resources for the M4 core. If the M4 has already been touched, initialized, or memory reserved differently (for instance, by the U-Boot-launched GPIO example), it might cause a conflict or double resource mapping when the kernel’s rproc driver initializes.
Launching Application from U-Boot:
Running the GPIO application from U-Boot before starting Linux may alter the state of the M4 core or its resources (such as TCM, ROM, etc.), causing memory or peripheral conflicts when Linux tries to reset or claim those resources.

How to Troubleshoot

Try Booting Without Launching the M4 Core/Application
- Power up the board and boot Linux/Torizon OS without running the GPIO example from U-Boot.
- Check if the kernel panic still occurs. If the system boots fine, this strongly suggests the U-Boot stage application is causing the conflict.
Remove HMP Overlay
- Temporarily remove the verdin-imx8mm_hmp_overlay.dtbo overlay from your U-Boot/extlinux configuration.
- Boot as usual and see if the kernel panic is resolved. If so, the issue is isolated to HMP functionality and how it’s interacting with the pre-started M4/application.
Only Boot M4 Application From Linux
- The recommended approach for Cortex-M4 development is to let the Linux kernel and imx_rproc driver manage loading, starting, and stopping the M4 core via standard mechanisms (remoteproc, /sys/class/remoteproc, etc.).
- Do not run or boot applications for the M4 directly from U-Boot if Linux is going to manage it afterwards. This can cause unexpected resource conflicts.
Verify Device Trees
- Ensure your device trees (and overlays) match your hardware. Check you don’t have conflicting memory mappings or peripheral allocations.

References & More Reading

Summary

Do not pre-start the M4/application from U-Boot when using HMP device tree overlay and Linux remoteproc.
Let Linux manage the M4 firmware startup exclusively.
Remove the HMP overlay temporarily to confirm root cause.

If you share the exact steps you use to start the application from U-Boot, or whether you are loading a firmware for the M4 from U-Boot, I can provide more targeted advice.

Let me know how it goes or if you need step-by-step instructions for any of the above checks!

Best regards,
Toradex AI Assistant.

bruno.tx · July 16, 2025, 11:57am

Hello @slou26,

I think the issue is one of the following:

The kernel command line argument imx8mm.mcore_booted is missing. To set this, you can use the following on u-boot:

setenv tdxargs clk-imx8mm.mcore_booted=1
saveenv

The GPIO pin which you are using on the Cortex-M is also used on Linux.
- If this is the case, can you clarify which GPIO are you using?

Best Regards,
Bruno

slou26 · July 16, 2025, 12:39pm

thanks for your answer …

The kernel command line imx8mm.mcore_booted is already set.

and we used SODIMM 200 :

#define EXAMPLE_LED_GPIO GPIO5
#define EXAMPLE_LED_GPIO_PIN 11U

bruno.tx · July 16, 2025, 12:47pm

Hello @slou26,

Ok, so it seems that the SPI node is conflicting with the GPIO you are using.
You can check here that SODIMM 200 is used by pinctrl_ecspi2: imx8mm-verdin.dtsi « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

Therefore, you will need to disable ecspi2 (which uses pinctrl_ecspi2) on your device tree or on a device tree overlay.
This can be done as follows:

&ecspi2 {
	status = "disabled";
};

If you have any questions, please feel free to reach out.

Best Regards,
Bruno

slou26 · July 16, 2025, 1:19pm

I modified the overlay but still the same error

slou26 · July 16, 2025, 1:24pm

I tried with another GPIO ( SODIMM_206 ) and same thing

bruno.tx · July 16, 2025, 1:47pm

Hello @slou26,

This may be related to some interrupt configuration, interrupts are based on the GPIO bank and cannot be shared between Cortex-M and Cortex-A.
It should still be possible to configure the pin as an output or input, as long as it is not a source of interrupts.
I will try to reproduce the issue here and check possible solutions.

Best Regards,
Bruno

slou26 · July 16, 2025, 1:56pm

Ok thanks … If I launch the blinking led application with remote proc once the kernel has started , no problem, it works …
But if I try with RPMSG String Echo example, it’s the opposite … I can run it from the uboot and start the kernel after without problem, but it fails if I run it with remote proc ( kernel panic )
Could you check on your side, please ?

bruno.tx · July 17, 2025, 2:08pm

Hello @slou26,

Just to give you an update, I have been able to reproduce the issue and try a few possible solutions.
However at this point I have not found a working solution.

Once there are further updates I will send them here.

Best Regards,
Bruno