4. R-Car硬件架构详解

多核异构SoC里，核与核之间怎么“说话”？这是驱动开发绕不开的核心问题。我见过不少团队，硬件设计很牛，但软件通信没做好，性能直接腰斩。说白了，核间通信就三板斧：共享内存传数据、核间中断打招呼、Mailbox做控制。

这一章，我把这几个机制掰开揉碎，结合我踩过的坑，给你讲透。

4.1 共享内存原理

共享内存，就是两个核都能访问的同一块物理内存。听起来简单，但坑不少。

核心原则：共享内存必须位于所有参与核的“统一寻址空间”内。在异构系统里，A核和M核的地址映射可能不同，需要硬件MMU或SMMU做地址翻译。

我在一个项目中，A核往0x8000_0000写数据，M核死活读不到。查了半天，发现M核的地址空间里，0x8000_0000映射的是别的外设。后来改用硬件SMMU做地址重映射才解决。

共享内存设计要点：

  • 一致性：两个核都有Cache，数据写进Cache没刷回内存，另一个核读到的是脏数据。解决方案：使用非Cacheable内存区域，或者用硬件Cache一致性协议（如CCI、ACE）。
  • 原子性：多核同时写同一个变量，会乱套。必须用原子操作或锁机制。
  • 内存屏障：编译器或CPU可能乱序执行指令。写共享变量前，一定要加内存屏障（DSB/DMB指令）。

注意：共享内存不要放函数指针或复杂的数据结构。不同核的指令集可能不同（比如A核是ARMv8，M核是ARMv7-M），函数指针跨核调用会直接崩溃。

4.2 Ring Buffer设计与实现

Ring Buffer（环形缓冲区）是共享内存最常用的数据结构。它像一个循环队列，一个核写，一个核读，不需要锁。

我习惯用这种结构体定义Ring Buffer：

struct ring_buffer {
    uint32_t head;    // 写指针，生产者更新
    uint32_t tail;    // 读指针，消费者更新
    uint32_t size;    // 缓冲区大小，必须是2的幂
    uint8_t *buffer;  // 数据缓冲区
};

为什么size必须是2的幂？因为可以用位运算代替取模，性能更好：

// 取模版本
next_head = (head + 1) % size;

// 位运算版本（size=2^n）
next_head = (head + 1) & (size - 1);

我在一个视频处理项目里，用Ring Buffer传递图像帧。一开始用取模，发现A核写数据时CPU开销太大，改成位运算后，性能提升了15%。

Ring Buffer核心操作：

操作 生产者（写核） 消费者（读核）
写入 检查 (head+1)%size != tail —
读取 — 检查 head != tail
更新指针 先写数据，再更新head 先读数据，再更新tail
内存屏障 写数据后加DMB 读数据前加DMB

避坑指南：我曾经在Ring Buffer里留了一个“空位”不用（即最多存size-1个元素），用来区分“满”和“空”。结果调试时发现，如果生产者和消费者速度不匹配，这个空位会导致数据丢失。后来我改用“计数法”来区分状态，更可靠。

4.3 核间中断（IPI）的使用

共享内存解决了数据传输问题，但怎么通知对方“数据来了”？这就需要核间中断（IPI）。

IPI，说白了就是一个核往另一个核的中断控制器里写一个寄存器，触发对方的中断。在ARM GIC（通用中断控制器）里，IPI是SGI（软件生成中断）。

IPI使用流程：

  1. 发送核：写GIC的SGI寄存器，指定目标核和中断ID。
  2. 接收核：CPU响应中断，进入中断处理函数。
  3. 中断处理函数：读取共享内存，处理数据。

我见过一个新手写的代码，在IPI中断处理函数里做复杂的加解密运算。结果中断处理时间太长，导致其他中断丢失。记住：IPI处理函数一定要快，只做“通知”和“搬运”，复杂逻辑放到任务上下文。

最佳实践：IPI处理函数里，只做两件事：1）从共享内存取数据；2）唤醒一个等待队列或工作队列。其他事情交给内核线程做。

IPI的几种模式：

  • 点对点：一个核发，一个核收。用于主从架构。
  • 广播：一个核发，所有核收。用于全局同步。
  • 自旋：一个核发给自己。用于测试或软中断。

4.4 Mailbox驱动框架

Mailbox是比共享内存更高级的核间通信机制。它像一个“邮箱”，一个核往邮箱里放信，另一个核来取。Mailbox通常由硬件实现，有专用的寄存器和中断。

Linux内核里，Mailbox驱动框架在 drivers/mailbox/ 目录下。核心结构体是 mbox_controller 和 mbox_chan。

struct mbox_controller {
    struct device *dev;
    const struct mbox_chan_ops *ops;
    struct mbox_chan *chans;
    unsigned int num_chans;
    // ...
};

struct mbox_chan_ops {
    int (*send_data)(struct mbox_chan *chan, void *data);
    int (*startup)(struct mbox_chan *chan);
    void (*shutdown)(struct mbox_chan *chan);
    bool (*last_tx_done)(struct mbox_chan *chan);
};

Mailbox vs 共享内存：

特性 共享内存 Mailbox
数据量 大（几KB到几MB） 小（通常几个寄存器）
传输方式 内存读写 寄存器读写
同步机制 需要自己实现 硬件自带握手
适用场景 批量数据 控制命令、小数据

我在一个车载项目中，用Mailbox传递控制命令，用共享内存传递传感器数据。Mailbox负责“发号施令”，共享内存负责“搬砖”。这样分工，既保证了控制命令的实时性，又保证了大数据量的吞吐。

注意：Mailbox的寄存器通常很小（32位或64位）。如果数据超过寄存器宽度，需要分多次发送，或者配合共享内存使用。我见过一个方案：Mailbox只传“指针”和“长度”，数据放在共享内存里。这样既快又灵活。

4.5 知识体系总览

下面这张图，把本章的核心逻辑串起来了。你一看就明白：

多核通信机制知识体系 多核通信机制知识体系 多核异构SoC 共享内存 核间中断(IPI) Mailbox 共享内存要素 • 一致性（Cache Coherency） • 原子性（Atomic Access） • 内存屏障（Memory Barrier） IPI要素 • SGI寄存器配置 • 中断处理函数 • 点对点/广播模式 Mailbox要素 • mbox_controller • mbox_chan_ops • 硬件握手协议 Ring Buffer（环形缓冲区） Ring Buffer是共享内存的典型实现，配合IPI或Mailbox使用

嗯，这张图把关系理清了。共享内存是“路”，Ring Buffer是“车”，IPI是“喇叭”，Mailbox是“红绿灯”。四者配合，才能让多核异构系统跑得又快又稳。

你在实际项目中，可以根据数据量和实时性要求，灵活组合这些机制。比如控制命令走Mailbox+IPI，批量数据走共享内存+Ring Buffer。没有银弹，只有最适合的方案。

← 上一章 📖 返回目录 下一章 →