Combining RTOS and Linux in Heterogeneous Multi-Core Systems: When and How to Use AMP Architectures

Introduction: The Rise of Heterogeneous Multi-Core Systems

Modern embedded systems increasingly rely on heterogeneous System-on-Chip (SoC) architectures that include multiple cores with different capabilities. For example, a high-performance ARM Cortex-A core running Linux may be paired with one or more Cortex-M cores running a Real-Time Operating System (RTOS).

This architectural approach enables developers to split system responsibilities: real-time control tasks on the RTOS and complex user applications on Linux. The asymmetric multiprocessing (AMP) model allows these cores to operate independently while still coordinating through shared memory or messaging mechanisms.

In this article, we explore how and when to use AMP architectures in embedded designs, the benefits and challenges of combining RTOS and Linux, and practical implementation techniques for building robust, predictable systems.

What Is AMP and How Does It Differ from SMP?

AMP (Asymmetric Multiprocessing)

• Each core runs its own OS instance
• Typically involves different ISAs (e.g., ARM Cortex-A + Cortex-M)
• Minimal shared memory; explicit messaging for communication
• Ideal for separating real-time and non-real-time tasks

SMP (Symmetric Multiprocessing)

• All cores run the same OS instance (e.g., multi-core Linux)
• Shared memory, kernel-managed scheduling
• Requires identical cores with cache coherency

Long-tail keyword example: "What is the difference between AMP and SMP in embedded systems?"

Answer: SMP uses identical cores with a shared OS, while AMP allows independent cores to run different OSes like Linux and RTOS. AMP is preferred when tasks have distinct real-time and non-real-time requirements.

Benefits of RTOS + Linux AMP Systems

• Real-time predictability: RTOS ensures deterministic behavior for control loops
• Rich OS capabilities: Linux provides networking, filesystems, UI frameworks
• Power efficiency: Small RTOS can enter low-power modes independently
• Fault isolation: A failure in Linux doesn’t crash the real-time core
• Vendor support: Many SoCs (NXP i.MX, TI Sitara, STMP1) natively support AMP

Common Use Cases for AMP Architectures

• Industrial automation controllers with real-time motor control and web-based HMI
• Automotive ECUs combining AUTOSAR Classic on MCU with Linux infotainment
• Drones and robotics separating control loops and perception stack
• Medical devices with real-time patient monitoring and secure data logging

Selecting the Right SoC for AMP

Look for:

• Heterogeneous cores (e.g., Cortex-A + Cortex-M)
• Shared memory or mailbox peripherals
• Debug support for both cores (JTAG, SWD)
• Software SDKs with AMP examples (e.g., NXP MCUXpresso, TI SDK)

Long-tail keyword example: "Which SoCs support Linux and RTOS in an AMP configuration?"

Answer: SoCs like NXP i.MX 8M, TI AM64x, STM32MP1, and Xilinx Zynq-7000 support AMP with combinations of Linux (Cortex-A) and RTOS (Cortex-M) on the same chip. These platforms provide shared memory, IPC, and vendor-supported SDKs for development.

Communication Between Linux and RTOS

Several IPC (inter-process communication) mechanisms are used:

• RPMsg (RemoteProc + VirtIO): Kernel framework for Linux-to-RTOS messaging
• Shared memory with ring buffers: Lightweight and low-latency
• Mailbox peripherals: Hardware-accelerated signaling
• UART, SPI, I2C bridges: For external AMP setups

OpenAMP is a standard middleware layer that implements RPMsg across Linux and RTOS domains.

Memory and Peripheral Partitioning

• Use MMU on Cortex-A to isolate Linux memory
• Use MPU on Cortex-M for stack and heap protection
• Carefully partition peripheral access to avoid race conditions
• Design interrupt routing to prioritize real-time responsiveness

Synchronization and Latency Considerations

• Use bounded queues or mailboxes to prevent RTOS blocking
• Ensure Linux doesn’t starve RTOS of shared resources
• Avoid polling loops in Linux that could affect real-time cores
• Profile inter-core latency with logic analyzers or timestamped logs

Long-tail keyword example: "How do RTOS and Linux cores communicate in AMP systems?"

Answer: They communicate via IPC mechanisms like RPMsg, shared memory buffers, or hardware mailboxes. RPMsg provides a standardized messaging layer for efficient Linux-to-RTOS communication in AMP environments.

Debugging and Development Tools

• Dual-core debug probes (e.g., Lauterbach, Segger J-Link Pro)
• OpenAMP log tracing and RPMsg sniffers
• GDB + OpenOCD for Linux
• IAR or MCUXpresso IDEs for RTOS core
• Trace32 or DAPLink for synchronized traces

Best Practices for AMP System Design

• Start from vendor reference designs and BSPs
• Use well-defined IPC protocols and queues
• Schedule Linux services with awareness of RTOS priorities
• Test boot synchronization and core bring-up sequences
• Include watchdogs and fallback modes for recovery

Summary: Making the Most of Heterogeneous SoCs

AMP architectures unlock powerful flexibility for embedded designs, especially when combining real-time requirements with rich OS capabilities. With the right SoC, communication strategy, and toolchain, you can build systems that are both responsive and feature-rich.

Why Promwad?

Promwad has deep experience with multi-core SoCs and AMP system integration. We help:

• Architect RTOS + Linux solutions for industrial and automotive
• Configure IPC channels with OpenAMP and RPMsg
• Partition memory and peripherals safely
• Optimize performance and boot-up synchronization
• Develop and validate full-stack embedded systems

Let’s make your heterogeneous SoC project a success.

Contact us