[参考译文] AM6442：A53上的 FIQ 中断

您好 Steven、

让我看看我们在这方面的情况、可能需要几天的时间才能回到这方面。 将保持联系。

此致、Andreas

谢谢 Andreas、非常感谢。

尊敬的 Andreas、您好、请返回查看您是否能够查看此内容。

我浏览了 GIC-500 TRM、但没有看到任何有关选择 FIQ 与 IRQ 的信息。 我猜这意味着我需要查看 Cortex A53文档、因此我今天将尝试这样做。 但是，如果你能指出我的正确方向，那将是一个重大的帮助。 谢谢！

Steven、

过去、内核 不使用 FIQ、但是有一些支持迹象被添加到上行内核、主要是在启用对 Apple M1 ARMv8芯片的支持的背景下、请参阅以下补丁系列：  https://lore.kernel.org/lkml/CAK8P3a1bXiWcieqTSZARN+to=J5RjC2cwbn_8ZOCYw2hhyyBYw@mail.gmail.com/T/ 和  https://lore.kernel.org/linux-arm-kernel/20210302101211.2328-9-mark.rutland@arm.com/T/  如果您在  上行内核树中特别查看 arch/arm64/include/asm、则可以找到合并的几个 FIQ 支持跟踪、并且内核应该可以在 M1芯片上引导。 我没有花时间了解我们的 AM6x SoC 有哪些可能、但让 FIQ 正常工作可能 需要将现有的 Apple M1支持扩展/添加/回退到 ti-linux-5.10.y 树、但这不是我们支持的、甚至是我所知的。 此时我不建议自己走这条路。

后退一步、您遇到的真正问题是与 Linux-RT 延迟相关、我们确实有其他客户报告涉及类似问题、我们的研发团队目前正在积极调查如何改善这种行为。 我建议我们将此主题再开放1-2周、以便我们可以通过这条途径分享更多详细信息。

此致、Andreas

此外、您能否分享一些有关如何设置和测试性能的系统级详细信息？ 您是否使用了任何标准测试工具？

谢谢、Andreas

您好、Andreas、感谢您的反馈。

我对 FIQ 选项进行了一些探究、当 ATF/OPTEE 设置 SCR_EL3.FIQ=1 时、它看起来有点复杂、因此 A53将所有 FIQ 路由为 EL3 (安全世界)。 我还没有弄清 ATF 是否有方法在 EL1中将周期性 FIQ 路由到 Linux、但我猜 这至少很难说。

我同意是否 可以改善 Linux-RT 延迟、这 将是一个更好的解决方案。 另一种选择是使用 AMP 模式、其中一个 A53内核运行 Linux、另一个内核运行裸机或 FreeRTOS。 但是、从 Processor SDK v8.04开始、这似乎不受支持。

为了进行基准测试、我将在(新的、SR2.0) AM64xEVM 板上使用处理器 Linux-RT SDK v8.04中的默认 SD 卡映像。 我已在 bootargs 中添加"isolcpus=1 "、以将第二个 A53内核 与调度程序隔离。 我运行的两个基准是：

1) 1)使用"任务集"进行循环测试、以便仅在 CPU2上进行调度。 首先、我使用以下命令加载 CPU：

yes > /dev/null &

然后启动 cyclictest 并将结果记录到一个文件中：

taskset -c 1 cyclictest -l300000 -m -S -p99 -i200 -h400 > cyclictest.txt

请注意、我仅运行300、000个循环@ 200us、因此它仅运行60秒、这非常短。 与 运行时间更长(例如小时)相比、这会带来更乐观的结果。 但这里的结果显示了60秒周期内的单个数字30-40us 延迟。  我看到跑步时间更长时接近60-70us。

