Platforms
RME targets the whole computing spectrum, but the project is explicit about what is measured and delivered versus what is work in progress. This page keeps that distinction visible.
Microcontrollers
Microcontroller support requires a Memory Protection Unit (MPU). On MCUs, RME is used through RVM: RVM is the user-level library and project generator, and it can also host other bare-metal applications or RTOSes alongside RME.
| Requirement | Value |
|---|---|
| Absolute minimum | 64 KB ROM / 20 KB RAM (STM32L071CB, Cortex-M0+) |
| Practical starting point | 128 KB ROM / 64 KB RAM |
| Protection | MPU required |
| Cores | Single-core only; multi-core MCUs are out of scope |
| Toolchains | GCC, Keil uVision (ARMCC/ARMCLANG) |
The 64 KB / 20 KB figure is the smallest proof-of-concept that finishes the benchmark, including a virtualized RMP benchmark. Chips such as the STM32G0B1CBT6 are comfortably above the floor; the recommendation is to start with 128 KB / 64 KB for a useful system.
Application processors
Application processors require an MMU. The recommended resource is about 32 MB ROM / 32 MB RAM for a meaningful system. This side of the project is work in progress: the ports exist in various stages, but the microprocessor benchmark table is still TBD.
| Family | Protection | Example | Status |
|---|---|---|---|
| ARMv7-A | MMU + GIC | XC7Z020 (Cortex-A9) | Port present; single-core; LGPL v3+ |
| RV64 | Sv39 | QEMU-VIRT (RV64GC) | Port present; needs sibling init image |
| x86-64 | MMU | Server profile | Work in progress; no bootable image |
| C66x | MMU | TMS320C6678 | Immature |
The ARMv7-A port and some of its headers are marked LGPL v3+, unlike the rest of the repository, which is Unlicense/public domain. If you distribute A7A binaries, review that license.
Architecture summary
| Family | Directory | Protection | Example chips | Toolchains |
|---|---|---|---|---|
| ARMv6-M | A6M | MPU | STM32L071CB, STM32G071RB | GCC, Keil |
| ARMv7-M | A7M | MPU | STM32F405RG, F429ZI, F767IG, H743ZI | GCC, Keil |
| ARMv7-A | A7A | MMU | XC7Z020 | GCC |
| RV32 | RV32P | PMP | CH32V307VC | GCC |
| RV64 | RV64V | Sv39 | QEMU-VIRT | GCC |
| x86-64 | X64 | MMU | Server profile | GCC |
| C66x | Immature/C66X | MMU | TMS320C6678 | CCS |
Build projects
The repository ships a small number of project trees rather than one project per chip. Microcontroller projects are generated through RVM, because that is where the toolchain, board and guest configuration knowledge lives.
| Project | Target | Notes |
|---|---|---|
VSCODE-GCC-X64 | x86-64 | Scaffolding; the image is not currently bootable |
GCC-RV64V | QEMU-VIRT RV64 | Needs a sibling M7M03_Anomalocaris init image |
MFGCC-XC7Z020 | Zynq-7020 | ARMv7-A, single-core |
Immature/CCS-TMS320C6678 | C66x DSP | Immature |
Immature/ECLIPSE-* | MCU / x64 / Zynq | Experimental Eclipse projects |
Immature/HIGHTEC-TC275TP | AURIX TC275 | Experimental demos |
What this means for adoption
- MCU today: use RVM to generate a project for an MPU-equipped Cortex-M or RV32 part; 64 KB / 20 KB is the floor, 128 KB / 64 KB is the recommendation.
- Application processors: treat the ports as research and bring-up work, not a production distribution. The RMC container layer is a concept in progress.
- No multi-core MCUs: a single RME instance per core is the model; the project does not pretend otherwise.
The performance page separates measured MCU numbers from the microprocessor table, which is entirely TBD.