从PRU-ICSS到PRU_ICSSG：Sitara处理器实时单元迁移实战指南

1. 项目概述与核心价值

如果你正在使用德州仪器（TI）的Sitara系列处理器进行工业通信、实时控制或电机驱动相关的开发，那么你对PRU（可编程实时单元）一定不陌生。PRU-ICSS（工业通信子系统）及其增强版PRU_ICSSG（千兆工业通信子系统）是这些芯片里负责“硬核”实时任务的协处理器。简单来说，它们就像SoC里的“特种兵”，专门处理那些对时序要求严苛到微秒甚至纳秒级的任务，比如EtherCAT、PROFINET、EtherNet/IP等工业以太网协议，或者高速PWM生成、编码器接口等，从而把主CPU（通常是Arm Cortex-A系列）解放出来去处理更上层的应用逻辑。

在实际项目中，我们常常会遇到这样的场景：一个基于AM335x（比如经典的BeagleBone Black）开发的功能稳定、性能优异的PRU固件，因为产品升级、成本优化或性能提升的需求，需要迁移到新一代的平台上，比如AM57x系列或者最新的AM65x。这时候，如果你直接拷贝代码，十有八九会“跑飞”或者功能异常。原因就在于，虽然都叫PRU，但不同型号的Sitara芯片，其PRU子系统的硬件细节存在诸多差异。这份指南，就是为你梳理从PRU-ICSS（代表型号如AM335x, AM437x, AM57x）迁移到PRU_ICSSG（代表型号AM65x）或在这些家族内部迁移时，必须面对的硬件差异和软件修改点。它不是一份简单的功能列表，而是一份基于实际工程经验的“避坑”手册，旨在帮助资深工程师快速定位问题，高效完成移植。

2. 硬件差异深度解析与迁移影响评估

硬件差异是软件迁移工作的根源。理解这些差异不仅仅是看表格，更要明白其背后的设计意图和对你代码的实际影响。PRU_ICSSG并非PRU-ICSS的简单升级，它在架构上进行了增强，以支持更高的性能和更复杂的工业通信协议。

2.1 核心与时钟架构的演进

最显著的变化是核心数量的增加。PRU_ICSSG在传统的两个PRU核心（PRU0和PRU1）之外，引入了两个RTU_PRU（实时单元PRU）核心。你可以把RTU_PRU理解为功能与标准PRU几乎相同的辅助核心，但它们没有直接的I/O引脚（R30/R31）。这意味着，如果你的原有代码严重依赖PRU核心的GPIO进行位操作或波形生成，在迁移到使用RTU_PRU时，这部分逻辑需要重构，可能需要通过共享内存或事件与主PRU核心通信。

在时钟方面，虽然默认频率都是200 MHz，但最大频率和新的Core/VBUS同步模式是PRU_ICSSG的亮点。这个同步模式允许PRU核心与子系统内部互联总线（VBUS）锁步运行，能实现最低的访问延迟和最高的吞吐量。如果你的应用对访问外部存储器或外设的延迟极其敏感（例如，处理高速ADC数据流），在AM65x上启用此模式可能会带来显著的性能提升。迁移时，需要检查并可能修改PRU的CFG模块中关于时钟控制的寄存器配置。

2.2 内存映射：全局与本地地址的变迁

内存地址的变更是最常见也最容易出错的迁移点。这里需要从两个层面理解：全局内存映射和本地内存映射。

全局内存映射基地址的变化是强制性的修改项。例如，PRU-ICSS1在AM335x上的基地址是0x4A30_0000，而在AM65x的PRU_ICSSG1上变成了0x00_0B10_0000。如果你的Arm端Linux驱动或裸机程序通过/dev/mem或直接指针访问PRU控制寄存器或共享内存，必须更新这些基地址。一个常见的做法是在代码中使用宏或配置头文件来定义这些基地址，便于不同平台的切换。

// 示例：平台相关的基地址定义 #ifdef SOC_AM335x #define PRUSS1_BASE 0x4A300000 #elif defined(SOC_AM65x) #define PRU_ICSSG1_BASE 0x00B100000 #endif