2) 2)我使用的另一个基准是内核模块中断处理程序(使用 IRQF_NO_THread 保留的中断)。 这更能代表我要长期实现的目标。 该中断是 使用比较事件中断路由器路由的 PRU IEP 比较事件(周期性@ 20kHz)。 在 IRQ 处理程序中、我立即读取 IEP 计时器、并将其值与 延迟为零时的值进行比较。 结果被写入 MSRAM、 我 使用 CCS 中的图形工具对其进行图形化。 结果如下所示(左轴以纳秒为单位、底部轴 为采样#@ 20kHz)：

请注意、定期尖峰达46us：

我似乎从 这两个基准中获得了相似的结果。 如果它有助于我共享内核模块代码、但循环测试可能是您复制的更轻松的选择。

您好 Steven、

这很有用、感谢您提供更多详细信息。 我将把这一信息反馈给我们的研发团队、以便将其 视为正在进行的调查的一部分。 表面、以确保它看起来非常适用。 让我们下周晚些时候再次入住、看看我们在结束时的状态 遗憾的是、我没有为您提供即时答案、但您可能会理解相关系统级和 SoC 级调查的复杂性。

此致、Andreas

您好、Andreas、没问题、我理解 w.r.t. SoC 复杂性。

正如您在我之前发布的图表中看到的、内核驱动程序通常会看到小于3微秒的延迟、偶尔会突发到40微秒以上。 如果我们能够消除突发行为 、剩余的2-3微秒 就满足了我们的要求。

本周、我计划研究内核配置、看看是否有任何设置可改善此行为。 遗憾 的是、我还没有操作系统感知调试器、因此更难确定导致延迟尖峰的原因。

请告诉我您的团队是否在这个问题上取得了进展、或者我是否可以提供任何测试数据。

以下是我们调查的相关主题： https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1127375/sk-am62-real-time-performance/4186772、供参考

有几个问题和理论正在研究中、但最终的根本原因尚待确认。 会让您随时了解最新信息。

此致、Andreas

您好、Andreas、我被安排去做另一个项目、但明天我将回到这里来看看。 TI 团队是否在寻找解决 AM64x 上此延迟问题的方法方面取得了进展？ 我读取了您之前链接的线程、它似乎与我在这里遇到的问题相同。

您好 Steven、

调查仍在进行中，但我们的初步调查结果如下，所以以一粒盐来进行调查。 我们发现 Cortex-A SMP (ARM64)与后台高速缓存散列(如应力- ng 内存速率)以及窄 DRAM 具有循环异常值。 这与 SoC 供应商无关。  完全单核最坏的情况下、较旧的内核在最坏的情况下可能更好。 较新的 ARM 平均更好。  例如每10M 的最坏情况下为1。 对单个内核的限制(在内核命令行上使用 maxcpus=1) 似乎会导致问题消失、这可能是由于限制了 DDR 突发。  

此致、Andreas

尊敬的 Andreas：

感谢您分享您的结果、无论结果是初步的。 我们将尝试使用 maxcpus=1重新运行基准测试。 尽管我们必须评估总体性能影响、因为 它不是芯片上1/2最大内核未使用的理想选择。

遗憾的是、存储器互连具有如此大的延迟、因为这正是 Cortex R5设计用于解决的问题。 遗憾 的是、当在 DDR 之外运行 R5代码时、我们看到每条指令有60多个时钟周期(假设我们的代码不适合高速缓存)、从而有效地将800MHz R5转换为12MHz 微控制器。

由于延迟尖峰与 DDR 突发相关、您 是否希望 FreeRTOS SMP 而不是 Linux 获得相同的结果？

您好 Steven、

谢谢、对它有更多的双眼总是很好、请报告任何发现。

明白。 我们不是在最后，也许还有其他方式更优雅地解决这一问题。

我没有仔细检查过数字、但通过讨论、我知道 MCU 内核最好仅从片上存储器运行、而不是 DDR 运行。 R5代码需要多少代码空间？

一般来说、FreeRTOS 比 Linux 更"精简"、因此绝对数字可能更好/更小、但如果它确实是 ARM64 SMP +窄 DDR 的基本限制、则一般概念仍应适用。

您可以随时发帖、这在内部肯定会引起很多关注。

此致、Andreas

您好 Steven、

关于 R5f：如果这是您的选择、您应该尽可能地将代码放入 TCM 中。 它们与缓存一样大、速度同样快、不受(伪)随机驱逐的影响。 如果您可以在单核模式下运行(双) R5FSS、则可以为该单核使用两倍的 TCM (总共128 KB)。

片上 SRAM (2MB)在~60周期延迟时已经糟糕得多、并且 DDR 存储器在~160周期延迟(单个严格排序32位读取的延迟)下实际上不是一个选项。 与高速缓存结合使用时、SRAM 可能仍然可以工作、因为每个高速缓存行(对于顺序代码)只会影响您一次。

此致、

Dominic

尊敬的 Andreas 和 Dominic：

非常感谢您的建议。 我们计划使用 TI 网络堆栈(EtherNet/IP、Profinet 和 EtherCAT)、最后我检查了其中一些堆栈使用 大量 片上 SRAM。 例如、EtherNet/IP 适配器演示占用了~1MB 的 MSRAM、我不确定这些数字如何随着新 SDK 的推移而变化。 此外、我相信 DMSC 即使 在引导完成后也会保留一部分 MSRAM。 出于这些原因 、我将 MSRAM 视为不可用。

从 TCM 运行 R5F 代码时、我们确实看到了显著的性能提升。 但 TCM 的尺寸相当有限。 我们尝试移植到 AM64x 的应用程序当前通过内核模块运行、具有~50KB 代码和~4MB 数据。 大多数数据是一个大型共享缓冲区、因此 我们可以通过将该缓冲区移动到 DDR 将数据减少到~100KB。 但我的假设 是 、如果不进行重大大修、我们的应用就无法轻松适应 TCM。 我们还将64位浮点用于控制算法、与 R5F 内核相比、64位浮点运算在 A53内核上似乎具有很大的性能优势。 同样、我们可能能够将其中的一些浮点更改为32位浮点、但它需要进行大量更改。

感谢有关单核模式 Dominic 的建议、 如果我们在 R5F 上运行、具有128KB TCM 可能是合理的。 我交叉检查了我的数字、从 R5上的 DDR 执行时看到的~67个周期必须 主要是缓存命中次数。 160个周期的延迟肯定会使严格排序的 DDR 执行脱离表格。

除非 我们遇到主要障碍、否则我将继续寻找方法来降低 A53内核上的延迟。  除了 偶尔发生的延迟突发之外、我们在 A53内核上看到的性能也很好。  如果我们无法找到解决延迟突发问题的解决方案、我们将再次查看 R5F 内核。

在这里进行了很好的讨论、让我们保持这个线程处于打开状态。 我将更新我们网站上的任何其他发现。 请注意、下一周是美国假日周、即将到来、因此这可能会在我们结束时暂时暂停

尊敬的 Andreas：

   在 SR2.0 AM64EVM 板上使用"maxcpus=1 "时、我们基本上没有看到延迟变化、无论是在 cyclictest 中还是在我们的内核模式中断测试中。 通过  查看'lscpu '和'cat /proc/cpuinfo 的输出、我们确认 Linux 仅限于1个内核：

root@am64xx-evm:~# lscpu
Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          2
On-line CPU(s) list:             0
Off-line CPU(s) list:            1
Thread(s) per core:              1
Core(s) per socket:              1
Socket(s):                       1
Vendor ID:                       ARM
Model:                           4
Model name:                      Cortex-A53
Stepping:                        r0p4
BogoMIPS:                        400.00
L1d cache:                       32 KiB
L1i cache:                       32 KiB
L2 cache:                        256 KiB
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Mmio stale data:   Not affected
Vulnerability Retbleed:          Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 cpui
                                 d
root@am64xx-evm:~# cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 400.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

root@am64xx-evm:~# cat /proc/cmdline
console=ttyS2,115200n8 maxcpus=1 earlycon=ns16550a,mmio32,0x02800000 mtdparts=fc40000.spi.0:1m(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),256k(ospi.env),256k(ospi.env.backup),57088k@8m(ospi.rootfs),256k(ospi.phypattern);omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system) root=PARTUUID=7c6f56e7-02 rw rootfstype=ext4 rootwait
root@am64xx-evm:~# uname -a
Linux am64xx-evm 5.10.140-rt73-g3a997318d8 #3 SMP PREEMPT_RT Fri Oct 21 10:05:23 PDT 2022 aarch64 aarch64 aarch64 GNU/Linux

