Skip to main content

mproc-mailbox

Cortex-M55-HP ↔ Cortex-M55-HE mailbox round-trip on AEN. HP-side stages a payload in shared SRAM, signals the peer via the hardware mailbox, waits for a reply, reads the result back.

This is the first project to declare both M55 cores as real build targets. m55_hp (app: ./src) and m55_he (app: ./peer) are both project cores, so one tan build produces both images — the HE side is no longer a written-but-unbuilt peer backed by the topology-default alp-stock-shim placeholder.

Source: examples/multicore/mproc-mailbox/.

What it shows​

  • Opening a shared-memory region with alp_shmem_open against the DT-alias-anchored name "alp_shmem0" (the alias is declared in boards/native_sim_native_64.overlay for the host smoke build; the orchestrator emits it from board.yaml's ipc: block on real silicon).
  • Opening the hardware mailbox with alp_mbox_open(.channel = 0, .peer = ALP_CORE_M55_HE).
  • Getting a raw pointer + size view with alp_shmem_view and staging the payload with memcpy — the carve-out stays at its non-cacheable default, which on this part means CONFIG_DCACHE=n on both cores (see below).
  • Signalling the peer with alp_mbox_send carrying a small (offset, length) tuple pointing at the staged bytes.
  • Registering an alp_mbox_set_callback to drain the peer's reply tuple from the mbox-ISR thread, then memcpy-ing the response out of shmem.

board.yaml​

One project, both cores:

som:
  sku: E1M-AEN801

preset: e1m-evk

cores:
  m55_hp:
    app: ./src
    peripherals: [mproc]
  m55_he:
    app: ./peer
    peripherals: [mproc]

ipc:
  - { kind: raw_shmem, endpoints: [m55_hp, m55_he], carve_out_kb: 4, name: alp_shmem0 }

diagnostics:
  log_level: info

name: alp_shmem0 is not a free-form label like an RPMsg channel name — it matches the DT-alias name that the mproc Zephyr backend and both main.c files hardcode.

Cross-core cache coherency — CONFIG_DCACHE=n​

The shared SRAM0 region is read and written by both M55 cores, each with its own D-cache. Left cached, a core's writes are invisible to its peer: the symptom is a silent false negative — a peer that in fact ran is reported as never having run.

Two mechanisms deliver CONFIG_DCACHE=n here, and they currently coexist:

  1. Explicit. This example is one of eight that carry CONFIG_DCACHE=n in their own prj.conf — both prj.conf and peer/prj.conf set it. The hand-written lines are bench-proven and are kept deliberately, so that a regression can be attributed to one mechanism or the other.
  2. Emitted. Declaring an ipc: entry of kind: raw_shmem now emits CONFIG_DCACHE=n automatically for every core listed in that entry's endpoints — here m55_hp and m55_he — unless the entry sets cacheable: true. This applies to raw_shmem only; it does not apply to kind: rpmsg or kind: mailbox_only.

See the board.yaml reference for the emit rule.

Build​

Both images come out of one project build — tan reads its targets from board.yaml:

tan build --project examples/multicore/mproc-mailbox

Each core can still be built standalone with west build while iterating on one side:

# native_sim (HP-side only; no peer core)
west build -b native_sim/native/64 alp-sdk/examples/multicore/mproc-mailbox
west build -t run

# HP side.
west build -b ensemble_e8_dk/ae402fa0e5597le0/rtss_hp alp-sdk/examples/multicore/mproc-mailbox
west flash

# HE side.
west build -b ensemble_e8_dk/ae402fa0e5597le0/rtss_he alp-sdk/examples/multicore/mproc-mailbox/peer
west flash

Each west line above is a plain single-image build with an explicit -b <target> — west build / west flash were never retired. The retired west alp-build twin has no drop-in replacement that takes -b: tan build reads its targets from board.yaml instead.

:::note Dual-core AEN flashing — the two cores now get disjoint slot0 windows Every generated AEN board _defconfig carries CONFIG_USE_DT_CODE_PARTITION=y (emitted by the board generator; no board.yaml key is involved), so an AEN application links into slot0_partition in MRAM rather than the raw MRAM base — CONFIG_FLASH_LOAD_OFFSET follows the devicetree.

Both AEN801 core boards used to declare the same slot0 window, so flashing a dual-core project silently overwrote one image with the other. That is fixed: the two cores now get disjoint slot0 windows. :::

Flash the HP image into the RTSS-HP slot and the HE peer image into the RTSS-HE slot. Once both are running:

[mproc] init mbox + shmem
[mproc] sending payload  "hello-from-HP" (13 bytes)
[mproc] HE replied via mbox callback
[mproc] HE replied       "echo: hello-from-HP" (19 bytes)
[mproc] done

HiL verification of the round-trip is still ahead.

See also​

Questions about this page? Discuss in Community Forum