本地内存映射的布局大部分保持一致，这算是个好消息。PRU固件内部通常使用本地偏移地址（如0x0002_0000访问INTC），这些偏移在PRU-ICSS和PRU_ICSSG之间是相同的。这意味着PRU汇编或C代码中基于本地地址的访问通常无需修改。主要差异在于新增模块的插入，例如PRU_ICSSG中增加的TM_CFG（任务管理器配置）、PA_STATS（数据包加速器统计）等模块占用了之前保留的地址空间。如果你的代码恰好操作了这些保留区域，就需要检查新平台的数据手册。

2.3 常量表：外设访问的“快捷方式”已改变

常量表（Constant Table）是PRU编程中的一个关键特性。它提供了32个固定的内存映射寄存器（C0-C31），PRU可以通过它们快速访问SoC内的各种外设（如UART、SPI、ePWM）和内部模块，而无需知道这些外设在复杂全局内存地图中的确切物理地址。

迁移时，常量表是重灾区。虽然表格结构（24个固定+8个可编程）没变，但具体条目映射的外设完全变了。例如，在AM335x上，C1指向DMTIMER2，但在AM65x上，C1指向了本地的IEP1定时器。如果你在PRU代码中使用了类似LBCO &data, C1, 4的指令来读取定时器值，在AM65x上，你读到的将是IEP1的寄存器，而非预期的DMTIMER2，这必然导致逻辑错误。

关键迁移步骤：必须逐行检查PRU汇编或C代码（通过pruss_intc_mapping等宏）中对常量表C0-C31的引用，并对照新旧平台的常量表映射表（如原文附录Table 9, Table 10）进行更新。对于AM65x，一个重要的灵活性是C15-C20, C23, C29-C31这些条目可以通过RAT（资源分配表）重映射到任何SoC地址，这可以用来模拟旧平台的部分地址映射，实现向后兼容，但每个PRU_ICSSG切片只有4个RAT区域，需要精心规划。

2.4 中断控制器（INTC）的扩展与重构

INTC是PRU与外部世界（包括Arm核心）通信的桥梁。PRU-ICSS和PRU_ICSSG的INTC基本框架（系统事件->通道->主机映射）相同，但细节差异巨大。

  • 系统事件数量与来源：PRU-ICSS支持64个系统事件（32内部+32外部），而PRU_ICSSG大幅扩展至160个（64内部+96外部）。这意味着事件编号完全改变了。例如，在AM335x上，UART接收事件可能是系统事件4，但在AM65x上，它可能对应一个完全不同的事件号。
  • 主机中断映射：主机（Host）是中断的出口。PRU-ICSS有10个主机，其中Host 1和2映射到PRU的R31寄存器用于核间通信，Host 3-6, 8-9映射到SoC级中断控制器（如Arm的GIC）。在AM437x和K2G上，Host 7的功能发生了变化，它被用于连接另一个PRU-ICSS实例，而不是连接到Arm。如果你原来的中断配置使用了Host 7，迁移时必须将其重新映射到其他主机（如Host 2-6或8-9）。
  • Arm端中断号：即使PRU INTC内部的主机映射正确，这个主机连接到Arm GIC的具体中断请求线（IRQ）编号也可能不同。Arm端的驱动程序必须更新这些IRQ号。

迁移策略：你需要整理一份新旧平台的“系统事件-主机-IRQ”映射对照表。首先在PRU固件中更新INTC的初始化代码，重新配置事件到通道、通道到主机的映射。然后在Arm端驱动中，更新请求的中断号。如果某个旧事件在新平台上不存在，可能需要改为轮询（Polling）模式，但这会引入延迟。

2.5 关键外设的功能差异与寄存器更新

