How Do Two CPUs in One SoC Talk to Each Other? Mailbox, Mutex and Shared RAM

Quick answers

• On heterogeneous SoCs, a Cortex-A running Linux and a Cortex-M running an RTOS sit on the same chip and share one physical address space — and they talk to each other through exactly 3 hardware mechanisms: a Mailbox, a Mutex and Shared RAM, each doing a very different job.
• The Mailbox only says "something has arrived": the sender writes 1 word into the DATA register, sets the STATUS bit, and the hardware fires a doorbell IRQ to wake the other CPU. The real data does not travel through the Mailbox — it lives in Shared RAM. This is exactly the "kick" mechanism known from virtio.
• The Mutex is a hardware test-and-set lock that arbitrates who may touch shared resources: reading back 0 means the lock is granted; reading back 1 means the other side is holding it.
• Shared RAM is where the real data lives: it holds the payload and the vrings (the ring buffers of a virtqueue). Both CPUs access it directly with loads and stores through the Interconnect, because they see the same physical address space.
• One command from Linux down to the Cortex-M goes through 7 steps: acquire the lock → write the payload into Shared RAM → release the lock → write to the Mailbox → doorbell IRQ → the Cortex-M reads the payload → it processes the request and drives peripherals (CAN, GPIO) via MMIO.

What is inter-processor communication (IPC) in a heterogeneous SoC?

Inter-processor communication (IPC) is the set of hardware and software mechanisms that let multiple processor cores on the same chip work together without corrupting each other's data. In a heterogeneous SoC, the cores differ sharply in architecture and operating system — for example, a high-performance Cortex-A running Linux handles the interface, networking and applications, while a real-time Cortex-M running an RTOS handles peripheral control, sensors and tasks that need instant response. Because the two sides cannot reliably share ordinary software synchronization mechanisms (such as a spinlock across two different architectures), the SoC must provide synchronization and notification mechanisms in hardware.

Why do two CPUs on one chip still need dedicated communication mechanisms?

The core question is: how do the two CPUs talk without "stepping on each other"? They share memory and peripherals, so if both wrote to the same data region with no arbitration, the data would be corrupted. Conversely, if one side finished writing data but the other side had no way to know it should read, the data would be useless.

In the diagram from the original article, the SoC is divided into 4 layers, top to bottom: Processors (the two CPUs), Mailbox/Mutex, Interconnect, and Memory/I/O. Apart from the two CPUs, exactly 3 things take part in the communication: the Mailbox for notification, the Mutex for arbitration, and Shared RAM for holding data. The three problems — "who may touch the data", "where the data lives" and "how do I know new data exists" — are separated into three distinct mechanisms.

How does the Mailbox work?

The Mailbox is the smallest notification channel possible. The sender writes 1 word into the DATA register and sets the STATUS bit. The hardware immediately fires a doorbell IRQ at the other CPU. The receiver wakes up, reads DATA — done. That is all.

The key point to remember: the Mailbox only carries one small word (for example, a buffer index), not bulk data. It only says "something has arrived, come and get it" — the "goods" themselves live in Shared RAM. Anyone who has worked with virtio will recognize this instantly: it is the "kick" the guest uses to tell the host that the virtqueue has just gained a buffer.

One more detail: a Mailbox is usually unidirectional. If the Cortex-M needs to reply to the Cortex-A, the return direction needs a different Mailbox.

How is a hardware Mutex different from a software lock?

The Mutex solves a completely different problem from the Mailbox: who is allowed to touch a shared resource at a given moment. Each CPU issues a lock request in test-and-set fashion: if the bit reads back as 0, the lock is granted — that CPU may proceed; if it reads back as 1, the other side is holding it and must wait.

There is a good reason this Mutex is built in hardware. The Cortex-A and Cortex-M cores have different architectures and run two different operating systems (Linux and an RTOS), so an ordinary software spinlock cannot be shared reliably between them. Moving the test-and-set into hardware makes lock contention atomic and fair for both sides, no matter what software each side runs.

What roles do Shared RAM and the Interconnect play?

