tan-cli 0.7.0__py3-none-any.whl

tan/templates/vendored/minimal/E1M-V2N101/testcase.yaml

@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: Apache-2.0
+
+sample:
+  name: hello-world
+  description: |
+    Minimal "first program" example.  Prints a periodic heartbeat
+    so customers can verify their toolchain + flash flow + log
+    console before tackling peripheral wiring.  Builds on both
+    EVKs: no board-specific macros required.
+
+tests:
+  alp_sdk.example.hello_world.e1m_x_evk:
+    extra_args: EXTRA_CONF_FILE=generated/alp.conf
+    platform_allow:
+      - native_sim
+      - native_sim/native/64
+    integration_platforms:
+      - native_sim/native/64
+    extra_configs:
+      - 'CONFIG_COMPILER_OPT="-DALP_BOARD_E1M_X_EVK"'
+    tags:
+      - alp-sdk
+      - example
+      - hello-world
+      - v2n
+    harness: console
+    harness_config:
+        type: one_line
+        regex:
+          - "\\[hello\\] done"
+  alp_sdk.example.hello_world.e1m_evk:
+    extra_args: EXTRA_CONF_FILE=generated/alp.conf
+    platform_allow:
+      - native_sim
+      - native_sim/native/64
+    integration_platforms:
+      - native_sim/native/64
+    extra_configs:
+      - 'CONFIG_COMPILER_OPT="-DALP_BOARD_E1M_EVK"'
+    tags:
+      - alp-sdk
+      - example
+      - hello-world
+      - aen
+    harness: console
+    harness_config:
+        type: one_line
+        regex:
+          - "\\[hello\\] done"

tan/templates/vendored/multicore-mailbox/E1M-AEN801/CMakeLists.txt

@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: Apache-2.0
+
+cmake_minimum_required(VERSION 3.20)
+
+find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
+project(mproc_mailbox LANGUAGES C)
+
+target_sources(app PRIVATE src/main.c)

tan/templates/vendored/multicore-mailbox/E1M-AEN801/README.md