不是所有外设都保持兼容。即使同一个外设，寄存器也可能有增减或位域含义变化。

  1. 工业以太网外设（IEP）：这是工业协议栈的计时核心。差异包括：

    • 定时器位宽：AM335x是32位，AM57x及以后多为64位。如果你的代码直接操作IEP计数器寄存器，需要考虑数据类型的扩展。
    • 比较寄存器数量：从8个（AM335x）增加到16个（AM57x, AM65x）。这为你实现更复杂的定时调度提供了可能。
    • 新增功能：如慢速补偿模式、32位影子模式、IEP1从模式等。迁移时需检查是否用到了新平台不支持的特性。

  2. MII_RT（实时MII接口）：这是实现以太网MAC的关键。PRU_ICSSG增加了对RGMII和SGMII模式的支持，这对于实现千兆以太网至关重要。同时，FIFO深度、硬件过滤、分类器等功能也有增强。如果你的PRU固件实现了自定义的以太网MAC或PHY管理，需要仔细核对MII_RT_CFG等相关寄存器的定义。

  3. 新增PWM模块：PRU_ICSSG独有。如果你需要在PRU中实现高精度PWM，现在有了专用的硬件外设，这比用GPIO模拟更高效、更精确。迁移时可以考虑将原有的软件PWM逻辑移植到硬件PWM模块上。

  4. MDIO管理：虽然基础功能相同，但PRU_ICSSG的MDIO模块寄存器有更新。如果固件包含PHY配置代码，需要检查MDIO控制寄存器的偏移和位定义。

2.6 加速器与指令集的微调

  • Scratch Pad：基本功能向后兼容。PRU_ICSSG新增了XCHG（交换）指令，可以单周期完成Scratch Pad的读-修改-写操作，能优化某些原子操作或锁的实现。
  • CRC模块：AM65x的CRC模块增加了CRC16-CCITT多项式和支持32字节推送的FIFO。如果你的协议栈使用CRC16-CCITT，可以启用硬件加速以获得性能提升。
  • 数据移动加速器：PRU_ICSSG引入了XFR2VBUS和XFR2PSI等新加速器。TI官方建议，在AM65x上访问外部存储器映射寄存器（MMR）时，应优先使用这些新加速器，而不是传统的LBxO/SBxO指令，因为前者能最小化PRU的停顿周期，提升效率。这是性能优化的关键点。

3. 软件迁移实操指南与步骤拆解

了解了硬件差异，迁移工作就可以按图索骥。下面是一个从PRU-ICSS（以AM335x为例）迁移到PRU_ICSSG（以AM65x为例）的实操检查清单和步骤。

3.1 PRU固件迁移检查与修改

PRU固件通常是用汇编或C语言编写，运行在PRU核心上的代码。迁移时，请按以下清单逐项核对：

1. 更新全局内存映射引用：

  • 操作：搜索固件中所有访问全局内存地址的指令（如通过常量表C28-C31进行可编程访问的地址）。如果这些地址是硬编码的，需要根据新平台的全局内存映射表进行更新。更常见的是，这些地址由Arm端通过共享内存传递，因此只需确保Arm端传递的值正确。
  • 注意：访问PRU本地地址空间（0x0000_0000 到 0x0003_FFFF）的代码通常无需改动。

2. 重构中断控制器（INTC）配置：

  • 操作：找到INTC初始化代码。根据新平台的《技术参考手册》（TRM）中INTC章节的系统事件表，更新以下内容：
    • EVT_MAP寄存器：将你所用的事件（如UART中断、定时器捕获事件）映射到通道。
    • CHAN_MAP寄存器：将通道映射到主机（Host）。
    • HOST_MAP寄存器：确认主机到PRU R31或系统中断的映射。
  • 示例（概念性代码）：
    // AM335x 可能配置 UART RX 事件 (假设是事件4) 映射到主机3 CT_INTC.EVT_MAP[4] = 1; // 事件4 -> 通道1 CT_INTC.CHAN_MAP[1] = 3; // 通道1 -> 主机3 // AM65x 需要查表找到 UART RX 事件的新编号，假设是事件100 CT_INTC.EVT_MAP[100] = 1; CT_INTC.CHAN_MAP[1] = 3; // 假设主机3仍然连接到Arm GIC

3. 更新外设寄存器访问：

  • 操作：对于IEP、MII_RT、CFG等有寄存器变更的外设，需要将旧的寄存器地址偏移和位掩码，更新为新平台TRM中定义的值。重点关注：
    • IEP的计数器宽度、比较寄存器数量。
    • MII_RT的FIFO状态寄存器、配置寄存器。
    • 如果使用新的PWM模块，需要全新编写驱动。