The two vertical lines at the left and right edges of the diagram (labeled "bus access: load, store") are the CPUs' normal paths for accessing memory and peripherals. They run from the two CPUs straight down through the Mailbox/Mutex layer to the Interconnect — they do not pass through the Mailbox or the Mutex. Because both CPUs share one physical address space, both see the same Shared RAM.

The Interconnect is the central bus, distributing every access from both CPUs to 4 destinations:

• Shared RAM: load/store access; holds the real payload and the vrings — the ring buffers of a virtio virtqueue.
• UART: via MMIO, serial bytes.
• CAN: via MMIO, CAN frames.
• GPIO: via MMIO, pin logic levels.

MMIO (Memory-Mapped I/O) means the CPU controls a peripheral by reading and writing its addresses, exactly as if they were RAM — no separate I/O instructions are needed.

Mechanism	What it does	What passes through it	Key point
Mailbox	Notifies "something has arrived" and wakes the other CPU with a doorbell IRQ	1 small word (e.g. a buffer index) in the DATA register	Usually unidirectional; it is virtio's "kick" mechanism
Mutex	Arbitrates access to shared resources with a hardware test-and-set	1 status bit: 0 = lock granted, 1 = held	Hardware is needed because two cores with different architectures/OSes cannot share a spinlock
Shared RAM	Holds the real data for both sides to read and write	Payload and vrings (virtqueues)	Both CPUs see it because they share one physical address space

In what order does one Linux command reach the Cortex-M?

Combining all three mechanisms, one command from the Cortex-A (Linux) to the Cortex-M (RTOS) goes through exactly 7 steps:

1. The Cortex-A requests the lock at the Mutex and is granted it.
2. The Cortex-A writes the payload into Shared RAM through the Interconnect.
3. The Cortex-A releases the lock.
4. The Cortex-A writes a small word (for example, a buffer index) into the Mailbox's DATA register and sets the STATUS bit.
5. The Mailbox fires a doorbell IRQ to the Cortex-M.
6. The Cortex-M wakes up, reads DATA, then reads the payload from Shared RAM.
7. If a reply is needed, the Cortex-M does the reverse — and since a Mailbox is usually unidirectional, the return direction uses a different Mailbox.

After receiving the command, the Cortex-M carries out the request by driving peripherals via MMIO: for example, sending a frame onto the CAN bus or changing the logic level of a GPIO pin. Overall, this is precisely the hardware foundation on top of which inter-core communication frameworks such as RPMsg and OpenAMP are built: Shared RAM plays the role of the virtqueues, the Mailbox plays the notification "kick" role, and the Mutex protects the shared data structures while both sides access them.

Frequently asked questions

Can the Mailbox transfer large amounts of data? No. The Mailbox only carries 1 small word, such as a buffer index. Bulk data always lives in Shared RAM; the Mailbox merely announces "there is data in Shared RAM, come and get it".

Why not use a software spinlock between the Cortex-A and the Cortex-M? Because the two cores have different architectures and run two different operating systems (Linux and an RTOS), an ordinary software spinlock cannot be shared reliably. A hardware Mutex performs the test-and-set atomically, independent of each side's software.

What is MMIO? MMIO (Memory-Mapped I/O) is how a CPU controls a peripheral by reading and writing the memory addresses mapped to that peripheral, exactly as if they were RAM. In this SoC, the UART, CAN and GPIO are all accessed via MMIO through the Interconnect.

What is a doorbell IRQ? It is the hardware interrupt the Mailbox raises to "ring the doorbell" and wake the other CPU as soon as a new notification arrives, instead of forcing that CPU to poll constantly to check for data — so the receiving side can sleep and only wake when there is real work.

Do both CPUs need to run the same operating system to communicate this way? No. The entire Mailbox, Mutex and Shared RAM mechanism lives in hardware, so one side running Linux and the other running an RTOS can still communicate — which is in fact the most common situation on heterogeneous SoCs.

---

Source: the article "How do two CPUs talk to each other?" by Devlinux in the Cộng đồng lập trình Nhúng & Vi Mạch (devlinux.vn) group on Facebook, posted on November 8, 2026. The diagram is the original post's figure.