1. 课程导入
欢迎进入《TI Sitara AM64x BSP 开发》课程。AM64x 是德州仪器 Sitara 系列中面向工业边缘计算与实时控制的重要处理器，它把多核异构计算、工业实时网络、功能安全与长期供货能力整合在同一颗芯片上。对于嵌入式工程师而言，理解 AM64x 的架构不是“背景知识”，而是后续所有 BSP 移植、驱动适配、启动优化与系统调试工作的地基。本章将建立一张全局地图：先看清芯片内部由哪些计算域和子系统构成，再明确 BSP 开发到底要交付什么，最后给出贯穿全课程的学习路径与整体框架。
一、AM64x 处理器架构：多核异构与工业外设的融合
AM64x 的核心特征可以概括为“双域多核 + 工业实时网络 + 安全与可靠性”。它内部主要包含三类处理单元：最多两个 64 位 Arm Cortex-A53 应用核，用于运行 Linux 等富操作系统；最多四个 32 位 Arm Cortex-R5F 实时核，通常成对分组，用于运行 RTOS 或裸机实时任务；以及一个 Cortex-M4F 微控制器，负责电源、时钟、复位等设备管理。A53 与 R5F 之间通过片上互联和 Mailbox、RPMSG 等机制通信，形成“应用域 + 实时域”的典型异构架构。
在存储与数据通路上，AM64x 集成了 DDR 控制器、片上 SRAM、多级缓存以及丰富的外设接口。工业场景中特别关键的是它支持的工业通信子系统：包括两个千兆以太网口、TSN（时间敏感网络）交换能力、EtherCAT、PROFINET、EtherNet/IP 等工业协议的硬件加速与软件支持。此外还有 MCAN（CAN-FD）、MCSPI、I2C、UART、ADC、PWM、GPIO 等常规外设，用于连接传感器、执行器和现场总线设备。
从 BSP 开发视角看，AM64x 的架构决定了软件必须分层看待：A53 侧关注 Linux 内核、设备树、根文件系统与用户态服务；R5F 侧关注 RTOS 启动、核间通信、实时任务调度与外设独占；M4F 侧关注电源管理固件与低层初始化。三者共享同一套时钟、复位和引脚资源，因此资源划分与所有权定义是 BSP 设计中最容易出错、也最需要提前规划的部分。
二、BSP 开发目标：从“能启动”到“可交付”
BSP（Board Support Package）不是单一软件，而是一组让硬件“可用、可控、可维护”的软件集合。对于 AM64x，BSP 开发目标可以分为四个层次。第一层是启动与引导：确保 ROM Code、SPL、U-Boot、ATF、OP-TEE 到 Linux 内核的启动链稳定可靠，并能通过 SD 卡、eMMC、OSPI 或网络等多种介质引导。第二层是硬件抽象：通过设备树描述引脚复用、时钟树、电源域、外设地址与中断，让内核正确识别并驱动板级硬件。第三层是驱动与中间件：包括以太网、CAN、SPI、I2C、ADC、显示、存储等外设驱动，以及工业协议栈和核间通信框架。第四层是系统集成与交付：构建可复现的 Yocto 镜像、提供调试手段、编写移植文档并保证长期可维护。
BSP 交付物清单：
- 引导固件：tiboot3.bin、tispl.bin、u-boot.img、ATF、OP-TEE
- 内核与设备树：Image、am64x-*.dtb、内核配置与补丁
- 根文件系统：Yocto 构建的 core-image 或自定义镜像
- 驱动与固件：外设驱动、R5F 固件、M4F DM 固件
- 工具与脚本：烧录脚本、调试脚本、构建脚本
- 文档：移植指南、引脚分配表、测试报告
三、学习路径：从架构认知到工程落地
本课程的学习路径遵循“先通链路，再攻细节”的原则。建议按以下顺序推进：
- 架构与启动链：理解 AM64x 多核布局、启动流程与镜像组成，能独立完成最小系统启动。
- 开发环境与 SDK：搭建交叉编译环境，熟悉 TI SDK、Yocto 与 CCS 的基本使用。
- 设备树与引脚复用：掌握 DTS 语法、Pinmux 配置、时钟与电源域描述方法。
- 外设驱动移植：逐个适配以太网、CAN、SPI、I2C、ADC 等工业外设。
- 核间通信与实时域：掌握 Mailbox、RPMSG、R5F 固件加载与实时任务划分。
- 工业协议与系统优化：集成 TSN、EtherCAT 等协议，进行启动优化与稳定性测试。
- 调试与排障：使用 JTAG、串口日志、ftrace、perf 等工具定位问题。
四、整体框架与常见误区
从工程视角看，AM64x BSP 开发可以归纳为“一条启动链、两套运行域、三类资源表、四层软件栈”。一条启动链指从 ROM 到 Linux 的完整引导路径；两套运行域指 A53 的 Linux 域与 R5F 的实时域；三类资源表指引脚复用表、时钟树表和电源域表；四层软件栈指引导层、内核层、驱动层和应用层。理解这个框架后，遇到问题时就能快速判断问题出在哪一层，而不是盲目修改配置。
| 开发阶段 | 核心任务 | 关键产物 | 常见误区 |
|---|---|---|---|
| 启动链 | ROM → SPL → U-Boot → Kernel | 可启动镜像 | 忽略 ATF/OP-TEE 加载顺序 |
| 设备树 | Pinmux、时钟、电源、外设节点 | DTS/DTB | 引脚冲突未提前规划 |
| 驱动移植 | 外设驱动适配与验证 | 驱动模块/内核配置 | 只改驱动不改设备树 |
| 核间通信 | Mailbox、RPMSG、共享内存 | 通信通道与固件 | 资源所有权未划分 |
| 系统集成 | Yocto 构建、烧录、测试 | 完整镜像与文档 | 构建环境不可复现 |
新手常见误区：把 BSP 开发等同于“改内核驱动”。实际上，AM64x 的多数问题出现在设备树、引脚复用、时钟配置和核间资源划分上。建议在动手写驱动前，先用串口日志和 JTAG 确认启动链与硬件描述是否正确。
下面是一段典型的 AM64x 启动日志片段，用于建立对启动链的直观认识：
U-Boot SPL 2023.04 (Jan 10 2024 - 10:22:31 +0800)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.6--v09.00.06')
Trying to boot from MMC1
Loading Environment from MMC... OK
NOTICE: BL31: v2.8(release):v2.8.0
NOTICE: BL31: Built : 10:20:15, Jan 10 2024
U-Boot 2023.04 (Jan 10 2024 - 10:22:31 +0800)
SoC: AM64x SR1.0
Model: Texas Instruments AM642 EVM
DRAM: 2 GiB
Core: 120 devices, 28 uclasses, devicetree: separate
MMC: mmc@fa10000: 0, mmc@fa00000: 1
Loading Device Tree to 000000009fff0000, end 000000009ffff3a5 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000
[ 0.000000] Linux version 6.1.46-gdb2b6c1d4e0a
[ 0.000000] Machine model: Texas Instruments AM642 EVM