4. 修正常量表引用：

  • 操作：这是最繁琐但最关键的一步。逐行审查代码，对所有使用C0到C31的指令，根据新平台的常量表映射（Table 10）进行替换或重映射。
    ; AM335x 示例：通过C1读取DMTIMER2值 LBCO &r0, C1, 0, 4 ; C1 = DMTIMER2 ; AM65x 修改：C1现在指向IEP1，如果需要访问类似功能的定时器，可能需要改用其他常量表条目或通过RAT重映射 ; 假设通过RAT将C29重映射到了通用定时器地址 LBCO &r0, C29, 0, 4 ; 前提是C29已通过Arm端配置为映射到定时器

5. 评估并适配加速器使用：

  • 操作：如果旧代码使用了LBxO/SBxO频繁访问外部MMR，考虑在AM65x上改为使用XFR2VBUS指令，以减少停顿。如果使用CRC，检查多项式是否匹配，并考虑使用新的FIFO功能。

6. 处理SoC级差异：

  • 操作：PRU固件有时会通过常量表或全局内存直接访问SoC其他部分（如GPIO、另一个外设的寄存器）。这些外设的基地址和寄存器布局可能已改变，需要同步更新。

3.2 Arm端代码迁移检查与修改

Arm端代码负责PRU的初始化、固件加载、内存共享和中断处理。

1. 更新PRU子系统基地址：

  • 操作：在设备树（Device Tree）或驱动硬编码中，更新pruss或pruss_intc等节点的寄存器地址范围。例如，在Linux设备树中：
    // AM335x pruss: pruss@4a300000 { compatible = "ti,am3356-pruss"; reg = <0x4a300000 0x2000>, <0x4a302000 0x2000>, ...; }; // AM65x pru_icssg0: pru_icssg@b000000 { compatible = "ti,am65-pru-icssg"; reg = <0x00 0x0b000000 0x00 0x80000>, ...; };

2. 更新中断配置：

  • 操作：
    • 设备树：更新interrupts属性，使用新平台GIC对应的中断号。
    • 驱动代码：更新request_irq()或类似函数中使用的中断号。这个号需要根据新平台的《数据手册》或《技术参考手册》中PRU INTC主机到GIC的映射关系来确定。

3. 配置引脚复用（Pinmux）：

  • 操作：PRU的GPIO、MII/RGMII、UART等信号需要通过Pinmux连接到芯片引脚。新平台的引脚复用配置可能完全不同。必须根据新平台的《数据手册》和电路板设计，重新配置设备树中的pinctrl节点，确保PRU的外设信号正确路由到物理引脚。

4. 更新固件加载与内存映射：

  • 操作：如果使用pruss-remoteproc框架，固件文件名和内存区域通常由设备树或驱动自动处理。但如果是自定义的加载器，需要确保固件被加载到正确的内存区域（如PRU的程序RAM地址），这个地址在新平台上可能不同。

3.3 系统级配置与验证

  1. 时钟与电源管理：确认新平台的PRU子系统时钟源和默认频率配置。在某些低功耗场景下，可能需要额外配置时钟控制器模块以使能PRU时钟。
  2. 内存保护与防火墙：新一代SoC（如AM65x）可能有更复杂的内存保护单元（如PROTECT模块）。需要确保Arm核心有权限访问PRU的共享内存和数据RAM，以便进行数据交换。
  3. 循序渐进验证：迁移后不要期望一次性成功。建议采用分步验证法：
    • 步骤一：先让PRU跑一个最简单的LED闪烁程序（如果GPIO映射允许），验证核心、基础时钟和GPIO功能。
    • 步骤二：测试共享内存读写，验证Arm与PRU之间的基础通信。
    • 步骤三：测试INTC，验证中断能否正确从PRU触发到Arm。
    • 步骤四：逐个启用复杂外设（如IEP定时、MII_RT以太网），并与旧平台行为对比。

4. 常见问题排查与实战经验分享

在实际迁移过程中，你肯定会遇到各种“坑”。下面是我总结的一些典型问题及其排查思路。

