AOT Zephyr support

[jucm8]

I'm currently testing AOT in Zephyr, and I'm struggling to understand some things.

This readme states that AOT does not work on the ESP32C3. Can someone explain the reason why this is the case? What is the difference between the qemu_riscv32 and ESP32C3 platforms, so that AOT works on the former, but not on the latter?

Also, is there any kind of compatibility table, which shows what Zephyr platforms support each feature?

Thank you.

[TianlongLiang]

Generally speaking, even though it's the same architecture, the toolchain for an embedded device will differ from a normal desktop
one(In your case, could be riscv32-esp-elf-gcc vs riscv32-unknown-elf-gcc).
The Memory layout and elf section will all be different, resulting in AOT works on one target, but not on the other.

I am not sure whether esp32c3 is still unsupported right now, you can try it out to see its current status.

Also, is there any kind of compatibility table, which shows what Zephyr platforms support each feature?

The Zephyr platform is a rather vague term that the actual support really depends on the board config, I would say most wasm language features are supported, but some runtime features like Zephry user mode, and threading depend on the actual hardware.

[jucm8]

Hello, thanks for answering! I've been further testing this issue.

I've working with two boards: esp32c3_devkitm (RISCV) and esp32_devkitc_wroom/esp32/procpu (XTENSA). I haven't managed to get AOT working on neither of those using Zephyr. However, AOT works fine in both of these boards using ESP-IDF.

Here are the errors I get on each board using Zephyr:

esp32c3_devkitm

<err> os:
<err> os:  mcause: 1, Instruction Access fault
<err> os:   mtval: 3fc95ec4
<err> os:      a0: 3fc9ab50    t0: 4005890e
<err> os:      a1: 00000000    t1: 3fc95ec4
<err> os:      a2: 00000898    t2: ffffffff
<err> os:      a3: 3fc903a4    t3: 42002f64
<err> os:      a4: 3fc95ec4    t4: 0000004c
<err> os:      a5: 3fc903a4    t5: 3fc95ce0
<err> os:      a6: 00000002    t6: 3fc95b5c
<err> os:      a7: 3fc903a4
<err> os:      sp: 3fc902a0
<err> os:      ra: 42002f78
<err> os:    mepc: 3fc95ec4
<err> os: mstatus: 00001880
<err> os:
<err> os: call trace:
<err> os:       0: sp: 3fc902b0 ra: 42013eb0
<err> os:       1: sp: 3fc902c0 ra: 4201432e
<err> os:       2: sp: 3fc902e0 ra: 420005b4
<err> os:       3: sp: 3fc90300 ra: 420005b4
<err> os:       4: sp: 3fc90320 ra: 42000796
<err> os:       5: sp: 3fc90340 ra: 42014eae
<err> os:       6: sp: 3fc90390 ra: 42002258
<err> os:       7: sp: 3fc903f0 ra: 42015b40
<err> os:
<err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
<err> os: Current thread: 0x3fc92b80 (unknown

esp32_devkitc_wroom

[00:00:00.158,000] <err> os:  ** FATAL EXCEPTION
[00:00:00.158,000] <err> os:  ** CPU 0 EXCCAUSE 2 (instr fetch error)
[00:00:00.158,000] <err> os:  **  PC 0x3ffbbc58 VADDR 0x3ffbbc58
[00:00:00.158,000] <err> os:  **  PS 0x60b20
[00:00:00.158,000] <err> os:  **    (INTLEVEL:0 EXCM: 0 UM:1 RING:0 WOE:1 OWB:11 CALLINC:2)
[00:00:00.158,000] <err> os:  **  A0 0x800e099f  SP 0x3ffb8200  A2 0x3ffbbc58  A3 0x3ffc61f8
[00:00:00.158,000] <err> os:  **  A4 0x3ffb8340  A5 0x3ffb8340  A6 0  A7 0x1
[00:00:00.158,000] <err> os:  **  A8 0x800e5db0  A9 0x3ffb81f0 A10 0x3ffc61f8 A11 0
[00:00:00.158,000] <err> os:  ** A12 0x8b8 A13 0x80000000 A14 0 A15 0x864
[00:00:00.158,000] <err> os:  ** LBEG 0x4000c46c LEND 0x4000c477 LCOUNT 0xffffffff
[00:00:00.158,000] <err> os:  ** SAR 0x1a
[00:00:00.158,000] <err> os:  **  THREADPTR 0


Backtrace:0x3ffbbc55:0x3ffb8200  |<-CORRUPTED

[00:00:00.158,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:00.158,000] <err> os: Current thread: 0x3ffb5f10 (unknown)
[00:00:00.259,000] <err> os: Halting system

I think the issue might be related to memory protection. The problem could be that the memory location where the AOT code is copied (DRAM) does not permit execution access. Here's an that might be related to this.

Thank you!

[TianlongLiang]

I think the issue might be related to memory protection

It's likely that is the issue, I have encountered a similar issue in Zephyr before, and I remembered that my solution was to modify the linking script(linker.ld) or device tree file(dts and dtsi) in Zephyr, making the global heap buf located in the executable memory region. You can try it to see whether it helps.