以下是  两个内核均处于活动状态时的循环测试结果(命令="cyclictest -l300000 -m -S -p99 -i200 -H400 > cyclictest.txt")：

"maxcpus=1"(命令与上述相同)下的循环测试结果：

感谢您提供详细的结果和控制台日志。 这似乎与我们观察到的情况不一致。 与团队核实解释…

您好、Andreas：我将电路板刷新为8.04 Linux-RT SDK (tisdk-default-image-am64xx-evm.wic.xz)附带的默认映像、以确保我没有无意中损坏任何内容、但我仍然看不到"maxcpus=1"带来的延迟差异。 请告诉我是否可以提供其他信息来帮助进行故障排除。

下面是一个额外的图、显示了"maxcpus=1 (垂直轴、以纳秒为单位)时内核模式中断处理程序随时间变化的延迟：

尊敬的 Andreas：

感谢您的反馈。 我同意您的调查结果、但 令人惊讶的是、15年前的 Cortex A9与更现代的 ARM 内核相比、性能会超过延迟。 但我认为这是一种在架构层面上进行的折衷、旨在提高其他领域的性能。

我们决定将代码库向前移植、以便在 R5F 内核上运行。 在 R5F 上运行中断基准测试显示中断延迟小于300ns、抖动小于75ns；与 A53相比有了巨大改进。 感谢您的帮助、指导我们朝着正确的方向前进。