同一颗 SoC 里的两个 CPU 如何对话？Mailbox、Mutex 与共享 RAM

快速回答

• 在异构 SoC（heterogeneous SoC）中，运行 Linux 的 Cortex-A 与运行 RTOS 的 Cortex-M 位于同一颗芯片上，共享同一物理地址空间——它们之间通过恰好 3 种硬件机制通信：Mailbox、Mutex 和共享 RAM（Shared RAM），每种机制负责一件截然不同的事。
• Mailbox 只负责“报信”：发送方把 1 个字（word）写入 DATA 寄存器，置位 STATUS 位，硬件随即向另一个 CPU 发出门铃中断（doorbell IRQ）将其唤醒。真正的数据不经过 Mailbox——它存放在共享 RAM 中。这正是 virtio 里熟悉的“kick”机制。
• Mutex 是硬件实现的 test-and-set 锁，用于裁决谁可以使用共享资源：读回 0 表示获得锁（lock granted），读回 1 表示对方正在持有。
• 共享 RAM 才是真正存放数据的地方：它保存载荷（payload）和 vrings（virtqueue 的环形缓冲区）。两个 CPU 都经互连（Interconnect）以 load/store 直接访问它，因为它们看到的是同一个物理地址空间。
• 一条从 Linux 发往 Cortex-M 的命令要走 7 步：申请锁 → 把载荷写入共享 RAM → 释放锁 → 写 Mailbox → 门铃中断 → Cortex-M 读取载荷 → 处理并经 MMIO 驱动外设（CAN、GPIO）。

什么是异构 SoC 中的核间通信（IPC）？

核间通信（Inter-Processor Communication，IPC）是让同一颗芯片上的多个处理器核心协同工作、又不互相破坏数据的一整套硬件与软件机制。在异构 SoC 中，各核心的架构与操作系统截然不同——例如高性能的 Cortex-A 运行 Linux，负责界面、网络与应用；实时性的 Cortex-M 运行 RTOS，负责外设控制、传感器以及需要即时响应的任务。由于两侧无法可靠地共用普通的软件同步机制（例如跨两种不同架构使用自旋锁），SoC 必须在硬件层面提供同步与通知机制。

为什么同在一颗芯片上的两个 CPU 仍需要专门的通信机制？

核心问题是：两个 CPU 要怎样对话，又不“互相踩脚”？它们共用内存和外设，如果双方在没有裁决的情况下同时写入同一块数据区域，数据就会损坏。反过来，如果一方写完数据而另一方无从得知该去读，数据同样没有用处。

从原文的示意图看，SoC 自上而下分为 4 层：Processors（两个 CPU）、Mailbox/Mutex、Interconnect（互连）和 Memory/I/O。除两个 CPU 外，参与通信的恰好只有 3 样东西：负责通知的 Mailbox、负责裁决的 Mutex、负责存放数据的共享 RAM。“谁能碰数据”“数据放在哪里”“如何知道有新数据”这三个问题，被拆成三种独立的机制。

Mailbox 是如何工作的？

Mailbox 是尽可能小的通知通道。发送方把 1 个字写入 DATA 寄存器并置位 STATUS 位，硬件立即向另一个 CPU 发出门铃 IRQ。接收方被唤醒，读走 DATA——就这么多。

需要记住的关键点是：Mailbox 只能传递 1 个小字（例如一个缓冲区索引），而不是大量数据。它只负责说“有货到了，来取吧”——真正的“货”存放在共享 RAM 中。熟悉 virtio 的人会立刻认出来：这正是 guest 用来通知 host “virtqueue 刚放入了新缓冲区”的那个“kick”。

还有一个细节：Mailbox 通常是单向的。如果 Cortex-M 需要回复 Cortex-A，反方向就需要另一个 Mailbox。

硬件 Mutex 与软件锁有何不同？

Mutex 解决的是与 Mailbox 完全不同的问题：某一时刻谁有权使用共享资源。每个 CPU 都以 test-and-set 的方式发出加锁请求：如果读回的位为 0，则 lock granted——该 CPU 可以进入；如果为 1，则对方正在持有，必须等待。

这个 Mutex 做在硬件里是有原因的。Cortex-A 与 Cortex-M 架构不同，运行的又是两套不同的操作系统（Linux 与 RTOS），普通的软件自旋锁无法在两者之间可靠共用。把 test-and-set 下放到硬件，使抢锁过程成为原子操作，并对双方公平，与每一侧运行什么软件无关。

共享 RAM 与 Interconnect 各起什么作用？

