Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IMX8MM: Running fail a zephyr sample in the imx8mm #46277

Closed
MinSteve opened this issue Jun 4, 2022 · 2 comments
Closed

IMX8MM: Running fail a zephyr sample in the imx8mm #46277

MinSteve opened this issue Jun 4, 2022 · 2 comments
Labels
bug The issue is a bug, or the PR is fixing a bug platform: NXP NXP

Comments

@MinSteve
Copy link

MinSteve commented Jun 4, 2022

Describe the bug
Running fail a zephyr hello_world sample in the imx8mm

  • Target platform: MYS-8MMX using IMX8M Mini SoC
  • I check in u-boot DTS and kernel dts. They have initialized uart4 and a zephyr still initializes uart4 with a different clock.
    I tried to rebuild u-boot without declaring the uart4 node in the DTS file but it still not working.

To Reproduce
Steps to reproduce the behavior:

  1. west build -b mimx8mm_evk samples/hello_world
  2. dtc -O dtb -o zephyr.dtb build/zephyr/zephyr.dts
  3. copy zephyr.dtb to boot partition in the SD card
  4. setenv fdt_file zephyr.dtb (in uboot)
  5. fatload mmc 0:1 0x7e0000 zephyr.bin;bootaux 0x7e0000

Impact
The system can't run

Logs and console output
After I set the u-boot environment, I run the command
go 0x7e0000

```
u-boot=> go 0x7e0000
Starting application at 0x007E0000 ...
"Synchronous Abort" handler, esr 0x8600000f
elr: ffffffff82ad2000 lr : 0000000040206578 (reloc)
elr: 00000000007e0000 lr : 00000000bdf14578
x0 : 0000000000000001 x1 : 00000000bc913458
x2 : 00000000bc913458 x3 : 00000000007e0000
x4 : 00000000ffffffff x5 : 00000000bc903cf8
x6 : 0000000000000030 x7 : 000000000000000f
x8 : 00000000bc9046e8 x9 : 0000000000000008
x10: 00000000ffffffd0 x11: 0000000000000010
x12: 0000000000000006 x13: 000000000001869f
x14: 00000000bc9049c8 x15: 0000000000000001
x16: 00000000007e0000 x17: 0000000000000000
x18: 00000000bc90dd88 x19: 00000000bc913458
x20: 00000000007e0000 x21: 0000000000000002
x22: 00000000bc913450 x23: 00000000bdfce5f0
x24: 0000000000000002 x25: 0000000000000000
x26: 0000000000000000 x27: 0000000000000000
x28: 00000000bc913060 x29: 00000000bc904720

Resetting CPU ...
```

If I set u-boot environment and I run boot
```
[ 0.000000] SError Interrupt on CPU0, code 0xbf000002 -- SError
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.3-2.0.0+gc05efad #1
[ 0.000000] Hardware name: NXP i.MX8M Mini EVK board (DT)
[ 0.000000] pstate: 80000085 (Nzcv daIf -PAN -UAO)
[ 0.000000] pc : new_slab+0x198/0x360
[ 0.000000] lr : new_slab+0x1a0/0x360
[ 0.000000] sp : ffff800011fd3dd0
[ 0.000000] x29: ffff800011fd3dd0 x28: 0000000041e00018
[ 0.000000] x27: 0000000000000000 x26: ffff80001176a738
[ 0.000000] x25: ffff000020180280 x24: 0000000000000000
[ 0.000000] x23: ffff000020180300 x22: ffff800011fe27c0
[ 0.000000] x21: 0000000000000005 x20: ffff800011ae7a58
[ 0.000000] x19: fffffe0000606000 x18: 0000000000000020
[ 0.000000] x17: 0000000000018000 x16: 0000000000000000
[ 0.000000] x15: 0000000000000100 x14: 0000000000000001
[ 0.000000] x13: 0000000000000000 x12: 0000000000000000
[ 0.000000] x11: 0000000000000000 x10: 0000000000000000
[ 0.000000] x9 : ffff800098040000 x8 : 0000000000000000
[ 0.000000] x7 : ffff800098040000 x6 : 0000000000000001
[ 0.000000] x5 : 000000000000fffd x4 : ffff0000a9be0c17
[ 0.000000] x3 : 0000000040002000 x2 : 0000000080010400
[ 0.000000] x1 : 0000000000000080 x0 : ffff800011ae7a58
[ 0.000000] Kernel panic - not syncing: Asynchronous SError Interrupt
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.3-2.0.0+gc05efad #1
[ 0.000000] Hardware name: NXP i.MX8M Mini EVK board (DT)
[ 0.000000] Call trace:
[ 0.000000] dump_backtrace+0x0/0x140
[ 0.000000] show_stack+0x14/0x20
[ 0.000000] dump_stack+0xb4/0xf8
[ 0.000000] panic+0x158/0x324
[ 0.000000] nmi_panic+0x84/0x88
[ 0.000000] arm64_serror_panic+0x74/0x80
[ 0.000000] do_serror+0x80/0x138
[ 0.000000] el1_error+0x84/0xf8
[ 0.000000] new_slab+0x198/0x360
[ 0.000000] __kmem_cache_create+0x1b4/0x568
[ 0.000000] create_boot_cache+0xb8/0xf4
[ 0.000000] kmem_cache_init+0x58/0x118
[ 0.000000] start_kernel+0x224/0x44c
```

Environment

  • OS: Linux
  • Toolchain: Zephyr SDK
  • Newest commit in develop branch

Additional context

  1. The device tree used in u-boot
    https://github.com/MYiR-Dev/myir-imx-uboot/blob/develop/arch/arm/dts/myir-imx8mm.dtsi
  2. The device tree used in Linux kernel
    https://github.com/MYiR-Dev/myir-imx-linux/blob/develop/arch/arm64/boot/dts/myir/mys-imx8mm-evk.dts
  3. The device tree used for FreeRTOS core-M4
    https://github.com/MYiR-Dev/myir-imx-linux/blob/develop/arch/arm64/boot/dts/myir/mys-imx8mm-evk-rpmsg.dts
@MinSteve MinSteve added the bug The issue is a bug, or the PR is fixing a bug label Jun 4, 2022
@henrikbrixandersen
Copy link
Member

To Reproduce Steps to reproduce the behavior:

1. west build -b mimx8mm_evk samples/hello_world

2. dtc -O dtb -o zephyr.dtb build/zephyr/zephyr.dts

3. copy zephyr.dtb to boot partition in the SD card

4. setenv fdt_file zephyr.dtb (in uboot)

5. fatload mmc 0:1 0x7e0000 zephyr.bin;bootaux 0x7e0000

Zephyr doesn't use the zephyr.dts (nor the device tree blob) at runtime, so no need to load that (see https://docs.zephyrproject.org/latest/build/dts/api-usage.html#a-note-for-linux-developers). Have you tried just loading and running the zephyr.elf file from U-Boot?

@danieldegrasse
Copy link
Collaborator

Logs and console output
After I set the u-boot environment, I run the command
go 0x7e0000

To be clear, are you running go 0x7e0000 here to boot the secondary M4 core? I'm not very familiar with this platform, but generally bootaux should start the auxiliary core, and go should be used for the application core, correct?

@zephyrproject-rtos zephyrproject-rtos locked and limited conversation to collaborators Jun 15, 2022
@fabiobaltieri fabiobaltieri converted this issue into discussion #46554 Jun 15, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
bug The issue is a bug, or the PR is fixing a bug platform: NXP NXP
Projects
None yet
Development

No branches or pull requests

3 participants