3. Jacinto软件总体架构
Jacinto 系列（如 TDA4VM、DRA829）在智能驾驶域控制器中承担感知接入、融合计算、规控执行与整车通信的枢纽角色。它的软件总体架构不是单一操作系统，而是“异构多核 + 多操作系统 + 统一通信”的组合体。理解这一架构，关键要抓住四条主线：Processor SDK 提供的 Linux/RTOS 双环境、AUTOSAR CP 与 AP 的分工、跨核通信框架，以及从上电到应用加载的启动与分区布局。
一、Processor SDK：Linux 与 RTOS 的双环境
TI 的 Processor SDK 是 Jacinto 软件栈的底座，它同时提供 Linux 与 RTOS 两套开发环境。Linux 侧运行在 Cortex-A72 主核上，负责高吞吐、非实时或软实时的任务，例如摄像头数据管理、AI 推理调度、以太网服务、文件系统与 OTA 升级。RTOS 侧通常运行在 Cortex-R5F 的 MCU 域以及部分主域 R5F 上，承担硬实时控制、安全监控、CAN 收发与执行器闭环。
两套环境共享同一套底层驱动抽象：Linux 使用标准内核驱动模型，RTOS 使用 TI 的 PDK 驱动（CSL、UDMA、IPC 等）。这意味着同一个外设（如 MCAN、CPSW、CSI2）在两侧都有对应驱动，但配置方式不同。实际项目中，A72 上跑 Linux，MCU 域 R5F 上跑 AUTOSAR CP 或 TI RTOS，主域 R5F 上跑视觉预处理或安全岛逻辑，C7x/MMA 上跑深度学习算子。这种“按实时性分层”的部署，是 Jacinto 软件架构的第一原则。
二、AUTOSAR CP 与 AP 的支持方式
Jacinto 对 AUTOSAR 的支持是“CP 为主、AP 为辅、按核部署”。AUTOSAR CP（Classic Platform）面向硬实时、固定周期、小数据量的控制场景，典型运行在 MCU 域 R5F 上，通过 MCAL 驱动 MCAN、ADC、DIO、SPI 等，配合 RTE 与 SWC 完成整车控制。TI 提供 MCAL 包与 EB tresos 配置工具链，使 CP 工程可以生成符合 AUTOSAR 4.x 的 BSW 代码。
AUTOSAR AP（Adaptive Platform）面向高算力、动态调度、面向服务的场景，通常运行在 A72 的 Linux 或 QNX 之上，提供 ara::com、ara::exec、ara::per 等 API，用于 SOA 服务通信、进程生命周期管理与持久化。在域控制器中，AP 常承载感知融合、地图服务、OTA 客户端等模块。需要注意的是，CP 与 AP 并非二选一，而是通过 SOME/IP 或 IPC 桥接：CP 侧负责确定性控制，AP 侧负责服务化计算，两者在同一 SoC 内协同。
三、多核通信框架：从 IPC 到共享内存
Jacinto 的多核通信核心是 TI 的 IPC（Inter-Processor Communication）框架，它建立在共享内存与 Mailbox 中断之上。每个核（A72、R5F、C7x、MCU R5F）在共享内存中拥有自己的 VRING 缓冲区，通过 Mailbox 触发对方中断，实现消息通知。上层可选用 RPMessage（轻量消息）或 RPMsg（带端点与通道语义），再往上可对接 OpenVX、TIOVX 或自定义数据流。
实际部署中，A72 Linux 与 R5F RTOS 之间的通信通常走 RPMsg，用于下发控制指令、上传状态；R5F 与 C7x 之间的图像/张量数据则走共享内存 + 零拷贝，避免大块数据反复搬运。通信设计要关注三点：缓冲区大小与对齐、Cache 一致性（A72 侧需处理 cache 维护）、以及中断优先级对实时性的影响。若通信延迟抖动大，优先检查 VRING 深度与 Mailbox 中断是否被 Linux 中断线程化延迟。
四、启动流程与系统分区
Jacinto 的启动是“多级引导 + 多核释放”的过程。上电后，ROM Code 根据 Boot Mode 引脚选择启动介质（eMMC、OSPI、UART、以太网等），从介质读取 Tiboot3（或 SPL）到 MCU SRAM 执行。Tiboot3 完成基础时钟与 DDR 初始化后，加载 U-Boot 与 ARM Trusted Firmware（ATF）。ATF 负责建立安全环境并释放 A72 主核，U-Boot 随后加载 Linux 内核与设备树。
Linux 启动后，通过 RemoteProc 框架加载 R5F、C7x 的固件（.elf 或 .xer5f），并借助 Mailbox 通知各从核开始运行。此时 MCU 域的 R5F 可能先运行 AUTOSAR CP 的 BSW，主域 R5F 运行视觉预处理，C7x 运行推理算子。整个启动顺序必须与核间依赖匹配：如果 C7x 固件依赖 R5F 提供的共享内存初始化，就必须保证 R5F 先就绪。
系统分区方面，典型方案是在 eMMC 上划分 boot 分区（存放 Tiboot3、U-Boot、内核、设备树）、rootfs 分区（Linux 根文件系统）、app 分区（AP 应用与配置）、data 分区（日志、标定、持久化数据），以及一段保留的共享内存区（如 0xA0000000 起始的 16MB）。共享内存区的地址与大小必须在 Linux 设备树、RTOS 链接脚本、IPC 配置三处保持一致，否则会出现 VRING 读写错位。分区表通常在 U-Boot 环境变量或 GPT 中定义，OTA 升级时只切换 app 与 rootfs 分区，boot 分区保持稳定。
五、架构落地的关键约束
把上述四部分串起来，实际项目要守住三条约束。第一，实时性分层：硬实时任务必须落在 R5F 的 RTOS/CP 侧，不要试图用 Linux 的实时补丁替代 MCU 域。第二，通信一致性：共享内存地址、Cache 属性、VRING 深度在 Linux 与 RTOS 两侧必须逐项对齐，任何一侧改动都要同步更新。第三，启动依赖：核间启动顺序、固件加载时机、分区挂载顺序要与应用初始化顺序一致，避免“核已启动但依赖资源未就绪”的竞态。
理解 Jacinto 软件总体架构，本质上是在一张“核—操作系统—通信—存储”的映射图上做设计决策。Processor SDK 提供双环境底座，AUTOSAR CP/AP 提供标准化应用框架，IPC 框架打通核间数据流，启动与分区则决定系统能否稳定、可升级地运行。这四者共同构成域控制器软件架构的骨架。