问题一：PRU固件加载后毫无反应，Arm端也收不到任何中断。

  • 排查思路：
    1. 检查基地址：首先确认Arm端配置的PRU子系统基地址是否正确。一个错误的基地址会导致配置寄存器写入错误的位置。
    2. 检查时钟：使用调试器或读取PRU控制模块的状态寄存器，确认PRU核心是否已解除复位并有时钟。在某些平台，PRU时钟默认可能是关闭的。
    3. 检查中断映射：这是高频问题。使用pruss_intc_debugfs（如果内核支持）或直接读取INTC的EVT_MAP、CHAN_MAP、HOST_MAP和HOST_STATUS寄存器，逐级确认：系统事件是否产生？是否映射到通道？通道是否映射到主机？主机状态位是否置位？
    4. 检查Arm端IRQ号：使用cat /proc/interrupts命令查看你期望的中断是否被注册和触发。如果没看到，说明驱动申请的中断号错误。

问题二：PRU能运行，但访问某个外设（如通过常量表访问的定时器）时数据错误或操作失败。

  • 排查思路：
    1. 常量表映射错误：这是最大嫌疑。用PRU调试器单步执行，在访问常量表前后检查目标地址的值。与TRM中该外设的实际寄存器值对比。务必使用新平台的常量表映射。
    2. 外设时钟/电源域未开启：PRU能运行不代表目标外设已上电。确认你尝试访问的外设在系统层面已被使能（例如，通过设备树或SCMI协议）。
    3. 寄存器偏移/位定义已变更：即使外设相同，寄存器细节也可能有变。仔细核对TRM中该外设章节的寄存器描述。

问题三：从PRU-ICSS迁移到PRU_ICSSG后，网络性能下降或出现丢包。

  • 排查思路：
    1. MII_RT配置差异：检查FIFO深度设置。PRU_ICSSG的TX/RX FIFO可能是96字节，而旧平台是64字节。不正确的FIFO阈值配置可能导致上溢或下溢。
    2. 数据移动效率：如果你在PRU固件中使用LBxO/SBxO指令从共享内存搬移网络数据包，在AM65x上这会造成严重的PRU停顿。将其替换为XFR2VBUS/XFR2PSI指令可以极大提升吞吐量。
    3. 时钟与同步模式：检查是否启用了Core/VBUS同步模式。对于高吞吐量应用，启用此模式可以降低访问延迟。

问题四：使用RTU_PRU时，原本基于GPIO（R30/R31）的代码失效。

  • 解决方案：RTU_PRU没有物理I/O。你需要重构这部分逻辑。通常有两种方法：
    • 方法A（核间通信）：让RTU_PRU通过共享内存（Scratch Pad或Data RAM）与主PRU（PRU0/1）通信，由主PRU执行实际的GPIO操作。这需要设计简单的消息协议。
    • 方法B（任务卸载）：将不涉及直接I/O的纯计算或状态机任务分配给RTU_PRU，把宝贵的带I/O的PRU核心资源留给实时性要求最高的信号处理。

问题五：在AM65x上，试图通过常量表访问多个旧平台外设时失败。

  • 原因与解决：AM65x只有4个RAT区域可用于常量表重映射（C15-C20, C23, C29-C31中的部分）。如果你需要模拟超过4个旧地址映射，就会冲突。
    • 策略：优先重映射最常用、性能最敏感的外设。对于其他外设，考虑让PRU代码通过XFR2VBUS指令，使用完整的32位地址进行访问（虽然效率稍低）。或者，修改软件架构，减少对外部外设的直接访问。

最后，也是最宝贵的经验：永远不要假设兼容性。TI的文档虽然详尽，但最可靠的信息永远来自你正在使用的那个具体芯片型号的最新版《技术参考手册》（TRM）和《数据手册》。在开始迁移前，花时间通读新平台PRU相关章节，特别是“差异说明”部分，这能帮你提前避开80%的陷阱。调试时，一个支持PRU的JTAG调试器（如TI的XDS系列）是无价之宝，它可以让你实时查看PRU的寄存器、内存和单步执行代码，这是解决复杂问题的终极手段。