1. 课程导入与工业场景认知
在开始调试一块 Sitara 板卡之前，先要建立三个基本认知：TI Sitara 到底覆盖哪些芯片、工业 Linux 在这些芯片上通常跑什么业务、以及从"能启动"到"能交付"之间还隔着哪些工程环节。这三件事决定了后续所有调试动作的方向——同样是串口没输出，在 AM335x 的 U-Boot 阶段和在 AM62x 的 SPL 阶段，排查路径完全不同。
一、Sitara 产品线的分层结构
Sitara 是 TI 面向工业与嵌入式市场的 ARM 处理器家族，按内核代际和定位大致可分为四层。最底层是 AM335x（Cortex-A8 单核，主频 300MHz～1GHz），它是工业网关、HMI、PLC 通信模块中存量最大的型号，外设以 PRU-ICSS、双千兆以太网、CAN 为特色。往上是 AM437x（Cortex-A9），在 AM335x 基础上增强了显示与工业通信能力。再往上是 AM57x（Cortex-A15 + DSP + PRU），面向需要实时信号处理与运动控制的场景。最新一代是 AM62x / AM64x（Cortex-A53，64 位），AM64x 额外集成两个 Cortex-R5F 实时核，用于 EtherCAT、Profinet 等硬实时协议栈。
选型时最容易踩的坑是"只看主频不看实时性"。例如一个需要 1ms 周期 EtherCAT 从站的设备，用 AM335x 跑 Linux 主站往往抖动超标，而 AM64x 把协议栈放到 R5F 上、Linux 只做管理面，才能稳定达标。因此产品定义阶段就要把"实时任务放在哪个核"确定下来，这会直接影响后续的设备树划分和固件加载方式。
二、工业 Linux 的典型应用场景
Sitara 上的工业 Linux 大致落在四类场景中，它们的调试重点差异明显：
- 工业网关/协议转换器：Modbus RTU 转 MQTT、CAN 转以太网。重点是串口/CAN 驱动的稳定性、长时间运行的内存泄漏、以及断网重连逻辑。
- HMI 人机界面：Qt 或 Chromium 界面 + 触摸屏。重点是 GPU/显示子系统、触摸校准、以及界面进程崩溃后的自恢复。
- 边缘控制器/运动控制：需要确定性周期。重点是 PREEMPT_RT 补丁、CPU 隔离（isolcpus）、中断亲和性设置。
- 机器视觉/数据采集：摄像头或高速 ADC 采集。重点是 DMA 带宽、内存预留（CMA）、以及数据不丢包的缓冲设计。
这四类场景对"交付"的定义也不同：网关类看重 7×24 小时稳定性，HMI 类看重启动时间和界面流畅度，运动控制类看重周期抖动，视觉类看重吞吐。调试指标必须从场景反推，而不是统一套用"能跑就行"。
三、产品交付全流程框架
从一块 EVM 到一台可出货的设备，完整链路可以概括为：硬件确认 → Boot 链路打通 → 内核与根文件系统定制 → 外设驱动适配 → 应用部署 → 稳定性验证 → 量产烧录与固件升级。其中每一步都有明确的"通过判据"，例如 Boot 链路的判据是"断电重启 100 次全部进入内核"，而不是"看到一次登录提示符"。
下面这张图把这条链路与各阶段的核心对象、关键判据对应起来，便于在后续章节中定位自己处在哪一环：
四、调试与交付的核心挑战
上图中四类挑战并非并列关系，而是有明确的"暴露顺序"。硬件问题最早暴露，通常在板子回板后的第一次上电就能发现；Boot 问题紧随其后，表现为串口无输出或输出乱码；驱动问题在系统起来后才显现，比如网口能识别但 ping 不通；实时性问题往往要到压力测试阶段才暴露，且最难复现。
以"串口无输出"为例，实际排查应按信号链顺序推进，而不是盲目换线：先确认 SoC 的 UART 引脚是否被复用为其他功能（查 pinmux 寄存器或设备树 pinctrl 节点），再确认 UART 时钟是否使能（查 CM_PER 相关寄存器），然后确认波特率分频是否正确（115200 对应 48MHz 时钟下的分频值），最后才怀疑线序和终端软件。这个顺序的本质是"从 SoC 内部往外查"，因为内部配置错误的概率远高于外部接线错误。