Rust for HAMPU systems

One workspace for every component in your SoC.

Consortium pairs a Linux-capable A-core with Cortex-M real-time cores, the heterogeneous and asymmetric multiprocessing (HAMPU) pattern behind SoCs such as i.MX 9 and STM32MP2, with typed IPC, explicit cross-core contracts, and code generated from one manifest.

cargo install csti
mcu/src/main.rs · CM33
#[consortium_runtime_mcu::main]
async fn main(_s: Spawner) -> Result<(), ConsortiumError> {
    let (_p, c) = init(Config::default());
    let mut sensor = Transceiver::connect(c.SENSOR).await?;

    for seq in 0u32.. {
        let temperature_mdc = read_sensor();
        let reading = SensorReading { temperature_mdc, seq };
        sensor.send(&reading).await?;
        // IPCC1 rings; the CA35 wakes and decodes it
        Timer::after_secs(1).await;
    }
    Ok(())
}

Explicit contracts across the core boundary

The Linux host sits at the center: talking down to the real-time controller, up into the secure world, left to the kiosk interface, and right into the broader ecosystem.

TrustZone
OP-TEE
Secure World via Teaclave
unverified
#[tee_command]
Host
Linux
Tokio, UIO, aarch64 / armv7
Interface
Kiosk HMI
Cog / PocketJS
unverified
Ecosystem
Integration Layers
ONNX & ROS & Zenoh
in development
Transceiver + doorbell
Controller
Bare-metal
Embassy and defmt
FDCAN / UART
Wired
Remote Controller
External components like ESC

Badged parts are not production-ready: TEE code is generated to compile against Teaclave but is not yet formally tested, the HMI is untested, and the integration layers are in development.

One manifest drives the whole build.

csti reads Consortium.toml, validates it against the embedded chip database, and generates a consortium.gen.rs for every endpoint, including memory map, doorbell vectors, time driver, and a synchronous init() that hands back typed Peripherals and Channels.

Each channel then runs its own async Transceiver::connect handshake, so bring-up is one line per side with no Primary/Secondary branch.

  • csti new my-soc --chip stm32mp257fScaffold a manifest plus app, firmware and shared crates; -i asks instead.
  • csti checkValidate the manifest and cargo check every endpoint.
  • csti build --linux <DIR>Build app, firmware, TA and device tree into a deployable tree.
  • csti fetchPrefetch dependencies so build can run --offline.
[profile]
chip        = "stm32mp257fak3"
devkit      = "stm32mp257f-dk"
shared      = "../shared"
deploy_root = "/opt/consortium"

[endpoints]
linux = "./app"
optee = "./ta"
cm33  = "./mcu"

[[ipc.channel]]
name          = "sensor"
doorbell      = "ipcc1"
pattern       = "memory"
primary       = "linux"
secondary     = "cm33"
party.linux   = { chan = 0, type = "Command" }
party.cm33    = { chan = 1, type = "SensorReading" }
config.memory = { base = 0x00064000, length = 0x4000 }
mtu           = 128

Pick the wire, keep the channel

Every transport implements the same SendTransport, RecvTransport and Connect traits, so Channel and Transceiver code is unchanged whichever one carries it.

Shared memory

IPCC · MU · HSEM · GPIO doorbells
consortium-ipc-transport-memory

A descriptor plus 64-byte-aligned slots in a shared window. Splits into Tx/Rx halves; config.ack adds acknowledged sends on their own doorbell lines.

Generated from pattern = "memory"

UART

byte arrival
consortium-ipc-transport-uart

COBS(chan | payload | CRC32) framing. Tokio serial on Linux, an IRQ-buffered BufferedUart on firmware.

Crate API

FDCAN

frame arrival
consortium-ipc-transport-fdcan

One header byte segments messages across classic or FD frames. Each direction binds its own CAN identifier.

Crate API

Message types derive IpcSafe, which rejects pointers, references, usize and anything else that means something different on the other core.

One log stream, both cores

consortium-dbg carries defmt frames off the M-core through a shared-memory ring; the generated app decodes them into tracing events beside the host’s own logs.

melt-pot-stm32mp25-app · CA35
2026-10-29T13:18:17.601238Z TRACE consortium_dbg::host: HostRing::from_raw_parts(base = 0xffffb3646000, len = 0x2000)
2026-10-29T13:18:17.601463Z TRACE consortium_dbg::host: HostRing::from_raw_parts: descriptor capacity = 0x2000, read_ptr = 0x10, write_ptr = 0x552
2026-10-29T13:18:17.601790Z  INFO consortium_dbg::host: defmt table parsed: encoding = Rzcobs, has_timestamp = true
2026-10-29T13:18:17.602114Z  INFO melt_pot_stm32mp25_app: melt-pot: CA35 application started; IPC bring-up complete
2026-10-29T13:18:18.603871Z  INFO consortium::dbg: sensor seq=0 temp_mdc=20000 core="cm33"
2026-10-29T13:18:19.603902Z  INFO consortium::dbg: sensor seq=1 temp_mdc=20500 core="cm33"

A crate for every layer

From wire protocol to human interface, each concern is its own crate.

Build
csti

The CLI: check, fetch and build every endpoint from one manifest.

Docs →
Logging
consortium-log

One defmt/tracing facade so generated and cross-platform code share a call site.

Docs →
TEEuntested
consortium-tee

Write OP-TEE commands as plain Rust functions; #[tee_command] generates code that compiles against Teaclave.

Docs →

Supported chips & targets

STM32MP25 and i.MX 93 are officially supported and tested in hardware. STM32MP23 and STM32MP21 reuse the STM32MP25 support without formal verification, i.MX 95 is still being brought up, and i.MX 94 is planned.

STM32MP25
Verified
A35 + M33 + M0+ · NPU/GPU
firmware
Cortex-M33
doorbell
IPCC
Advanced industrial HMI, AI and multimedia.
i.MX 93
Verified
A55 + M33 · NPU/GPU
firmware
Cortex-M33
doorbell
MU
Low-power intelligent edge devices.
STM32MP23
Derived from MP25
A35 + M33
firmware
Cortex-M33
doorbell
IPCC
Mid-range HMI and lightweight edge AI.
STM32MP21
In progress
A35 + M33
firmware
Cortex-M33
doorbell
IPCC
Cost-sensitive industrial control and gateways.
i.MX 95
In progress
A55 + M7 + M33 · NPU/GPU/VPU
firmware
Cortex-M7
doorbell
MU
High-performance edge AI and multi-camera vision.
i.MX 94
Planned
A55 + M7 + M33 · NPU
firmware
2 Cortex-M7 & 1 Cortex-M33
doorbell
MU
Industrial and automotive networking with TSN.

Architecture targets

aarch64-unknown-linux-gnu and thumbv8m.main-none-eabihf run on real hardware. The other listed targets compile the code, but have not run on a board yet. Dashed targets are not built yet; support is coming.

A-core Linux
aarch64-unknown-linux-gnuhardwarearmv7-unknown-linux-gnueabihf
M-core bare-metal
thumbv8m.main-none-eabihfhardwarethumbv7em-none-eabihfthumbv6m-none-eabiwill support
RISC-V
riscv32imc-unknown-none-elfwill supportriscv32imac-unknown-none-elfwill supportriscv32imafc-unknown-none-elfwill support