📚 课程目录第2章 i.MX异构多核平台解析

2. i.MX异构多核平台解析

在 i.MX 系列应用处理器（如 i.MX 8M、i.MX 8M Plus、i.MX 8QuadMax、i.MX 7Dual 等）中，Cortex-A 与 Cortex-M 并不是简单的“大小核”关系，而是两个在硬件层面就相对独立的执行域。理解异构通信工程的第一步，不是急着写 RPMsg 或 OpenAMP 代码，而是先弄清楚：谁拥有哪块内存、谁控制哪个外设、谁先启动、谁给谁让路。只有把资源归属和启动时序看清楚，后续的共享内存划分、中断路由和消息通道设计才不会踩坑。

一、硬件资源划分：两个域，两套视角

以典型的 i.MX 8M Plus 为例，芯片内部同时集成 4 个 Cortex-A53 核心和 1 个 Cortex-M7 核心。A 核运行 Linux 或 Android，负责应用、网络、显示、文件系统等复杂任务；M 核运行裸机或 RTOS（如 FreeRTOS、Zephyr），负责实时控制、电机闭环、传感器采集、低延迟响应等任务。两者共享同一颗芯片的 DDR 控制器、总线矩阵和部分外设控制器，但访问权限和初始化责任被明确划分。

关键点在于：M 核通常拥有自己独立的 TCM（Tightly Coupled Memory）和部分专属外设，例如 i.MX 8M Plus 的 M7 拥有 128 KB ITCM + 128 KB DTCM，以及独立的 GPIO、I2C、UART、SPI、CAN-FD、eCSPI 等外设实例。这些外设的寄存器地址在 M 核视角下是直接可访问的，不需要经过 A 核授权。而 A 核则通过系统总线访问 DDR、PCIe、USB、以太网等高速外设。两者之间通过共享内存和 Messaging Unit（MU）进行通信。

注意：不同 i.MX 型号的 M 核外设归属差异很大。例如 i.MX 7Dual 的 Cortex-M4 与 A7 共享更多外设，而 i.MX 8M Plus 的 M7 外设独立性更强。设计前必须查阅对应芯片的 Reference Manual 中“Peripheral Memory Map”和“Resource Domain Controller（RDC）”章节。

二、内存映射：从地址空间看归属

在 i.MX 8M Plus 中，M 核的地址空间与 A 核并不完全一致。M7 的 TCM 通常映射在 0x0000_0000 到 0x0003_FFFF 附近（ITCM 和 DTCM 各 128 KB），而 DDR 在 M 核视角下通常从 0x8000_0000 开始。A 核 Linux 则通过 MMU 将物理地址映射为虚拟地址，用户空间无法直接访问 M 核 TCM。

共享内存区域一般由 A 核在设备树中预留，例如在 reserved-memory 节点中声明一块 1 MB 的 rsc_table 和 vdev0vring 区域。M 核固件启动后，会在这块共享内存中建立 RPMsg vring 和资源表。A 核 Linux 通过 remoteproc 框架加载 M 核固件，并解析资源表，从而知道 M 核使用了哪些内存和外设。

/* 示例：i.MX 8M Plus 设备树中为 M7 预留共享内存 */
reserved-memory {
    #address-cells = <2>;
    #size-cells = <2>;
    ranges;

    m7_reserved: m7@0x80000000 {
        reg = <0x0 0x80000000 0x0 0x100000>;
        no-map;
    };

    vdev0vring0: vdev0vring0@0x80100000 {
        reg = <0x0 0x80100000 0x0 0x8000>;
        no-map;
    };

    vdev0vring1: vdev0vring1@0x80108000 {
        reg = <0x0 0x80108000 0x0 0x8000>;
        no-map;
    };

    vdev0buffer: vdev0buffer@0x80110000 {
        reg = <0x0 0x80110000 0x0 0x10000>;
        no-map;
    };
};

这段设备树片段明确告诉 Linux：0x8000_0000 开始的 1 MB 归 M7 使用，0x8010_0000 和 0x8010_8000 分别放两个 vring，0x8011_0000 放共享缓冲区。Linux 不会把这些区域纳入自己的内存管理，从而避免冲突。

三、外设归属：RDC 与时钟控制

i.MX 8M Plus 引入了 Resource Domain Controller（RDC），用于将外设和内存区域分配给不同的域（Domain）。每个外设可以配置为属于 A 核域、M 核域或共享域。例如，如果要把某个 I2C 控制器分配给 M 核，就需要在 RDC 中设置该外设的域归属，并确保 A 核的 Linux 驱动不加载该外设。

时钟和电源管理同样需要关注。M 核通常有自己的时钟门控和电源域，A 核可以通过 CCM（Clock Controller Module）和 PMU 控制 M 核的复位与时钟。在启动 M 核之前，A 核需要先使能 M 核的时钟、释放复位、配置 RDC，然后才能加载固件。

四、启动流程：A 核先跑，M 核后启

i.MX 异构平台的典型启动顺序是：Boot ROM → A 核启动 → U-Boot → Linux 内核 → 用户空间 → remoteproc 加载 M 核固件。M 核并不是与 A 核同时启动的，而是由 A 核在 Linux 启动完成后，通过 remoteproc 框架“唤醒”并加载固件。

具体来说，Linux 内核中的 imx_rproc 驱动会负责：使能 M 核时钟、释放复位、将固件拷贝到 M 核 TCM 或 DDR 指定地址、设置 M 核入口地址、启动 M 核。M 核启动后，会初始化自己的外设和 RTOS 任务，然后在共享内存中建立 RPMsg 通道，等待 A 核发来的消息。

五、从资源划分到通信设计

理解了上述资源划分和启动流程后，设计异构通信时就有了明确的边界。例如，如果 M 核需要控制一个电机，那么电机对应的 PWM、编码器接口、GPIO 必须通过 RDC 分配给 M 核域，A 核 Linux 不能同时加载这些外设的驱动。共享内存的大小和地址必须在设备树中提前预留，M 核固件的链接脚本也要与之匹配。

在实际工程中，常见的错误包括：A 核 Linux 仍然占用 M 核需要的外设，导致 M 核访问时总线报错；共享内存地址在设备树和 M 核固件中不一致，导致 RPMsg 初始化失败；M 核时钟未使能就尝试加载固件，导致 remoteproc 超时。这些问题都可以通过先理清资源归属和启动顺序来避免。

建议在项目初期就建立一张资源分配表，明确列出每个外设、每块内存的归属域、地址范围、初始化责任方和通信方式。这张表是后续驱动开发、设备树编写和固件链接脚本的共同依据。

总结来说，i.MX 异构多核平台的核心在于“分而治之”：A 核负责通用计算和系统管理，M 核负责实时控制，两者通过共享内存和 MU 进行消息传递。资源划分决定了谁能访问什么，内存映射决定了数据放在哪里，外设归属决定了谁控制硬件，启动流程决定了谁先谁后。把这四件事搞清楚，异构通信工程就有了坚实的基础。