示意图左右两边缘的两条竖线（标注“bus access: load, store”）是 CPU 访问内存与外设的正常通路。它们从两个 CPU 出发，穿过 Mailbox/Mutex 层，直达 Interconnect——并不经过 Mailbox 或 Mutex。由于两个 CPU 共用同一物理地址空间，它们看到的是同一块共享 RAM。

Interconnect 是中央总线，把两个 CPU 的全部访问分发到 4 个目的地：

• 共享 RAM：load/store 访问，存放真正的载荷以及 vrings——virtio virtqueue 的环形缓冲区。
• UART：经 MMIO 传输串行字节。
• CAN：经 MMIO 传输 CAN 帧。
• GPIO：经 MMIO 读写引脚的逻辑电平。

MMIO（Memory-Mapped I/O，内存映射 I/O）指的是 CPU 像读写 RAM 一样，通过读写外设的地址来控制外设——无需单独的 I/O 指令。

机制	它负责的事	经过它的数据	要点
Mailbox	通知“有货到了”，并用门铃 IRQ 唤醒另一个 CPU	DATA 寄存器中的 1 个小字（如缓冲区索引）	通常单向；正是 virtio 的“kick”机制
Mutex	用硬件 test-and-set 裁决共享资源使用权	1 个状态位：0 = 获得锁，1 = 被持有	需要硬件实现，因为两种架构/操作系统的核心无法共用自旋锁
共享 RAM	存放供双方读写的真实数据	载荷（payload）与 vrings（virtqueue）	两个 CPU 因共享物理地址空间而都能看到它

一条 Linux 命令到达 Cortex-M 的顺序是怎样的？

把三种机制组合起来，Cortex-A（Linux）向 Cortex-M（RTOS）发送一条命令，恰好经历 7 步：

1. Cortex-A 向 Mutex 申请锁，并获得 granted。
2. Cortex-A 经 Interconnect 把载荷写入共享 RAM。
3. Cortex-A 释放锁。
4. Cortex-A 把 1 个小字（如缓冲区索引）写入 Mailbox 的 DATA 寄存器，并置位 STATUS 位。
5. Mailbox 向 Cortex-M 发出门铃 IRQ。
6. Cortex-M 被唤醒，读取 DATA，然后从共享 RAM 读取载荷。
7. 如需回复，Cortex-M 反向执行同样的流程——由于 Mailbox 通常单向，反方向使用另一个 Mailbox。

收到命令后，Cortex-M 经 MMIO 驱动外设来执行请求：例如向 CAN 总线发送一帧，或改变某个 GPIO 引脚的逻辑电平。整体来看，这正是 RPMsg、OpenAMP 等核间通信框架所依托的硬件基础：共享 RAM 扮演 virtqueue 的角色，Mailbox 扮演通知“kick”的角色，而 Mutex 在双方同时访问时保护共享数据结构。

常见问题

Mailbox 能传输大量数据吗？ 不能。Mailbox 只能传递 1 个小字，例如一个缓冲区索引。大量数据始终存放在共享 RAM 中；Mailbox 只负责通知“共享 RAM 里有数据了，来取吧”。

为什么不在 Cortex-A 与 Cortex-M 之间使用软件自旋锁？ 因为两个核心架构不同、运行两套不同的操作系统（Linux 与 RTOS），普通软件自旋锁无法在两者之间可靠共用。硬件 Mutex 以原子方式执行 test-and-set，与每一侧的软件无关。

什么是 MMIO？ MMIO（内存映射 I/O）指的是 CPU 像读写 RAM 一样，通过读写映射给外设的内存地址来控制外设。在这颗 SoC 中，UART、CAN 和 GPIO 都经 Interconnect 以 MMIO 方式访问。

什么是门铃 IRQ（doorbell IRQ）？ 它是 Mailbox 发出的硬件中断，用于在新通知到达时立即“敲门”唤醒另一个 CPU，而不必让该 CPU 不停轮询检查是否有数据——接收方因此可以休眠，只在真正有工作时才醒来。

两个 CPU 需要运行相同的操作系统才能用这种方式通信吗？ 不需要。Mailbox、Mutex 与共享 RAM 整套机制都位于硬件层，因此一侧运行 Linux、另一侧运行 RTOS 也能通信——这正是异构 SoC 上最常见的情况。

---

来源：Devlinux 于 2026 年 11 月 8 日在 Facebook “Cộng đồng lập trình Nhúng & Vi Mạch（devlinux.vn）”群组发表的文章《两个 CPU 如何互相交谈？》。文中的示意图为原帖配图。