@@ -0,0 +1,120 @@
+# mproc-mailbox
+
+Per-peripheral example for `<alp/mproc.h>`.  Demonstrates the
+M55-HP side of a Cortex-M55-HP ↔ Cortex-M55-HE mailbox roundtrip
+on AEN: stage a payload in shared SRAM, signal the peer via the
+hardware mailbox, wait for a reply, read the result back.
+
+## What this shows
+
+- Opening a shared-memory region (`alp_shmem_open`) and a
+  hardware mailbox (`alp_mbox_open`) by portable instance IDs.
+- Resolving a raw pointer view of the shared region with
+  `alp_shmem_view()`, then staging payload bytes by `memcpy`
+  through that pointer (the surface hands back a base pointer +
+  size and trusts the caller to write through it; the region is
+  non-cacheable, so no cache maintenance is needed).
+- Signalling the peer with `alp_mbox_send` carrying a small
+  tuple (offset + length) that points at the staged bytes.
+- Receiving the reply through an inbound callback registered with
+  `alp_mbox_set_callback()` -- it fires on the SDK's mbox thread
+  with the peer's (offset, length) tuple, which `main()` then
+  drains.
+- Reading the peer's echo response back from shared SRAM via the
+  same pointer view.
+
+## Build
+
+### native_sim (no peer core; HP-side init only)
+
+```bash
+# writes ./generated/alp.conf, which west reads below (#866)
+tan generate --target zephyr-conf --core m55_hp --sdk-root "$ALP_SDK_ROOT" --output generated/alp.conf
+west build -b native_sim/native/64 . -- -DEXTRA_CONF_FILE=generated/alp.conf
+west build -t run
+```
+
+Expected output:
+
+```
+[mproc] init mbox + shmem
+[mproc] sending payload  "hello-from-HP" (13 bytes)
+[mproc]   native_sim: no peer core; skipping reply
+[mproc] done
+```
+
+### Real silicon (AEN dual-core, both images built from this project)
+
+The peer-side firmware lives at
+[`./peer/main.c`](peer/main.c) -- HE-side
+image that waits on the same mbox, reads the staged shmem
+payload, and writes back an echo via reverse send.  (alp-sdk's own
+upstream copy of this example lives at
+`examples/multicore/mproc-mailbox/peer/main.c`, not part of this
+scaffolded project.)
+
+`board.yaml` declares both `m55_hp` (`app: ./src`) and `m55_he`
+(`app: ./peer`) as real project cores, so one `tan build` now
+produces both images -- no more topology-default `alp-stock-shim`
+placeholder on the HE side:
+
+```bash
+tan build --project .
+```
+
+Each core can also be built standalone with `west build` directly
+(e.g. while iterating on one side):
+
+```bash
+# HP side.
+# writes ./generated/alp.conf, which west reads below (#866)
+tan generate --target zephyr-conf --core m55_hp --sdk-root "$ALP_SDK_ROOT" --output generated/alp.conf
+west build -b ensemble_e8_dk/ae822fa0e5597ls0/rtss_hp . -- -DEXTRA_CONF_FILE=generated/alp.conf
+west flash
+
+# HE side.
+# writes ./peer/generated/alp.conf, which west reads below (#866)
+tan generate --target zephyr-conf --core m55_he --sdk-root "$ALP_SDK_ROOT" --output peer/generated/alp.conf
+west build -b ensemble_e8_dk/ae822fa0e5597ls0/rtss_he ./peer -- -DEXTRA_CONF_FILE=generated/alp.conf
+west flash
+```
+
+Flash both into the matching SoC partitions (HP -> RTSS-HP slot,
+HE -> RTSS-HE slot) and the roundtrip completes:
+
+```
+[mproc] init mbox + shmem
+[mproc] sending payload  "hello-from-HP" (13 bytes)
+[mproc-peer] request offset=0 len=13
+[mproc-peer] payload  "hello-from-HP"
+[mproc-peer] replied "echo: hello-from-HP" (19 bytes)
+[mproc] HE replied via mbox callback
+[mproc] HE replied       "echo: hello-from-HP" (19 bytes)
+[mproc] done
+```
+
+## Reference
+
+- [`<alp/mproc.h>`](https://github.com/alplabai/alp-sdk/blob/v0.17.0/include/alp/mproc.h) -- mailbox + shmem
+  + hwsem API.
+- [`docs/v1.0-readiness.md`](https://github.com/alplabai/alp-sdk/blob/v0.17.0/docs/v1.0-readiness.md) §4 --
+  this example is one of the v1.0 reference-app flagships; both the
+  HP host and the HE peer now build from this one project, with
+  HiL verification of the round-trip still ahead.
+
+## Before you run this: the channel is not allocated yet
+
+`E1M-AEN801` carries no `memory_map:` in its SoM metadata, so this project's
+shared-memory carve-out cannot be placed and resolves `blocked`:
+
+```
+name: alp_shmem0  kind: raw_shmem  status: blocked
+reason: memory_map.base is TBD for region 'mram_main' in SoM E1M-AEN801; this
+        SoM hasn't been HW-mapped yet so IPC carve-outs cannot be allocated.
+```
+
+The project still configures and builds, and `--emit ipc-contract-h` still
+exits 0 -- it emits `ALP_IPC_*_ADDR 0x0u /* stub: blocked */`. So the mailbox
+roundtrip this example teaches compiles and does nothing until that metadata
+lands. This is
+mapping work not yet done upstream, not a limit of the design.

tan/templates/vendored/multicore-mailbox/E1M-AEN801/board.yaml

@@ -0,0 +1,57 @@
+# board.yaml -- per-app project configuration for the
+# mproc-mailbox example (M55-HP + M55-HE, both real project cores).
+#
+# Targets AEN-Zephyr on both Cortex-M55 cores: `m55_hp` runs the
+# host side (`./src`), `m55_he` runs the peer (`./peer`) that echoes
+# the mailbox payload back.  The SoM's second core no longer ships
+# the topology-default `alp-stock-shim` here -- `tan build` builds
+# both slices from this one project, matching the `ipc:` block's
+# `endpoints: [m55_hp, m55_he]` below.
+som:
+  sku: E1M-AEN801
+
+preset: e1m-evk
+cores:
+  m55_hp:
+    app: ./src
+  m55_he:
+    app: ./peer
+
+# Cross-core shared SRAM + hardware mailbox used to signal the peer.
+# `raw_shmem`, not `rpmsg`: this is the low-level <alp/mproc.h>
+# shmem+mailbox primitive, so the carve-out stays at its non-cacheable
+# default (kconfig.py's `_emit_cross_core_shmem_cache` reads this
+# block and emits CONFIG_DCACHE=n for both m55_hp and m55_he
+# accordingly -- see the comment in prj.conf / peer/prj.conf for the
+# hardware reasoning). `name: alp_shmem0` matches the DT-alias name
+# alp-sdk's `src/backends/mproc/zephyr_drv.c` (a different `src/`
+# than this project's own -- not part of this scaffolded project)
+# and both main.c's hardcode -- it is NOT a free-form label like an
+# rpmsg channel name.
+#
+# #1069 gave E1M-AEN801 a real `memory_map:` (alp-sdk's
+# metadata/e1m_modules/E1M-AEN801.yaml, not part of this scaffolded
+# project), but this carve-out still resolves `status: blocked`
+# (`--emit system-manifest`): the five fine-grained regions
+# (mcuboot/he_slot0/hp_slot0/reserved/storage) are MRAM, not RAM, and are
+# marked `carveout: false` so the allocator can't silently place this
+# raw_shmem ring inside flash-class memory; `mram_main` (the only other
+# region accessible from both m55_hp and m55_he) is ALSO flash-class --
+# its extent equals the SoC's declared App MRAM aperture exactly (the
+# whole-device alias; `base` resolved to 0x80000000 in #2053), not safe
+# as an IPC carve-out target either. The carve-out being blocked does
+# not affect this example:
+# the generated `<alp/system_ipc.h>` / DTS reservation it would drive
+# aren't consumed here (main.c / peer/main.c open "alp_shmem0" by its DT
+# alias, wired by the board overlay directly, not by the orchestrator's
+# resolved address) -- only the `_emit_cross_core_shmem_cache` Kconfig path
+# this PR adds reads this block, and that path doesn't need resolution to
+# fire.
+ipc:
+  - kind: raw_shmem
+    endpoints: [m55_hp, m55_he]
+    carve_out_kb: 4
+    name: alp_shmem0
+
+diagnostics:
+  log_level: info

tan/templates/vendored/multicore-mailbox/E1M-AEN801/boards/native_sim_native_64.overlay

@@ -0,0 +1,40 @@
+/*
+ * Copyright 2026 Alp Lab AB
+ * SPDX-License-Identifier: Apache-2.0
+ *
+ * Overlay declaring alp-shmem0 for the mproc-mailbox example so the
+ * HP-side native_sim build resolves "alp_shmem0" through the new
+ * DT-anchored lookup path (commit 2e9deec, v0.7).  native_sim never
+ * dereferences the address; alp_shmem_view just reports the
+ * DT-anchored base + size verbatim and the example's memcpy is
+ * skipped on the !CONFIG_BOARD_NATIVE_SIM branch.
+ *
+ * On real AEN silicon the alp-shmem0 alias must point at a
+ * reserved-memory carve-out shared between the M55-HP and M55-HE
+ * images.  The orchestrator (alp-sdk's scripts/alp_orchestrate.py,
+ * not part of this scaffolded project) emits the
+ * per-core overlay with the matching alias when the board.yaml v2
+ * declares an ipc[] block; until that ships customers can declare
+ * the alias by hand in a board overlay following this same shape:
+ *
+ *     / {
+ *         alp_shmem0_node: shmem@<carve_out_addr> {
+ *             compatible = "mmio-sram";
+ *             reg = <0x<addr> 0x<size>>;
+ *             status = "okay";
+ *         };
+ *         aliases { alp-shmem0 = &alp_shmem0_node; };
+ *     };
+ */
+
+/ {
+    alp_shmem0_node: shmem@70000000 {
+        compatible = "mmio-sram";
+        reg = <0x70000000 0x1000>;
+        status = "okay";
+    };
+
+    aliases {
+        alp-shmem0 = &alp_shmem0_node;
+    };
+};

tan/templates/vendored/multicore-mailbox/E1M-AEN801/peer/CMakeLists.txt

@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: Apache-2.0
+#
+# HE-side peer image for the mproc-mailbox flagship.  `board.yaml`
+# declares this as the `m55_he` slice's `app:`, so `tan build`
+# builds it alongside `../src` (m55_hp) as a real project core, not
+# the topology-default `alp-stock-shim`.
+
+cmake_minimum_required(VERSION 3.20)
+
+find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
+project(mproc_mailbox_peer LANGUAGES C)
+
+target_sources(app PRIVATE main.c)

tan/templates/vendored/multicore-mailbox/E1M-AEN801/peer/main.c

@@ -0,0 +1,171 @@
+/*
+ * Copyright 2026 Alp Lab AB
+ * SPDX-License-Identifier: Apache-2.0
+ *
+ * mproc-mailbox -- M55-HE side of the dual-core mailbox roundtrip.
+ * Sister to ../src/main.c (the HP-side).
+ *
+ * The pattern this peer shows
+ * ===========================
+ *
+ * The HP-side application code stages a payload in shared memory
+ * and signals this peer through a hardware mailbox.  This peer:
+ *
+ *   1. Opens the same mbox + shmem region.
+ *   2. Registers an mbox callback that fires on each HP send.
+ *   3. In the callback: reads the (offset, length) tuple, pulls
+ *      the payload out of shared memory, builds an echo
+ *      response, writes it back at a different shmem offset,
+ *      and signals the HP via mbox.
+ *
+ * The peer runs forever in a low-power idle loop -- the mbox
+ * callback fires from the SDK's mailbox thread.
+ *
+ * Build status (v1.0 prep)
+ * ========================
+ *
+ * Compiles standalone today, and `board.yaml` declaring both
+ * `m55_hp` (`app: ./src`) and `m55_he` (`app: ./peer`) as real
+ * project cores means one `tan build` already produces both images
+ * through the orchestrator's existing multi-slice path -- no
+ * sysbuild involved.  Each core can also be built standalone with
+ * `west build` and flashed to its own partition.
+ */
+
+#include <stdio.h>
+#include <string.h>
+
+#include <zephyr/kernel.h>
+
+#include "alp/mproc.h"
+#include "alp/peripheral.h"
+
+/* Region name resolved against the alp-shmemN DT aliases.  Must
+ * match the HP side; both peers see the same physical bytes via
+ * the alp-shmem0 alias. */
+#define SHMEM_REGION_NAME "alp_shmem0"
+#define SHMEM_REGION_SIZE 512u
+#define MBOX_CHANNEL      0u
+#define RESPONSE_OFFSET   256u /* must match HP's expectation */
+#define ECHO_PREFIX       "echo: "
+#define MAX_PAYLOAD       128u
+
+static struct {
+	alp_shmem_t *shmem;
+	alp_mbox_t  *mbox;
+	void        *shmem_base;
+	size_t       shmem_size;
+} g_peer;
+
+/* Mailbox inbound-message callback.  Fires when the HP signals
+ * via the shared mbox channel.  Pulls the request out of
+ * shared memory, builds the echo response, stages it back,
+ * signals via mbox.  Runs on the SDK's mailbox thread. */
+static void mbox_inbound(uint32_t channel, const void *data, size_t len, void *user)
+{
+	(void)channel;
+	(void)user;
+	if (len < 8u || g_peer.shmem_base == NULL) {
+		printf("[mproc-peer]   undersized tuple (%zu bytes) -- dropping\n", len);
+		return;
+	}
+
+	const uint8_t *b = data;
+	const size_t   offset =
+	    (size_t)b[0] | ((size_t)b[1] << 8) | ((size_t)b[2] << 16) | ((size_t)b[3] << 24);
+	size_t req_len =
+	    (size_t)b[4] | ((size_t)b[5] << 8) | ((size_t)b[6] << 16) | ((size_t)b[7] << 24);
+	if (req_len > MAX_PAYLOAD) req_len = MAX_PAYLOAD;
+	if (offset + req_len > g_peer.shmem_size) return;
+
+	printf("[mproc-peer] request offset=%u len=%u\n", (unsigned)offset, (unsigned)req_len);
+
+	/* Pull the request bytes out of shared memory.  The region
+     * is non-cacheable, so no cache invalidate is needed before
+     * the read. */
+	char request_buf[MAX_PAYLOAD + 1] = { 0 };
+	memcpy(request_buf, (const uint8_t *)g_peer.shmem_base + offset, req_len);
+	request_buf[req_len] = '\0';
+	printf("[mproc-peer] payload  \"%s\"\n", request_buf);
+
+	/* Build the echo response.  Truncate if prefix + payload
+     * would exceed MAX_PAYLOAD; the protocol is a demo so
+     * silent-truncate is acceptable. */
+	char         response_buf[MAX_PAYLOAD + sizeof(ECHO_PREFIX)] = { 0 };
+	const size_t prefix_len                                      = sizeof(ECHO_PREFIX) - 1u;
+	memcpy(response_buf, ECHO_PREFIX, prefix_len);
+	size_t response_len = prefix_len + req_len;
+	if (response_len > MAX_PAYLOAD) response_len = MAX_PAYLOAD;
+	memcpy(response_buf + prefix_len, request_buf, response_len - prefix_len);
+
+	/* Stage the response at RESPONSE_OFFSET.  HP's mbox callback
+     * reads back via this offset. */
+	memcpy((uint8_t *)g_peer.shmem_base + RESPONSE_OFFSET, response_buf, response_len);
+
+	/* Signal the HP -- (offset, length) tuple pointing at the
+     * staged response. */
+	const uint8_t reply_tuple[8] = {
+		(uint8_t)(RESPONSE_OFFSET & 0xFFu),
+		(uint8_t)((RESPONSE_OFFSET >> 8) & 0xFFu),
+		(uint8_t)((RESPONSE_OFFSET >> 16) & 0xFFu),
+		(uint8_t)((RESPONSE_OFFSET >> 24) & 0xFFu),
+		(uint8_t)(response_len & 0xFFu),
+		(uint8_t)((response_len >> 8) & 0xFFu),
+		(uint8_t)((response_len >> 16) & 0xFFu),
+		(uint8_t)((response_len >> 24) & 0xFFu),
+	};
+	if (alp_mbox_send(g_peer.mbox, reply_tuple, sizeof(reply_tuple), 100u) != ALP_OK) {
+		printf("[mproc-peer]   mbox send failed\n");
+		return;
+	}
+	printf("[mproc-peer] replied \"%s\" (%u bytes)\n", response_buf, (unsigned)response_len);
+}
+
+int main(void)
+{
+	printf("[mproc-peer] HE side coming up\n");
+
+	const alp_shmem_config_t shmem_cfg = {
+		.name = SHMEM_REGION_NAME,
+		.size = SHMEM_REGION_SIZE,
+	};
+	g_peer.shmem = alp_shmem_open(&shmem_cfg);
+
+	const alp_mbox_config_t mbox_cfg = {
+		.channel = MBOX_CHANNEL,
+		.peer    = ALP_CORE_M55_HP,
+	};
+	g_peer.mbox = alp_mbox_open(&mbox_cfg);
+
+	if (g_peer.shmem == NULL || g_peer.mbox == NULL) {
+		printf("[mproc-peer]   open failed: last_err=%d\n", (int)alp_last_error());
+		return 1;
+	}
+
+	if (alp_shmem_view(g_peer.shmem, &g_peer.shmem_base, &g_peer.shmem_size) != ALP_OK) {
+		printf("[mproc-peer]   shmem view failed\n");
+		return 1;
+	}
+
+	if (alp_mbox_set_callback(g_peer.mbox, mbox_inbound, NULL) != ALP_OK) {
+		printf("[mproc-peer]   set_callback failed\n");
+		return 1;
+	}
+
+	printf("[mproc-peer] waiting on mbox channel=%u shmem=%zu bytes\n",
+	       (unsigned)MBOX_CHANNEL,
+	       g_peer.shmem_size);
+
+	/* Steady-state idle.  The mbox callback fires from the SDK
+     * thread on every HP send; main just keeps the system
+     * alive.  k_sleep instead of busy-wait so the core can
+     * enter WFI between events. */
+	for (;;) {
+		k_sleep(K_FOREVER);
+	}
+
+	/* Unreachable but kept for documentation. */
+	alp_mbox_close(g_peer.mbox);
+	alp_shmem_close(g_peer.shmem);
+	return 0;
+}

tan/templates/vendored/multicore-mailbox/E1M-AEN801/peer/prj.conf

@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: Apache-2.0
+#
+# Peer image stays small -- no IoT stack, no inference runtime,
+# just the mproc framing + a printk console.  Sysbuild will layer
+# its own overlay once the v0.4 dual-image flow lands.
+
+CONFIG_PRINTK=y
+CONFIG_ALP_SDK=y
+
+# Shared global-SRAM0 mailbox+shmem region is read/written by BOTH M55 cores
+# (this peer and ../src, its HP-side sibling), each with its own D-cache ->
+# the region must be coherent. Disable the D-cache (the AEN SRAM-coherency
+# precedent: the NPU apps do the same) so cross-core reads see the other
+# core's writes without explicit clean/invalidate. (A cache-on variant would
+# sys_cache_data_flush_range on the writer + invd_range on the reader, on
+# silicon where the D-cache can be enabled at all.)
+CONFIG_DCACHE=n

tan/templates/vendored/multicore-mailbox/E1M-AEN801/peer/testcase.yaml

@@ -0,0 +1,23 @@
+# SPDX-License-Identifier: Apache-2.0
+#
+# HE-side peer slice of mproc-mailbox.  `board.yaml` (one level up)
+# wires this directory as the `m55_he` core's `app:`, so Twister
+# discovers this as its own app root, separate from the HP-side
+# `../testcase.yaml` (rooted at the example's `./src`).  No
+# native_sim overlay exists under this directory -- the `alp_shmem0`
+# DT alias is provided only by `../boards/native_sim_native_64.overlay`,
+# which applies to the HP-side (`../src`) build, not this one -- so
+# this testcase carries AEN-board coverage only.
+
+sample:
+  name: mproc-mailbox-peer
+  description: |
+    M55-HE side of the mproc-mailbox roundtrip: waits on the same
+    mbox + shmem region as ../src (m55_hp), echoes the payload back.
+
+tests:
+  alp_sdk.examples.mproc_mailbox.peer.aen:
+    platform_allow:
+      - alp_e1m_aen801_m55_he/ae822fa0e5597ls0/rtss_he
+    extra_args: EXTRA_CONF_FILE=generated/alp.conf CONFIG_ALP_SDK_MPROC=y
+    build_only: true   # roundtrip verification is HiL (dual-ATOC bench flash), not a CI run.

tan/templates/vendored/multicore-mailbox/E1M-AEN801/prj.conf

@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: Apache-2.0
+#
+# Otherwise empty by design.  The build's effective Kconfig is
+# build/generated/alp.conf -- emitted from this app's board.yaml
+# by `tan build` and layered over this file via
+# EXTRA_CONF_FILE (see README.md: `tan generate --target zephyr-conf`). board.yaml's `ipc:` block (kind:
+# raw_shmem, endpoints: [m55_hp, m55_he]) now makes kconfig.py's
+# `_emit_cross_core_shmem_cache` emit CONFIG_DCACHE=n into the generated
+# conf too (PR #1080 follow-up -- this used to be the Ethos-U inference
+# branch's job alone).  The line below is kept anyway: it predates the
+# generator support, is bench-proven, and removing a hand-written line in
+# the same change that adds the generator path would make it impossible
+# to tell which one was doing the work if something regressed.  Dropping
+# it is a clean follow-up once the generator path is trusted.
+
+# Shared global-SRAM0 mailbox is read/written by BOTH M55 cores, each with its
+# own D-cache -> the region must be coherent. Disable the D-cache (the AEN
+# SRAM-coherency precedent: the NPU apps do the same) so cross-core reads see
+# the other core's writes without explicit clean/invalidate. (A cache-on variant
+# would sys_cache_data_flush_range on the writer + invd_range on the reader, on
+# silicon where the D-cache can be enabled at all.)
+CONFIG_DCACHE=n