The “Mailbox” Inside a Chip: A Tiny Thing That Decides Inter-Core Communication Efficiency
Have you ever wondered how two CPU cores inside a chip actually “talk” to each other?
They can’t shout, and they don’t have WeChat.
The answer is simple — a mailbox. Chip designers call it Mailbox.
Back in the Day, It Was “Passing Notes”
When chips first entered the multi-core era, the crudest way for two cores to communicate was: share a block of memory and poll each other.
Core 0 writes some data at address 0x8000, and Core 1 checks ten thousand times per second — “Anything new? Anything new? Anything new?”
This was the earliest inter-core communication: Polling.
As for efficiency, imagine two people passing notes, but the recipient opens the mailbox 10,000 times a second. Most of the time the mailbox is empty, and all the CPU time is wasted reading empty addresses.
You say, why not just add an interrupt notification?
Exactly — that’s how Mailbox was born.
What Does a Mailbox Actually Look Like?
A mailbox inside a chip is essentially the same thing as the metal box at your doorstep.
It has:
- One or more data registers — where you can drop data (like dropping a letter in)
- A status register — tells the other side “there’s mail in the box”
- A doorbell signal (Doorbell) — ding-dong, new message arrived
Core 0 writes data, rings the doorbell. Core 1 receives the interrupt and comes to pick up the mail.
It’s that simple.
A complete communication takes only three register operations + one interrupt, with latency typically between a few hundred nanoseconds to a few microseconds.
Why Not Just Use Shared Memory?
You might think: everyone shares the same memory, just write a flag bit, right?
It’s possible, but there are several pitfalls:
- Cache Coherency — Core 0 writes to memory, but the data is still sitting in L1 cache; Core 1 might read stale data. You’d have to add a cache flush or use uncached memory, and a single flush costs dozens of cycles.
- No hardware queuing — If two cores write to the same address simultaneously, who goes first? You’d need spinlocks, atomic operations, and with each additional core, the complexity rises exponentially.
- No standard interrupt mechanism — How does Core 1 know Core 0 wrote data? Either polling or building your own interrupt logic.
Mailbox handles all of this in hardware: hardware-guaranteed atomicity, interrupt notification, and register access that naturally crosses cache domains.
What’s It Actually Used For?
Here are a few real-world examples.
AMP systems (Asymmetric Multi-Processing) are the most common scenario. In one SoC, a Cortex-A core runs Linux and a Cortex-M core runs bare metal or an RTOS.
The M core controls a motor, and the A core needs to send an instruction: “Set the fan speed to 3000 RPM.”
The A core writes “3000” into the mailbox, the M core receives the interrupt, reads the data, adjusts the speed, and writes “OK” back into the mailbox.
No shared memory touched, no synchronization locks needed.
This is how RPMsg (Remote Processor Messaging) works at the low level. TI’s OMAP and NXP’s i.MX series all use it.
Power management is also a major use case. When the CPU wants to sleep, it sends a message to the PMU (Power Management Unit) via the mailbox: “I’m going to sleep, drop voltage to 0.8V.” After the PMU finishes, it replies: “Done, go to sleep.”
This is ten thousand times more elegant than handshaking via custom GPIO levels with timers for timeout handling.
Then there’s the Safety Island. The main core sends critical safety data to an independent monitoring core. The monitoring core performs a CRC check, and only if everything is confirmed OK does it allow the operation to proceed. If this process goes wrong, it’s a vehicle-safety-level accident.
Mailbox’s role here is: a guaranteed insurance channel in hardware.
It Has Its Temper, Too
Mailbox isn’t a silver bullet.
The most annoying issue is limited depth. Most mailboxes only have 1–4 slots. When they’re full, they get blocked. If you write to it, you either get a busy return or the data gets dropped outright.
Higher-level protocols (like RPMsg) set up a ring buffer (vring) in shared memory, and the mailbox is only responsible for signaling “there’s data.” That way, even large amounts of data aren’t a problem — the mailbox is just a doorbell.
Another issue is lack of standardization. ARM introduced the MHU (Message Handling Unit) specification, but the register layout of mailboxes varies wildly across SoCs. The Linux kernel has a mailbox subsystem, but the low-level driver still has to be written by each vendor.
A Little Tail Note
Mailbox is a “small part” of the chip — literally just a few registers — but it determines whether inter-core communication is efficient or a bottleneck. It’s like the mailbox at your doorstep: a tiny metal box that handles the flow of information. The next time you send a text message, think about this — there’s a chip somewhere, with a tiny mailbox, making sure your data gets where it needs to go.
Comments