2. Sitara TSN硬件平台与开发环境搭建

TSN（Time-Sensitive Networking）不是单纯跑在协议栈里的软件特性，它要求从PHY、MAC、交换/队列到时间同步单元形成一条端到端的硬件通路。因此，在写第一行TSN应用代码之前，必须先把硬件平台和开发环境搭起来，并确认底层链路、时钟与外设都处于可控状态。本节以AM64x EVM为核心，围绕DP83869/DP83867 PHY、CPSW/ICSSG外设、Linux SDK与CCS环境，以及板级启动与网络连通性验证展开。

一、硬件平台构成与选型逻辑

AM64x是TI Sitara系列中面向工业通信与电机控制的异构多核SoC，典型配置包含双核Cortex-A53（运行Linux）、双核R5F（可运行RTOS或裸机，承担实时以太网协议栈）、以及若干PRU-ICSSG子系统。TSN能力主要落在两个位置：一是CPSW（Common Platform Switch）三端口千兆以太网交换子系统，支持IEEE 802.1Qbv、Qbu、Qav等TSN特性；二是ICSSG（Industrial Communication Subsystem Gigabit），其PRU内核可编程实现TSN端点、TSN交换或EtherCAT/PROFINET等工业协议。

AM64x EVM上通常提供两路或三路RJ45接口，分别对应CPSW端口与ICSSG端口。PHY选型上，DP83869是千兆以太网PHY，支持RGMII/SGMII以及100BASE-T1等模式，常用于需要介质转换或长距离工业链路的场合；DP83867是标准千兆RGMII PHY，集成度与功耗表现更适合常规RJ45端口。理解这两颗PHY的差异，直接决定了设备树中PHY模式、时钟延迟和接口类型的配置方式。

二、Linux SDK与CCS开发环境配置

AM64x的软件开发分为两条主线。Linux侧使用TI Processor SDK（基于Arago/Yocto），安装后通过 setup.sh 选择AM64x平台，得到交叉编译工具链、内核源码、设备树源码和根文件系统。典型流程是：先编译内核与设备树，再用 create-sdcard.sh 制作SD卡启动盘，最后通过串口登录系统。R5F与PRU侧则使用CCS（Code Composer Studio）配合MCU+ SDK，用于开发实时以太网固件和ICSSG固件。

环境配置中最容易出错的是设备树。CPSW与ICSSG的PHY节点必须与EVM实际连接一致，包括PHY地址、RGMII延迟、时钟源和端口映射。例如DP83867在RGMII模式下通常需要配置内部延迟，否则会出现链路能UP但丢包严重的情况。下面是一段典型的CPSW端口设备树片段示例（参数为教学示例，实际以EVM原理图和SDK默认值为准）：

&cpsw_port1 {
    phy-mode = "rgmii-id";
    phy-handle = <&phy0>;
    status = "okay";
};

&phy0 {
    reg = <0>;
    ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
    ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
    ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
};

CCS侧需要安装AM64x器件支持包和MCU+ SDK，导入示例工程后通过XDS110 JTAG连接EVM。若只做Linux TSN验证，CCS并非必需；但一旦涉及R5F实时协议栈或ICSSG固件，CCS就是唯一可靠的调试入口。

三、板级启动与网络连通性验证

上电后先通过串口观察启动日志，确认U-Boot能识别CPSW和ICSSG，并加载正确的设备树。进入Linux后，用 ip link 查看接口是否出现，用 ethtool eth0 确认链路速率和双工模式。若接口存在但链路Down，优先检查PHY复位、时钟和RGMII延迟；若链路UP但ping不通，则检查IP配置、VLAN和防火墙。

连通性验证建议按“物理层→链路层→网络层→时间同步”逐级推进。物理层看PHY寄存器与LED状态；链路层看 ethtool -S 的收发计数；网络层用 ping 和 iperf3 验证吞吐；时间同步则用 ptp4l 与 phc2sys 观察PTP偏移。只有这四层都稳定，后续的Qbv门控和流量调度才有意义。

四、验证检查表（可直接使用）