[参考译文] Linux：如何测试 AM3x/AM4x/AM6x SoC 的实时性能？

德州仪器(TI)的默认 SDK 是您的项目的良好起点，它在展示我们芯片的所有功能方面做得很出色。 但是、即使处于空闲状态、默认的 SDK 也可以使芯片保持相当繁忙、尤其是从实时角度而言。 在我们能够合理地了解任何 TI SoC 的实时性能之前，我们首先需要生成一个更类似于您的实时应用所使用的环境的环境。

准备用户空间

首先，我们需要从用户空间中删除任何不需要的应用程序。 SDK 中的许多这些应用和服务绝不会将其转换为生产版本、而只会从我们关心的其他应用中获取资源。 ‘，TI 的 SDK Yocto 构建环境可以使通过“bitbake tisdk-Tiny image”(基本上是裸总线盒)生成“Tiny”映像变得非常简单。

注意：使用 TI 的微型 SDK 生成出色的性能数据非常容易，但这些数据并不能反映现实。 请务必在计划在生产映像上添加应用程序、以生成可使用我们的 SoC 实现的实时性能的最准确近似值。

正在准备设备树

接下来，我们可以开始简化内核的设备树。 TI 的入门套件和评估模块在展示 SoC 的所有外设和所有功能方面表现出色。 但是、与我们的用户空间应用一样、许多实时应用具有更集中的目的、使我们的入门套件上的许多外设不再需要、最终会损害我们的实时性能。

在 ARM 领域、SoC 制造商可以随意地将任何内容放在存储器映射中。 ‘，我们可以在0x02800000处放置一个 UART 实例，而 Broadcom 可以在0x7E201000处放置一个 UART 设备。 这种将任何内容放置在存储器映射中的自由、正是 Linux 内核开发出器件树概念的原因。 它本质上是一个由我们的引导加载程序加载的小文件，用于描述 SoC 具有的所有器件和外设。 内核将使用此文件初始化正确配置和运行此文件中所述的每个器件所需的所有驱动程序。

例如，如果我们为实时应用程序评估 am625，则可以使用 Linux 内核中的 K3-am625-SK.dts 设备树源文件来描述 am.alem 入门套件的所有功能。 为了为我们的应用实现更真实的指标、我们可以开始从此文件中删除器件、以模仿我们计划在最终产品上提供的支持。

例如、如果我们不打算使用任何 LED、我们只需从器件树中移除整个 LED 节点即可。

diff --git a/arch/arm64/boot/dts/ti/k3-am625-sk.dts b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
index 4f179b146cabc..27c31ed3bf7da 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
@@ -138,20 +138,6 @@ vdd_sd_dv: regulator-4 {
                states = <1800000 0x0>,
                         <3300000 0x1>;
        };
-
-       leds {
-               compatible = "gpio-leds";
-               pinctrl-names = "default";
-               pinctrl-0 = <&usr_led_pins_default>;
-
-               led-0 {
-                       label = "am62-sk:green:heartbeat";
-                       gpios = <&main_gpio1 49 GPIO_ACTIVE_HIGH>;
-                       linux,default-trigger = "heartbeat";
-                       function = LED_FUNCTION_HEARTBEAT;
-                       default-state = "off";
-               };
-       };
 };
 
 &main_pmx0 {

‘s，我们也可以在任何节点上使用“状态=“禁用”；”属性，内核将像删除节点一样运行。 ‘s，我们只需在&ospi0节点内添加“状态=“禁用”；”属性即可禁用 ospi。

diff --git a/arch/arm64/boot/dts/ti/k3-am625-sk.dts b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
index 4f179b146cabc..b9ee8994405e4 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
@@ -406,7 +406,7 @@ mbox_m4_0: mbox-m4-0 {
 };
 
 &ospi0 {
-       status = "okay";
+       status = "disabled";
        pinctrl-names = "default";
        pinctrl-0 = <&ospi0_pins_default>;

我们可以继续在内核源代码中删除/编辑以下文件中所有 AWAKEUP 唤醒/MCU/主域的节点

• k3-am62-main.dtsi
• k3-am62-wakeup.dtsi
• k3-am62-mcu.dtsi

直到我们粗略地近似于最终的器件树。

注意：确保保留其他节点将依赖的节点。 例如、SD 卡(&S)取决于多个其他节点(通过其相位链接)、以打开电源稳压器(&VDD_mmc1)并配置 pinmux (&MAIN_mmc1_PINS_DEFAULT)

‘m对最终的设备树感到满意后，我们就可以在内核源代码中使用“make dtbs”来重建 DTB。 然后、只需将生成的 K3-am625-SK.dTB 连同 SD 卡中的内核映像一起复制到/boot/目录中。

最后、借助专为实时应用定制的完整 rootfs 和内核、我们可以开始测试。

测量实时性能

Cyclictest 是更广泛的实时 Linux 社区使用的一款非常流行的工具、用于评估许多 SoC 的性能并在内核中查找需要开发人员注意的位置。 循环测试本质上运行一个非实时线程来启动大量测量(实时优先级)线程、这些线程将被定期唤醒以计算其已编程和有效唤醒时间(延迟)之间的差异。 此延迟本质上是 SoC 从后台负载切换到实时应用所需的时间。

此指标可用于粗略估算运行实时应用所需的时间。 例如、如果您有500us 的时间来执行某些操作、则需要从那时起减去 SoC 切换上下文所花费的时间(例如：75us)、从而为您的实时代码提供425us 的运行时间。 虽然 Linux 不是基于 RTOS 的操作系统、但我们可以合理地感到、Linux 在大多数时间内需要大约75uS (在这个组成示例中)才能进行切换。

可能会有一些学习曲线、尤其是对于刚从实时世界起步的开发人员而言。 但是，对 am625的一个很好的测试如下所示：

$ cyclictest -l100000000 -m -S -p90 -i400 -h400 -q > am625-cyclictest.hist

此命令指示 cyclictest 获取100m 样本400us、并将生成的直方图数据保存到名为 am625-cyclictest.Hist 的文件中。 采集100M 样本通常需要5个多小时、但结果将使我们对我们在上面开发的环境对我们的应用具有的性能进行相当可靠的估计。

就像一个实验一样、我已经从 rootfs 和设备树中删除了几乎所有内容、只保存了控制台 UART 和 SD 卡、以生成 am625可以产生的绝对最小值。 (您的设备很可能具有更大的延迟数，并且比仅记录循环测试结果更有用  )

使用 简单脚本 将直方图数据转换为 OSADL 样式图显示 am625平均值太6uS 而无法切换到实时任务。 尽管这些结果令人惊叹、但它确实应该是一个关于我们在评估 SoC 以实现实时应用时所具有的控制程度的课程。 我们在 SoC 上放置的后台负载越多、内核必须维护的驱动程序越多、我们可以在此处生成的延迟图中产生巨大影响。

总结

在实时 Linux 应用方面、有丰富的知识和经验、可帮助您估算、评估和调试我在这里未介绍的实时应用。 希望这能为您开始使用实时应用提供良好的起点。

~Bryan