Real-Time Linux on MediaTek Genio: PREEMPT-RT, Jailhouse, and RITY
MediaTek Genio supports three distinct real-time approaches, each with different trade-offs in latency, isolation, complexity, and compatibility with the rest of the Linux software stack. PREEMPT-RT modifies the Linux kernel, Jailhouse partitions the CPU at the hypervisor level, and RITY uses dedicated co-processor hardware that never touches Linux. Choosing the right approach depends on your latency requirement and how much you need to isolate the real-time workload.
Key Insights
- PREEMPT-RT is the lowest-effort option — patches the Linux kernel, no hardware partitioning, 50-150 µs worst-case latency
- Jailhouse runs bare-metal or Zephyr on partitioned Cortex-A cores — deterministic, under 10 µs, requires memory partitioning work
- RITY is MediaTek’s M-core RTOS — completely separate hardware, 1-10 µs, communicates with Linux via IPC
- Genio 350 has no dedicated RTOS co-processor — PREEMPT-RT or Jailhouse are the only real-time options
- Running Jailhouse reduces CPUs available to Linux — plan core allocation before committing to this approach
What are the three approaches?
PREEMPT-RT
PREEMPT-RT is a set of patches to the Linux kernel that convert most kernel code paths from non-preemptible to preemptible. It does not change the hardware configuration — the same Linux kernel runs on all cores, and the same BSP drivers apply.
The effect is a significant reduction in worst-case interrupt latency. Standard Linux can experience latency spikes of several milliseconds under load. A PREEMPT-RT kernel on Genio typically holds worst-case latency below 100-150 µs.
To enable in Yocto (see the Genio Yocto build guide for the full build setup):
# In your local.conf or kas yml:
PREFERRED_PROVIDER_virtual/kernel = "linux-mediatek-5.15"
KERNEL_FEATURES:append = " features/preempt-rt/preempt-rt.scc"
Verify at runtime:
uname -a
# Should show "PREEMPT RT" in the version string
# Measure worst-case latency with cyclictest
cyclictest -m -p 99 -t 4 -n -i 200 -D 60
Jailhouse
Jailhouse is a Type-1 partitioning hypervisor. It runs at EL2 (ARM hypervisor mode) and partitions the system into isolated cells. The root cell runs Linux with access to all memory and peripherals not assigned to other cells. Inmate cells can run bare metal, Zephyr, or another RTOS.
For the inmate cell, the real-time execution is truly deterministic — it is not subject to Linux scheduling, cache pollution from Linux, or SMI latency. The trade-off is complexity: you must write cell configuration files that partition CPUs, memory, and peripherals, and you must implement IPC between the Linux root cell and the inmate.
On Genio, Jailhouse runs on the Cortex-A cores. MediaTek’s Genio 700 and 720 EVKs have been validated with Jailhouse (with upstream patches from MediaTek’s FAE team). The recommended IPC mechanism is IVSHMEM (shared memory with interrupt signaling).
A typical 4+2 core split for Genio 720 (octa-core):
Root cell (Linux): Cortex-A78 (cores 0-3) + Cortex-A55 (cores 4-5)
Inmate cell (Zephyr/bare-metal): Cortex-A55 (cores 6-7)
The inmate cell’s CPUs are physically isolated from Linux — they do not share the scheduler or interrupt affinity.
RITY
RITY is MediaTek’s proprietary RTOS that runs on the dedicated Cortex-M co-processor cores present on Genio 510/520/700/720/1200. These M-cores are separate silicon from the A-cores running Linux. They have their own interrupt controller, their own memory, and their own clock domain.
From Linux’s perspective, RITY is a remote processor (remoteproc) that the kernel boots by loading firmware via the RPMsg/IVSHMEM IPC bus.
RITY is appropriate for:
- Hard real-time control loops that must be completely isolated from Linux scheduling
- Sensor polling at fixed intervals (IMU, encoder, etc.)
- Motor control or actuator output with deterministic timing
- Watchdog behavior that must survive a Linux crash
RITY communicates with Linux through the rpmsg framework — Linux sends and receives messages to/from RITY via the IPC channel.
How do the approaches compare?
| PREEMPT-RT | Jailhouse | RITY | |
|---|---|---|---|
| Hardware change | None | Hypervisor partitioning of A-cores | Separate M-core hardware |
| Worst-case latency | 50-150 µs | < 10 µs (inmate) | 1-10 µs |
| Isolation from Linux | None — same kernel | Full — separate cell | Full — separate hardware |
| Complexity | Low | High | Medium |
| Linux driver compatibility | Full | Root cell only | Full (Linux side unchanged) |
| Available on Genio 350 | Yes | Yes (limited) | No |
| Requires NDA BSP | No | No (public patches) | Yes (RITY firmware) |
| IPC to Linux | Not needed | IVSHMEM | RPMsg |
Which approach should you choose?
PREEMPT-RT — when your latency requirement is above 100 µs and you want a single Linux image with no architectural changes. Good for industrial data acquisition, sensor fusion, and soft real-time control.
Jailhouse — when you need deterministic control under 10 µs on an A-core compute budget, and you are willing to invest in hypervisor configuration and IPC design. Best for robotics, multi-axis control, or safety-critical functions that benefit from A-core compute power.
RITY — when you need fully isolated hardware determinism for simple, fast control loops, and your real-time logic fits on an M-core (limited compute, no MMU). Best for sensor polling, watchdog, and I/O control that must survive a Linux crash.
Building a product on MediaTek Genio that needs real-time capabilities? ProventusNova has hands-on experience with PREEMPT-RT, Jailhouse, and RITY on Genio — including the Genio 720 Jailhouse integration. See our MediaTek Genio support page or get in touch.
MediaTek Genio Expert Support
Building on MediaTek Genio?
BSP bring-up, GStreamer pipelines, NeuroPilot integration, we've shipped it. Get unblocked fast. One call to scope it, fixed bid to deliver it.
Frequently Asked Questions
Does MediaTek Genio support PREEMPT-RT?
Yes. The Genio IoT Yocto BSP kernel can be configured with PREEMPT_RT patches. MediaTek includes PREEMPT_RT support in the BSP kernel tree. This reduces worst-case interrupt latency from the general-purpose Linux range (hundreds of microseconds) to the PREEMPT_RT range (typically under 100 microseconds on ARM Cortex-A cores). PREEMPT_RT is the lowest-effort real-time option and the right choice when hard real-time is not required.
What is RITY and which Genio platforms include it?
RITY is MediaTek's name for the RTOS that runs on the dedicated real-time co-processor cores present on some Genio SoCs. RITY is not Linux — it is a small RTOS that handles time-critical tasks (motor control, sensor polling, deterministic I/O) independently of the Linux side. RITY is present on Genio 510, 520, 700, 720, and 1200. Genio 350 does not have a dedicated RTOS co-processor. RITY runs on the Cortex-M cores, while Linux runs on the Cortex-A cores.
What is Jailhouse and how does it differ from RITY?
Jailhouse is an open-source Type-1 hypervisor that partitions the Cortex-A cores into isolated cells. One cell runs Linux (the root cell), and other cells can run a bare-metal RTOS, Zephyr, or bare-metal firmware. Unlike RITY (which uses dedicated M-core hardware), Jailhouse partitions the same A-cores that Linux uses. This gives you much more compute in the real-time cell but requires careful memory and peripheral partitioning.
What latency can I expect from each real-time approach on Genio?
PREEMPT-RT: worst-case interrupt latency of 50-150 microseconds depending on load and kernel version. Jailhouse bare-metal inmate: deterministic, typically under 10 microseconds — not subject to Linux scheduling at all. RITY on Cortex-M: deterministic, 1-10 microseconds range for simple ISR-driven tasks — completely isolated from the Linux side. The right choice depends on your latency requirement, not just which is 'most real-time.'
Does running PREEMPT-RT or Jailhouse affect AI inference performance on the NPU?
PREEMPT-RT has minimal effect on NPU inference — the NPU runs as a hardware accelerator independently of CPU scheduling. Jailhouse partitions CPU cores and memory, so if you assign cores to a real-time cell, those cores are not available to Linux for NPU driver threads. Plan your core allocation carefully: keep at least 2 Cortex-A cores in the Linux root cell for NPU driver and inference scheduling.
Written by
Andrés CamposCo-Founder & CTO · ProventusNova
8 years deep in embedded systems, from underwater ROVs to edge AI. Andrés leads every technical delivery personally.
Connect on LinkedIn