Embedded RTOS - aifoundry-org/erbium GitHub Wiki

This page attempts to capture thoughts around various real-time operating systems (RTOS) and applicability (or not) to Erbium in a low-memory/low-core embedded environment.

Please see Embedded Inference Frameworks for a discussion of higher-level inference frameworks. Ideally, these frameworks would be able to run on any of the below RTOS.

Other readings:

Erbium Constraints

As of this writing (Nov 2025), Erbium is expected to have roughly the following proposed architecture:

  • Full ET Neighborhood of 8 Minion cores running at 1GHz
  • RISC-V ISA - specifically RV64IMFC + Zicsr + Zifenci
  • 16MB of Magnetoresistive RAM (MRAM)
  • PLIC interrupt controller
  • No MMU

As of this writing (Nov 2025), the direction is that SMP configurations are likely not to be supported in Erbium. Therefore, addressing all 8 minions would require something like OpenAMP or yet-to-be-determined frameworks.

Workalike

As of this writing (Nov 2025), a simulator for Erbium has begun development in et-platform as part of sw-sysemu. There are also plans to create an FPGA-able target in the future. In order to bootstrap system-level conversations while those hardware and platform efforts are underway, we need an interim substitute.

Therefore, a close available workalike to the above Erbium constraints is VexiiRiscv. This allows a RISC-V 64-bit CPU with ISA matching that of the Erbium specifications above. VexiiRiscv is the next-generation successor of VexRiscv - notably, it introduces RISC-V 64-bit ISA support which aligns with the expected Erbium ISA. It is understood that the PLIC and other peripherals will likely be different on a real Erbium board.

On a Digilent Arty A7-100t with an Artix-7 XC7A100TCSG324-1 that has ~100k logic cells, it is possible to create a 4-core RISCV64 CPU at 100MHz. Of note, most of these RTOSes discussed here already support these Arty A7 boards with a Vexriscv core and are beginning to land support for Vexiiriscv as well.

Therefore, we will focus on the Arty A7 with Vexiiriscv cores as a target for any discussions below. As the Erbium simulator and FPGA targets become available that can replace any Vexiiriscv efforts, it is expected to revisit these workalikes.

Zephyr

The Zephyr OS is based on a small-footprint kernel designed for use on resource-constrained and embedded systems: from simple embedded environmental sensors and LED wearables to sophisticated embedded controllers, smart watches, and IoT wireless applications.

As of this writing (Nov 2025), there is a draft WIP PR to add in Vexiiriscv support to Zephyr:

MRAM support

Zephyr has support for a key-value store called Zephyr Memory Storage (ZMS) suitable for MRAM:

Zephyr Memory Storage is a new key-value storage system that is designed to work with all types of non-volatile storage technologies. It supports classical on-chip NOR flash as well as new technologies like RRAM and MRAM that do not require a separate erase operation at all, that is, data on these types of devices can be overwritten directly at any time.

Ocre - Containers on Zephyr

Ocre leverages WebAssembly (Wasm) to extend OCI-like software containerization to resource-constrained edge devices that have historically run firmware or embedded Linux. The Ocre runtime abstracts hardware complexity and enables code written in choice of programming language to be broken out into containerized applications that are developed and managed independently and have a footprint up to 2000X lighter than traditional container binaries.

Other links

Apache NuttX

NuttX is a free and open-source (FOSS) real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOS’s (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).

For existing applications that are expecting a POSIX/ANSI interface, NuttX offers a viable path. Notably, Erbium will almost certainly not have an MMU - so, the flat build model would likely apply. From Linux Processes versus NuttX Tasks:

NuttX can be built in several different ways:

Kernel Build - The kernel build, selected with CONFIG_BUILD_KERNEL, uses the MCU’s Memory Management Unit (MMU) to implement processes very similar to Linux processes. There is no interesting discussion here; NuttX behaves very much like Linux.

Flat Build - Most resource-limited MCUs have no MMU and the code is built as a blob that runs in an unprotected, flat address space out of on-chip FLASH memory. This build mode is selected with CONFIG_BUILD_FLAT and is, by far, the most common way that people build NuttX. This is the interesting case to which this Wiki page is directed.

Protected Build - Another build option is the protected build. This is essentially the same as the flat build, but uses the MCU’s Memory Protection Unit (MPU) to separate unproctect user address ranges from protected system address ranges. The comments of this Wiki page also apply in this case.

Python on Apache NuttX

Due to the underlying POSIX compatibility making it easy to port existing applications, the full CPython interpreter has been ported and is available on select NuttX environments. As of this writing (Nov 2025), it is available on RISC-V QEMU (emulated) and on Espressif’s ESP32-S3. For more, please see:

Other links

FreeRTOS

FreeRTOS is a market-leading embedded system RTOS supporting 40+ processor architectures with a small memory footprint, fast execution times, and cutting-edge RTOS features and libraries including Symmetric Multiprocessing (SMP), a thread-safe TCP stack with IPv6 support, and seamless integration with cloud services. It’s open-source and actively supported and maintained.

Of note, ET-SoC-1 service processor runs FreeRTOS on a minion core in Service Processor BL2 mode.

Other Links:

9front

9front is a fork of Plan 9. It was started to remedy a perceived lack of devoted development resources inside Bell Labs, and has accumulated various fixes and improvements.

Notably, there have been efforts to bring 9front to RISC-V 64-bit - see links below. As of this writing (December 2025), while there is a RISC-V compiler and toolchain available, RISC-V support is not yet integrated into an upstream 9front release.

Talks and slides/papers:

RISC-V port update posts on 9fans:

RISC-V Compiler Sources:

Other Links: