Home

The 'Real' Real-Time Kernel

The Docbook is the place to find what RK0 is on about.

The wiki provides some general information on its functionality (that is found on the Dockbook on details) and information on setting up QEMU and projects of RK0 on dev boards.

---

Important

RK0 is unapologetically real-time embedded.

It acknowledges (or has not forgotten) the processs/thread abstraction, and the software design approach inherited from general purpose systems has 'time' as an afterthought. Conservative policies make Response-Time-Analysis easier. A (comprehensive) set of modular services – some quite distinctive – are tailored for concrete real-time demands.

---

Questions

Q: Why there is no release yet?

A: A release is serious stuff. It will exist when:

• The system is characterised consistently.
• A seamless test harness for eventual contributors can be pushed;
• and a CI can be pushed.

Note

Expect v0.x.x for a long time, or maybe jump-in to collaborate.

Q: I heard not splitting user-space from kernel-space is bad, lame, last-week, toy-kernel, DOS-like. What you would say?*

A: First, to get some real-time literacy (Buttazzo, Bertolotti, Kopetz, etc.).

Second, not every chip RK0 supports has an MPU. Why? Because there is a demand for them. And I ensure they are not coffee-machines - they are controlling loops on plant floors.

Yes, Privilege levels are still allowed with no MPU. But not because it 'makes sense'. It is because tweaking an architectural feature that depends on the existence of an external co-processor is unfeasible.

An MPU can be extremely useful - it is a Memory Firewall. But it is not free: it has impact on determinism and jitter, coarse memory utilisation, not just on raw performance. Knowing when not to use it is also engineering.

Going further: Safety/security standards (IEC 61508, ISO 26262, DO-178, etc.) with regard to RK0:

• As stated, RK0 links altogether into a single image**. It is application-specific, hardware-dependent.

• A firmware update is updating the entire image. There is no 'hosted application'.

A system employing an RT-Executive like RK0: small codebase, static configuration bias, and strictly bounded behaviour, has gains for a certification process: these characteristics make analysis, testing, and traceability simpler. Even formal proofs would be made easier.

---

RK0 on QEMU

⚠️ QEMU 10.0 (tag 22-Apr-2025) is incompatible with the RK0 lm3s6965evb target

• The upstream QEMU 10.0 release (tagged 22 Apr 2025) introduces M-profile/NVIC changes that crash the lm3s6965evb board before your RK0 firmware even starts.

• The fault is entirely in the new QEMU code.

• Until upstream fixes the regression, build or install QEMU 9.2.x.

---

Requirements

• ARM GCC Toolchain (arm-none-eabi-gcc)
• QEMU for ARM (qemu-system-arm)

Target platform

• ARMv7-M (Cortex-M3): lm3s6965evb (TI Stellaris LM3S)

File Structure

├── arch/
│   ├── armv6m/           # ARMv6M port
│   │   └── kernel/
│   │       ├── inc/
│   │       └── src/
|   |
│   └── armv7m/           # ARMv7M port
│        └──kernel/
│           ├── inc/
│           └── src/
├── core/                # System core  
│   ├── inc/
│   └── src/
|
├── app/                 # Application  
│   ├── inc/
│   └── src/
|
├── build/               # Output directory 
└── Makefile             # Build system for QEMU target

Building and Running

To build and run for ARMv7-M (Cortex-M3):

make ARCH=armv7m qemu

To start in debug mode:

make ARCH=armv7m qemu-debug  

Then connect with GDB in a second terminal:

arm-none-eabi-gdb build/rk0_demo.elf -ex "target remote localhost:1234" 
# for a Debian-based OS, use `gdb-multiarch`

Screenshots

Here’s RK0 running on QEMU, showing UART output via GDB semihosting (QEMU 9.2.0 / macOS 15.2):

Debugging from VSCodium: