[参考译文] AM62L：AM62L 实时性能问题

您好、Xi、

在进行任何开发之前、我始终希望确保我们具有相同的“已知良好“起点。

在尝试任何内核隔离之前、您是否尝试通过执行文档中的确切步骤来复制官方文档的抖动结果？ 请使用未修改的默认 SDK 映像共享该测试的结果：
https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM62LX/11_02_08_02/exports/docs/devices/AM62LX/linux/RT_Linux_Performance_Guide．html

此致、

Nick

您好、Nick、

您好、Xi、

在继续之前：

免责声明:我不是调优 RT-Linux 的专家  

在调整您的 RT Linux 系统时、我将与您一起学习。

您使用的处理器是什么？

您提到了 AM62L、但您的终端日志报告了 AM62x (am62xx-EVM、而不是 am62lxx-EVM)。 您正在使用哪种处理器？

这些不同的处理器的硬件略有不同、这会影响您为提高性能而进行的一些调整。

请介绍一下您的用例  

好的、我们有 2 个内核。 您希望 core1 专用于执行单个繁重的任务（我假设这是 CodeSys 的待机项）、以及在 core0 上运行的所有其他任务。 是这样吗？

 core0 上正在运行哪些其他任务？

我看到 您的当前测试设置有任何问题吗？  

我过去曾使用 cgroups 在处理器内核之间分配任务。 我不确定它是否会导致与 isolcpus 明显不同的行为。 我随附了 AI 代理的以下反馈[1]。

如何针对您的应用调整 RT-Linux 性能？  

您可以在此处找到一些有关调整 RT Linux 性能的入门文档：
https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM62LX/latest/exports/docs/linux/How_to_Guides/Target/How_to_Tune_Real_Time_Linux．html

Bootlin 还提供出色的培训。 您可以在此处找到他们的 RT Linux 培训：
https://bootlin.com/training/preempt-rt/

第一步是禁用未使用的任何应用程序或驱动程序、无论代码运行在哪个内核上。 为什么？

Core1 仍然会受到 core0 上运行的代码的影响、即使在您隔离任务和中断后也是如此：

1) 共享缓存：A53 集群中的所有内核共享一个缓存。 缓存未命中意味着响应时间更长

2) DDR 接口：如果两个内核都执行繁重的 DDR 流量、这可能成为瓶颈

此致、

Nick

[1]关于 隔离章节 与隔离章节的 AI 反馈：

问: 隔离性脓和群隔离有什么区别?

答： 【一般知识】两种机制、主要区别：

isolcpus（你有什么）

内核调度程序机制。 在启动时工作、无需用户空间。

工作原理：
-域—从 SMP 负载平衡域中删除 CPU 1。 调度程序不会自动将任务迁移到 IT 上
- managed_IRQ—防止将 managed IRQ (MSI/MSI-X) 分配给 CPU 1
-任务仍然可以通过 taskset/sched_setaffinity 显式固定到隔离的 CPU

限值：
-内核线程（kthread_cpus=0 有助于但不完整的覆盖）
-一些内核子系统忽略它
-不执行—任何进程都可以调用 sched_setaffinity 并在 CPU 1 上运行
-无内存、I/O 或网络隔离—仅限计划

CPUset cgroups（您没有的内容—CONFIG_CPUSET 未设置）

分层资源容器。 由内核在任务级别强制执行。

其不同之处：
-硬分区:将 CPU 分配给 cgroups ,该 cgroup 中的任务无法在其他地方运行
- cpuset.cpus.exclused=1 (cgroups v2)—完全独占所有权,而不仅仅是隔离提示
-与 cpuset.MEMS 结合使用—还隔离 NUMA 内存节点（在单插槽 AM62L 上不太相关,但仍影响页面分配器
行为）
-可继承:子进程自动保留在 cgroup 中
-可与其他 cgroup 控制器组合（内存限制, I/O 权重）

关键的语义差异：

isolcpus :“调度程序,不要把东西放在这里,除非明确要求“
CPUSET：“此 CPU 属于此 cgroup、完全停止“

isolcpus 是调度程序的一个选择退出提示。 CPUset 是强制分区。

如果没有 CONFIG_CPUSET、什么仍然可以迂回 CPU 1？

【一般知识】即使是完整的命令行：
- workqueue 线程—kthread_cpus=0 有所帮助、但 WQ_unbound 工作队列可能仍使用任何 CPU
- Softirqs—绑定到硬件中断触发的 CPU；irqaffinity=0 有助于但不完整
-计时器 softirqs—nohz full=1 抑制大多数内核活动,但并非所有内核活动
-任何显式调用 sched_setaffinity(1) 的进程—没有强制层可以在没有 cpusets 的情况下停止

针对 CPU 1 上实时工作负载的实用建议

【一般知识】

选项 A—纯 isolcpus（您拥有的）：如果您的 RT 任务是您有意固定到 CPU 1 的唯一任务、并且您信任、则足够了
用户空间不会出现行为异常。 变得更轻松。

选项 B—启用 cpusets：更强的保证。 已隔离引导 CPU 1、然后：
#为 RT 任务创建专用 cpuset
mkdir /sys/fs/cgroup/cpuset/rt
Echo 1 >/sys/fs/cgroup/cpuset/rt/cpuset.cpus
Echo 0 >/sys/fs/cgroup/cpuset/rt/cpuset.mems
ECHO $RT_PID >/sys/fs/cgroup/cpuset/rt/tasks

#剩余的系统任务保留在 root cpuset 中（仅 CPU 0）
Echo 0 >/sys/fs/cgroup/cpuset/cpuset.cpus

这两种方法都是最强的：在配置 cgroups 之前、isolcpus 会在引导期间使调度程序保持离开；cpusets 会强制执行分区
运行时间。

给定 config_CPUSET 未设置—如果您的 RT 工作负载敏感、则值得启用它。 单个内核重新编译成本非常高
运行时隔离保证增益。

目标绩效是什么？  

您是否正在寻找特定的基准编号？

或者、您只是想让 cyclictest 数字消失、然后使用新配置重新运行 CODESYS、看看更快的 cyclictest 是否与更好的 CODESYS 性能相关联？

您好、Nick、

非常感谢您的答复。

首先、我采用的实际硬件模型是 AM62L3。

其次、我的核心业务应用程序是 CODESYS。 实时工作负载作为 CODESYS 主站运行。 我通过 CODESYS 上层计算机将所有 CODESYS EtherCAT 任务配置为在实时 Core 1 上调度。

根据我的测试方案：我计划首先使用专业测试命令验证系统的实时抖动。 我期望在 48 小时的长期连续测试中最大抖动可以保持在 70 微秒以下。 达到这一目标后、我将部署实际的业务场景、包括通过 EtherCAT 总线驱动伺服电机、以及通过 CODESYS 主机软件监测峰值抖动值。 因此、我使用 cyclictest 和 stress-ng 来模拟与实际业务负载一致的高 CPU 占用率和大内存压力。

此外、我正在对您同时提到的 cpuset 隔离解决方案进行相关的验证测试。 获得新结果后、我会及时向您反馈最新的测试数据。

此致、

十一

已编辑 2026年5月18日 — 以红色编辑

您好、Xi、

对本周的期望

我的 AM62L EVM 已设置完毕。 我将 在本周运行测试、以隔离可以减少最坏情况下延迟的特定设置。

我预计大量的 DDR 流量将导致最坏情况下的中断响应时间增加。 我不确定<70usec cyclictest 对于 48 小时测试是否合理、但让我们看看能达到多低。

test 260518_1：完全复制 SDK 11.2 文档中的命令 （使用 OPTEE TRNG 驱动程序除外）  

更新：SDK 基准测试结果是在启用伪 RNG 驱动程序的情况下捕获的。 我 没有为该测试启用它。 将使用更新后的结果再次运行。  

我的初始结果与文档不匹配。 即可
对于双核 A53、* stress-ng -c 4 vs -c 2
* 警告: STAT /dev/cpu_dma_latency 失败:没有这样的文件或目录

后续行动说明：

是的、stress-ng -c 4 是 TI 针对所有 AM6 器件运行的标准测试、无论 A53 内核是四核还是双核都是如此。 与测试结果无关。

 预计会显示有关 CPU_DMA_LATENCY 的警告。 TI DMA 驱动程序没有 CPU_DMA_LATENCY 选项、这就是 Cyclictest 无法在此处理器上找到它的原因。

root@am62lxx-evm:~# uname -a
Linux am62lxx-evm 6.12.57-ti-rt-g31b07ab8dfbc #1 SMP PREEMPT_RT Thu Dec  4 13:07:37 UTC 2025 aarch64 GNU/Linux

root@am62lxx-evm:~# stress-ng --cpu-method=all -c 4 &
[2] 1002
[1]   Done                    stress-ng --cpu-method=all -c 2
root@am62lxx-evm:~# stress-ng: info:  [1002] defaulting to a 1 day, 0 secs run per stressor
stress-ng: info:  [1002] dispatching hogs: 4 cpu
root@am62lxx-evm:~# cyclictest -m -Sp80 -D6h -h400 -i200 -M -q
WARN: stat /dev/cpu_dma_latency failed: No such file or directory
# Histogram
000000 000000   000000
000001 000000   000000
000002 000000   000000
000003 000000   000000
000004 000000   000000
000005 345248   762554
000006 27360548 24662134
000007 37407885 25009511
000008 24363913 18800255
000009 10887474 15688180
000010 3723560  10831733
000011 1546892  5943833
000012 880035   2643272
000013 538533   1211026
000014 319457   674355
000015 187475   449129
000016 117677   316653
000017 083693   227635
000018 066541   163902
000019 054741   119252
000020 042386   090612
000021 028144   076970
000022 016581   069648
000023 009738   059346
000024 005631   046448
000025 003812   034093
000026 002662   024576
000027 001900   018179
000028 001396   014439
000029 001044   011841
000030 000767   009951
000031 000603   008023
000032 000472   006384
000033 000324   005158
000034 000257   004241
000035 000189   003392
000036 000097   002807
000037 000086   002390
000038 000047   001997
000039 000034   001506
000040 000021   001195
000041 000012   000865
000042 000009   000688
000043 000004   000463
000044 000010   000362
000045 000001   000248
000046 000002   000206
000047 000004   000144
000048 000002   000081
000049 000001   000076
000050 000001   000050
000051 000004   000038
000052 000003   000028
000053 000005   000015
000054 000002   000013
000055 000001   000006
000056 000002   000005
000057 000004   000006
000058 000002   000002
000059 000001   000000
000060 000000   000000
000061 000001   000000
000062 000000   000000
000063 000003   000000
000064 000004   000001
000065 000003   000000
000066 000001   000001
000067 000003   000000
000068 000003   000000
000069 000002   000000
000070 000001   000000
000071 000002   000000
000072 000000   000000
000073 000004   000000
000074 000002   000000
000075 000003   000000
000076 000000   000000
000077 000002   000000
000078 000001   000000
000079 000002   000000
000080 000001   000000
000081 000004   000000
000082 000002   000000
000083 000002   000000
000084 000001   000000
000085 000003   000000
000086 000003   000000
000087 000001   000000
000088 000002   000000
000089 000000   000000
000090 000000   000000
000091 000001   000000
000092 000000   000000
000093 000000   000000
000094 000001   000000
000095 000000   000000
000096 000001   000000
000097 000000   000000
000098 000001   000000
000099 000000   000000
000100 000000   000000
000101 000000   000000
000102 000001   000000
000103 000001   000000
000104 000000   000000
000105 000001   000000
000106 000000   000000
000107 000000   000000
000108 000001   000000
000109 000000   000000
000110 000001   000000
000111 000000   000000
000112 000000   000000
000113 000000   000000
000114 000000   000000
000115 000000   000000
000116 000000   000000
000117 000000   000000
000118 000000   000000
000119 000001   000000
000120 000000   000000
000121 000000   000000
000122 000000   000000
000123 000000   000000
000124 000000   000000
000125 000000   000000
000126 000001   000000
…
# Total: 108000000 107999918
# Min Latencies: 00005 00005
# Avg Latencies: 00007 00008
# Max Latencies: 00126 00066
# Histogram Overflows: 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:

root@am62lxx-evm:~# stress-ng: info:  [1002] skipped: 0
stress-ng: info:  [1002] passed: 4: cpu (4)
stress-ng: info:  [1002] failed: 0
stress-ng: info:  [1002] metrics untrustworthy: 0
stress-ng: info:  [1002] successful run completed in 1 day, 0.77 secs

[2]+  Done                    stress-ng --cpu-method=all -c 4

下一个测试  

完全复制上面的初始测试

  在禁用 OP_TEE TRNG 的情况下重新执行测试 260518_1

后面的内容

DDR & A53 服务质量 (QoS) 和服务等级 (CoS) 可能对我们有帮助。 我还在阅读它。 面向未来读者的链接：

https://www.ti.com/lit/sprads6

 问题：AM6422：[LinuxRT]隔离式内核上的信令性能较差  

此致、

Nick

您好、Xi、

您是否使用伪 RNG 驱动程序为您的测试构建了 OP-TEE？
https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM62LX/11_02_08_02/exports/docs/linux/Foundational_Components_ optee.html#building-optee-with-PRNG

性能指南文档有一个小错误。 它提到了禁用 OP-TEE TRUE RNG 驱动器 (TRNG) 以及启用 Psueudo RNG 驱动器作为选项、这是不错的选择。 但是、性能指南中并未提及 TI 测试是使用默认 SDK 映像+ uboot 文件执行的、其中 u-boot 文件使用修改后的 OP-TEE 通过 PRNG 重新构建：
https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM62LX/11_02_08_02/exports/docs/linux/Foundational_Components /U-Boot/LCD BG-Build-K3.html 

我已提交工单以在未来的 SDK 版本中更新性能指南文档。

我将 在禁用 OP_TEE TRNG 的情况下重新运行测试 260518_1、以查看这是否允许我复制基准测试结果。

此致、

Nick

请注意、SDK 11.2 版本的 SDK 文档中有一个用于构建 OP-TEE 的错误、从 SDK 12.0 文档开始修复。  

这是 SDK 11.2 版本的文档中的错误参数：
https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM62LX/11_02_08_02/exports/docs/linux/Foundational_Components_OPTEE.html

Platform=k3-k3-am62lx

这是 SDK 12.0 版本的文档中的正确参数：
https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM62LX/latest/exports/docs/linux/Foundational_Components_OPTEE.html

Platform=k3-am62lx

我已提交工单、用于在未来的 SDK 版本中更新性能指南文档。

JIRA 只能更新未来版本。  是否有方法更新已发布版本的在线错误、以避免以后的读者因报告和确认而产生混淆。  

由于所有发布的版本将始终在线存在,让一个已知的错误存在于在线为世界范围的读者是没有意义的。

platform=k3-k3-am62lx

我在构建 OPTEE 时也发现了这个错误。 我向某人报告、如果它得到更新、您将不会再看到它。

您好、Nick、
我的 OP-TEE 固件使用 SDK 提供的预编译映像：board-support/prebuilt-images/am62lxx-evm/bl32.bin。 由于没有开发或修改要求、因此我直接使用此固件而无需重新编译。
但是、在查看我的日志记录时、似乎未正确加载 OP-TEE 模块。 虽然这不会影响整个系统的引导或功能、但您能否帮助确认此问题的潜在影响？ 以下是我的 U-Boot 日志和与 OP-TEE 相关的内核日志的相关摘录：

UBoot 日志：

NOTICE: bl1_plat_arch_setup arch setup
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v2.12.0(release):11.02.01-14-g5939ceaeb-dirty
NOTICE: BL1: Built : 08:05:07, Jan 28 2026
NOTICE: BL1: dram_class: 10
NOTICE: lpddr4: post start - PI training status=0x29c02000
NOTICE: bl1_platform_setup DDR init done
NOTICE: k3_bl1_handoff ENTERING WFI - end of bl1
NOTICE: BL31: v2.12.0(release):11.02.01-14-g5939ceaeb-dirty
NOTICE: BL31: Built : 08:05:11, Jan 28 2026
NOTICE: SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.5-v11.02.05a (Fancy Rat)')
get_device_type a0a
ERROR: Agent 0 Protocol 0x10 Message 0x7: not supported

U-Boot SPL 2025.01-g398f44b6f7db (Apr 30 2026 - 03:21:19 +0000)
SPL initial stack usage: 2048 bytes
Trying to boot from SPINAND
ERROR: Agent 0 Protocol 0x10 Message 0x7: not supported


U-Boot 2025.01-g398f44b6f7db (Apr 30 2026 - 03:21:19 +0000)

SoC: AM62LX SR1.1 HS-FS
Model: Texas Instruments AM62L3 Evaluation Module
DRAM: 512 MiB
ERROR: Agent 0 Protocol 0x10 Message 0x7: not supported
Core: 67 devices, 31 uclasses, devicetree: separate
MMC: mmc@fa10000: 0
Loading Environment from nowhere... OK
In: serial@2800000
Out: serial@2800000
Err: serial@2800000
Net: eth0: ethernet@8000000port@1
Warning: ethernet@8000000port@2 (eth1) using random MAC address - 4e:11:69:6c:28:a0
, eth1: ethernet@8000000port@2
Hit any key to stop autoboot: 0
Total of 1 byte(s) were the same
Total of 1 byte(s) were the same
Setting bus to 0
ubi0: attaching mtd4
ubi0: scanning is finished
ubi0: attached mtd4 (name "ospi_nand.rootfs", size 123 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 991, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 4/1, WL threshold: 4096, image sequence number: 80226512
ubi0: available PEBs: 0, total reserved PEBs: 991, PEBs reserved for bad PEB handling: 20
Loading file '/boot/Image' to addr 0x82000000...
Done
Loading file '/boot/dtb/ti/k3-am62l3-plc.dtb' to addr 0x88000000...
Done
## Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Working FDT set to 88000000
Loading Device Tree to 000000008fff2000, end 000000008ffff7b9 ... OK
Working FDT set to 8fff2000

Starting kernel ...

这是关于 op-tee 的内核日志：

[1.338980]被测对象：探测管道方法。
[ 1.338998]选项：API uid 不匹配
[1.339004] optee firmware:optee:带有驱动程序 optee 的探测器失败、错误为–22

此致、

十一

测试 260519_1：完全复制 SDK 11.2 文档中的命令、包括禁用 OP-TEE TRNG 驱动器  

现在我能够复制 Linux SDK 11.2 文档中的观察结果。

第 1 步：获取 OP-TEE 源代码。 我将链接到 SDK 12.0 版本的文档、因为它修复了 SDK 11.2 文档中的一些错误。

第 2 步：使用伪 RNG 而非真 RNG 构建 OP-TEE 代码：

#!/bin/bash

# set variables
export OPTEE_PLATFORM="k3-am62lx"
export SDK_INSTALL_DIR="<path_to>/ti-processor-sdk-linux-rt-am62lxx-evm-11.02.08.02"
export CROSS_COMPILE_64="${SDK_INSTALL_DIR}/linux-devkit/sysroots/x86_64-arago-linux/usr/bin/aarch64-oe-linux/aarch64-oe-linux-"
export SYSROOT_64="${SDK_INSTALL_DIR}/linux-devkit/sysroots/aarch64-oe-linux"
export CC_64="${CROSS_COMPILE_64}gcc --sysroot=${SYSROOT_64}"
export CROSS_COMPILE_32="${SDK_INSTALL_DIR}/k3r5-devkit/sysroots/x86_64-arago-linux/usr/bin/arm-oe-eabi/arm-oe-eabi-"
export CFLAGS64="--sysroot=${SYSROOT_64}"
export KCFLAGS="--sysroot=${SYSROOT_64}"
export LDFLAGS="--sysroot=${SYSROOT_64}"

# clean sources
make CROSS_COMPILE="$CROSS_COMPILE_64" clean

# make OPTEE
make CROSS_COMPILE64="$CROSS_COMPILE_64" PLATFORM="$OPTEE_PLATFORM" CFG_ARM64_core=y CFG_WITH_SOFTWARE_PRNG=y CFG_USER_TA_TARGETS=ta_arm64

echo "Make succeeded!"

第 3 步：使用更新的 OP-TEE 代码重新编译 U-Boot：

#!/bin/bash

# set variables
export PLATFORM_DEFCONFIG="am62lx_evm_defconfig"
export SDK_INSTALL_DIR="<path_to>/ti-processor-sdk-linux-rt-am62lxx-evm-11.02.08.02"
export CROSS_COMPILE_64="${SDK_INSTALL_DIR}/linux-devkit/sysroots/x86_64-arago-linux/usr/bin/aarch64-oe-linux/aarch64-oe-linux-"
export SYSROOT_64="${SDK_INSTALL_DIR}/linux-devkit/sysroots/aarch64-oe-linux"
export CC_64="${CROSS_COMPILE_64}gcc --sysroot=${SYSROOT_64}"
export CROSS_COMPILE_32="${SDK_INSTALL_DIR}/k3r5-devkit/sysroots/x86_64-arago-linux/usr/bin/arm-oe-eabi/arm-oe-eabi-"
export CFLAGS64="--sysroot=${SYSROOT_64}"
export KCFLAGS="--sysroot=${SYSROOT_64}"
export LDFLAGS="--sysroot=${SYSROOT_64}"

export UBOOT_DIR="${SDK_INSTALL_DIR}/board-support/ti-u-boot-2025.01+git"
export TI_LINUX_FW_DIR="${SDK_INSTALL_DIR}/board-support/prebuilt-images/am62lxx-evm"
# I used prebuilt TFA
export TFA_DIR="${TI_LINUX_FW_DIR}"
# I used rebuilt OPTEE
# NOTE: Make sure to check out the appropriate OPTEE tag, check Release Notes
export OPTEE="/home/a0226750local/git/optee_os/out/arm-plat-k3/core/tee-pager_v2.bin"
# Using prebuilt OPTEE
#export OPTEE="${TI_LINUX_FW_DIR}/bl32.bin"

# clean sources
make CROSS_COMPILE="$CROSS_COMPILE_64" clean

#configure u-boot
make CROSS_COMPILE="$CROSS_COMPILE_64" "$PLATFORM_DEFCONFIG"

# build u-boot
make CROSS_COMPILE="$CROSS_COMPILE_64" BL1=$TFA_DIR/bl1.bin BL31=$TFA_DIR/bl31.bin BINMAN_INDIRS=$TI_LINUX_FW_DIR TEE=$OPTEE

echo "Make succeeded!"

测试结果：

root@am62lxx-evm:~# uname -a
Linux am62lxx-evm 6.12.57-ti-rt-g31b07ab8dfbc #1 SMP PREEMPT_RT Thu Dec  4 13:07:37 UTC 2025 aarch64 GNU/Linux
root@am62lxx-evm:~# stress-ng --cpu-method=all -c 4 &
[1] 936
root@am62lxx-evm:~# stress-ng: info:  [936] defaulting to a 1 day, 0 secs run per stressor
stress-ng: info:  [936] dispatching hogs: 4 cpu

root@am62lxx-evm:~# cyclictest -m -Sp80 -D6h -h400 -i200 -M -q
WARN: stat /dev/cpu_dma_latency failed: No such file or directory
# Histogram
000000 000000   000000
000001 000000   000000
000002 000000   000000
000003 000000   000000
000004 000000   000000
000005 316691   705021
000006 20586842 22417152
000007 29812256 33595187
000008 23874842 24719871
000009 16066047 15036644
000010 8610582  6758354
000011 3841554  2421157
000012 1763729  936561
000013 1002112  478290
000014 640858   266835
000015 406657   151581
000016 249747   094050
000017 157131   069519
000018 111235   059859
000019 091638   056972
000020 084283   053234
000021 078843   046950
000022 070029   037546
000023 057772   027135
000024 042498   018041
000025 030672   011984
000026 023045   008631
000027 017919   006895
000028 014503   005833
000029 012056   004995
000030 009495   003834
000031 007223   002603
000032 005447   001679
000033 003909   001064
000034 002929   000702
000035 002046   000463
000036 001535   000347
000037 001102   000274
000038 000761   000189
000039 000577   000142
000040 000375   000100
000041 000272   000080
000042 000190   000027
000043 000148   000025
000044 000131   000019
000045 000087   000009
000046 000064   000005
000047 000032   000004
000048 000028   000002
000049 000025   000001
000050 000025   000003
000051 000014   000000
000052 000011   000000
000053 000011   000001
000054 000005   000001
000055 000003   000001
000056 000003   000000
000057 000002   000000
000058 000003   000000
000059 000000   000000
000060 000003   000000
000061 000002   000000
000062 000001   000000
000063 000000   000000
...
000399 000000   000000
# Total: 108000000 107999872
# Min Latencies: 00005 00005
# Avg Latencies: 00008 00007
# Max Latencies: 00062 00055
# Histogram Overflows: 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:

更改 OP-TEE 设置如何影响 Linux 中断响应时间？

我的理解是 Linux 和 OP-TEE 之间的上下文切换可能会增加内核中断响应时间的额外延迟。 Linux 也有一个伪 RNG 驱动程序、因此禁用 OP-TEE 硬件 RNG 驱动程序意味着 Linux 在需要 RNG 时不会切换到 OP-TEE（因为 Linux 已经拥有用于生成 RNG 的驱动程序）。 由于上下文切换到 OP-TEE 减少、因此延迟降低。

这与禁用或移除 OP-TEE 不同。 我目前的理解是、如果您的应用需要定期切换到 OP-TEE、那么我们应该会预计延迟会再次增加。

此致、

Nick

请为 OP-TEE 加载问题创建单独的线程  

这样、我们就可以确保正确解决单独的问题

编辑了 2026年5月20日

测试 260519_2： 5 月 12 日完全复制客户设置、包括使用 OOB OP-TEE  

root@am62lxx-evm:~# cat /proc/cmdline
console=ttyS0,115200n8 vt.global_cursor_default=0 rcu_nocb_poll rcu_nohz=1 rcu_nocbs=1 idle=poll nohz=on nohz_full=1 kthread_cpus=0 irq
affinity=0 isolcpus=managed_irq,domain,1 earlycon=ns16550a,mmio32,0x02800000 root=PARTUUID=076c4a2a-02 rw rootfstype=ext4 rootwait
root@am62lxx-evm:~# uname -a
Linux am62lxx-evm 6.12.57-ti-rt-g31b07ab8dfbc #1 SMP PREEMPT_RT Thu Dec  4 13:07:37 UTC 2025 aarch64 GNU/Linux
root@am62lxx-evm:~# taskset -c 1 stress-ng --cpu 1 --cpu-load 70 --vm 1 --vm-bytes 80% &
[1] 986
root@am62lxx-evm:~# stress-ng: info:  [986] defaulting to a 1 day, 0 secs run per stressor
stress-ng: info:  [986] dispatching hogs: 1 cpu, 1 vm
stress-ng: info:  [988] cpu: for stable load results, select a specific cpu stress method with --cpu-method other than 'all'

root@am62lxx-evm:~# cyclictest -a 0-1 -t 2 -p 99 -m -D 0 &

# output from earlier in the day
policy: fifo: loadavg: 0.57 1.56 1.84 1/158 1920
stress-ng: info:  [986] failed: 0
T: 0 (  992) P:99 I:1000 C:86443004 Min:      5 Act:    9 Avg:   15 Max:     489
T: 1 (  993) P:99 I:1500 C:57628654 Min:      6 Act:    8 Avg:   28 Max:     295

# output as of 3:30pm central, not sure if stress-ng has finished running or not
policy: fifo: loadavg: 0.00 0.01 0.01 1/157 1964
T: 0 (  992) P:99 I:1000 C:90242144 Min:      5 Act:    5 Avg:   15 Max:     489
T: 1 (  993) P:99 I:1500 C:60161415 Min:      6 Act:    7 Avg:   27 Max:     295

这是^ 24 小时后进行的测试

面向未来进行规划：

1) OP-TRNG Re 运行测试 260519_2（禁用 OP-TEE TRNG）

2) 使用 OOB OP-TEE 的 Re 运行测试 260519_2、但具有不同的 cyclictest 参数：

* cyclictest -m -S -p99 -D6H -H600 -i200 -M -q  cmdline entry isolcpus=domain, 1 break -S 需要显式设置亲和性。

* cyclictest -m -a 0-1 -t 2 -p99 -D6H -H600 -i200 -M -q
*更改 1ms -->200 usec 测试间隔 (-i200)
*避免堆栈中的页面错误,并将内存交换到磁盘 (-m -M)
*将 cyclictest 优先级保留为 99（不确定这与 CodeSys 行为的关系）

请参阅在[1]处对最初两次测试之间差异的 AI 比较

此致、

Nick

[1] 将“Cyclictest -a 0-1 -t 2 -p 99 -m -D 0“的行为与“Cyclictest -m -Sp80 -D6H -H400 -i200 -M -q“进行比较

  ┌───────────────┬────────────────────────────────────────────────────────────────────┬──────────────────────────────────────────┐
  │   Parameter   │                cyclictest -a 0-1 -t 2 -p 99 -m -D 0                │ cyclictest -m -Sp80 -D6h -h400 -i200 -M  │
  │               │                                                                    │                    -q                    │
  ├───────────────┼────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
  │ Thread        │ -t 2 explicit 2 threads                                            │ -S auto: 1 thread per CPU                │
  │ creation      │                                                                    │                                          │
  ├───────────────┼────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
  │ CPU affinity  │ -a 0-1 pin to CPU0+1                                               │ -S handles affinity automatically        │
  ├───────────────┼────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
  │ RT priority   │ -p 99 (max SCHED_FIFO)                                             │ -p 80                                    │
  ├───────────────┼────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
  │ Duration      │ -D 0 [UNCERTAIN: 0 = indefinite or exit immediately — test before  │ -D 6h explicit 6-hour run                │
  │               │ relying on it]                                                     │                                          │
  ├───────────────┼────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
  │ Sample        │ default = 1000 µs                                                  │ -i 200 = 200 µs (5× more samples)        │
  │ interval      │                                                                    │                                          │
  ├───────────────┼────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
  │ Histogram     │ none                                                               │ -h 400 (buckets up to 400 µs)            │
  ├───────────────┼────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
  │ Stack         │ standard stack                                                     │ -M mmap stack (avoids stack growth       │
  │               │                                                                    │ faults)                                  │
  ├───────────────┼────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
  │ Output        │ verbose — prints every sample, floods terminal                     │ -q quiet — prints only final             │
  │               │                                                                    │ summary/histogram                        │
  └───────────────┴────────────────────────────────────────────────────────────────────┴──────────────────────────────────────────┘

您好、Nick、

在我们的项目中、未加载 OP-TEE 模块、并且我们的实际业务方案不使用任何安全模块。 我想知道、是否有必要朝这个方向努力并进行相关的核查？

我现在可以复制 Linux SDK 11.2 文档中的观察结果。

当我使用自构建 OPTEE 进行测试时、抖动在测试和下电上电之间会有所不同、有时我可以在您的/SDK 用户指南中获得良好的效果、有时会得到更大的数字。 您能测试更多次吗？

您好 Nick、ö m

非常感谢您帮助分析该性能问题。

首先、关于 isolcpus=managed_IRQ 参数、应用层没有配置额外的专用业务配置。

其次、对于 CODESYS 的资源占用评估、我们主要采用之前讨论的 Core 1 压力仿真模式。 我观察到、在实际服务场景中、Core 0 上的 CPU 负载会从 0%动态波动到 50%。 此类负载变化通常不会导致内核 1 上出现抖动。 我唯一担心的是、Core 0 上意外的急剧负载浪涌可能会影响 Core 1 的运行性能。

简而言之、我认为无需更改当前的测试环境配置。

此致、

十一

您好、Xi、

感谢您的确认。 现在、我将在我的测试中继续使用您自 5 月 12 日起的初始压力因素。 如果您将来还想找到更好的系统建模方法、请告诉我。

简要更新：今天的测试  

之前 24 小时的目标是进一步探究 cyclictest 参数如何影响测试结果。 我从另外 3 个测试中收集了直方图,我开始绘制它们的图形,以便更容易比较行为。 准备就绪后（可能明天）、我将分享这些信息、但我更高优先级的目标是使用不同的 DDR 选项运行测试。 可能要在几天之后才能看到这些图。

这些测试是：
260521_1 使用-i1000 复制 260520_2 (cyclictest -m -a 0-1 -t 2 -p99 -D6h -H600 -i1000 -M -q)
260521_2 复制 260520_2（OP-TEE TRNG 禁用）
260521_3 使用-i1000 复制 260520_2（OP-TEE TRNG 禁用）
260522_1 在不使用-M 的情况下复制 260520_2 (OOB OP-TEE)

后续步骤

我将 cyclictest 和 stress-ng 及其依赖项添加到基本文件系统映像中。 我将于明天报告初始测试。 （这是一个准系统图像。 文档位于此处： https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM62LX/11_02_08_02/exports/docs/linux/sdk.html Foundational_Components_Filesystem )。

我的假设是、从文件系统中删除大部分代码将改善延迟。 我们将 看到它有多大的不同。

我仍然可以了解 DDR 设置。 我希望在星期五 Night 开始运行 DDR 测试、但可能需要到下周。 请注意,星期一酒店是在美国度假的

此致、

Nick

我今天度假后的快速更新：

调整 DDR 设置极大地改善了延迟数。 到明天、我将得到 20 多次不同测试运行的直方图。

我将在您的时间星期三之前发布对结果的分析。 问题

DDR 设置影响

OP-TEE 设置影响  

文件系统影响（即删除代码的影响）

磁芯隔离的影响

不同循环测试参数的影响

您好、Xi、

状态更新  

已经运行了 26 次测试、所有测试时间均为 6 小时或更长时间。 生成 24 个直方图。 在接下来的几天里、我将继续每天进行几次 6 小时的测试。

调查结果摘要：  

1) DDR QoS 对测试设置的 cyclictest 结果影响最大。 我将为您提供运行实验的设置

2) 较小的文件系统不会显著减少延迟

3) cyclictest 参数对报告的结果有很大影响（具体来说，-i1000 vs -i200）。 由于 cyclictest 结果和 CodeSys 性能之间没有一对应的 1：1 映射、因此我会优先考虑实际的 CodeSys 性能、而不是特定的 cyclictest 输出数

需要进行更多测试来评价 OP-TEE 影响和内核隔离影响。

如何 使用 cyclictest 和 CodeSys 应用 DDR QoS 配置进行测试？  

在运行测试之前、请在终端中键入以下内容：

# first, set CBASS QoS priority
# A53 READ and WRITE ports default to the same EPRIORITY = 7
# 7 is the lowest priority
# set A53 READ port EPRIORITY from 7 (default) to 6 (higher priority)
root@am62lxx-evm:~# devmem2 0x45D20500 w 0x00006000

# verify write
root@am62lxx-evm:~# devmem2 0x45D20500

# next, set DDR priority
# DDR priority defaults to all entries = AXI priority 0 (highest priority)
# DDRSS DEF_PRI_MAP — map VBUSM priority 7 → DDR AXI priority 1
# all other PRIMAP entries stay 0 = DDR AXI priority 0 (higher priority)
# thus A53 READ has higher priority than WRITE
root@am62lxx-evm:~# devmem2 0x0F300030 w 0x00000001

# verify write
root@am62lxx-evm:~# devmem2 0x0F300030

请向我展示原始数据

没问题。

test_table.csv 中包含生成直方图的所有已运行测试的列表、以及每个测试使用的所有配置。

e2e.ti.com/.../260525_5F00_test_5F00_table.csv

CAL1/2/3 文件会比较直方图测试、这些测试可用于详细了解 cyclictest 参数、DDR 配置和文件系统的影响。

e2e.ti.com/.../cat1_5F00_cyclictest_5F00_parameters.html

e2e.ti.com/.../cat2_5F00_ddr_5F00_configuration.html

e2e.ti.com/.../cat3_5F00_filesystem.html

delay_report 具有所有直方图。

e2e.ti.com/.../latency_5F00_report.html

此致、

Nick

您好、Xi、

我只是想告诉大家、我仍在运行测试。 我将在星期五上汇总报告、说明我是否观察到 OP-TEE 和核心隔离方面的任何改进。

此致、

Nick

您好、Xi、

我得到了一些有趣的发现、说明如何为您的测试用例获得最佳的周期性测试结果：

1) 使用 DDR QoS 设置 — 已讨论过

2) 不要隔离内核 — 在所有测试中性能都明显较差

3) 请勿使用 OPTEE TRNG（如果您实际上没有加载 OPTEE，我假设不是一个因子）

4) 关于文件系统是否重要的数据是不确定的。 如果这很重要,效果比前面的 3 点要小得多。

我感到惊讶的是、核心隔离导致了性能的如此下降。 我不确定这会如何影响 CODESYS、但我建议关闭核心隔离以查看性能是否有所提高。

完整报告

e2e.ti.com/.../report_5F00_core_5F00_isolation.html

e2e.ti.com/.../report_5F00_ddr_5F00_qos.html

e2e.ti.com/.../report_5F00_optee.html

e2e.ti.com/.../report_5F00_filesystem.html

DDR QoS 设置的任何说明？  

这是我目前的草稿。 如果有后续问题、请告诉我。

e2e.ti.com/.../ddr_5F00_qos_5F00_a53_5F00_read_5F00_priority.md

后续步骤  

我将使用默认和基本文件系统对“最佳情况“进行几次测试、以查看行为是否存在差异。 之后、优化将在软件级别进行。

此致、

Nick

您好 Nick、ö m

感谢你的帮助。

添加 DDR QoS 配置后、我们运行 CODESYS 应用程序测试环境（1ms 周期、8 个电机轴正在运行）。 该测试持续了 6 小时，抖动范围为 — 141 μs 至 140 μs。 另一个性能指标显示达到 1120 μs 的最大周期持续时间、超过了预期的 1ms。

我们还使用 cyclictest 以相同的 DDR 配置进行验证。 在 6 小时测试中、最大抖动为 132 μs。 因此、我们期望探索新的优化方法来减少对 100 μs 目标的抖动。

至于核心隔离：禁用它并未显著改善 CODESYS 方案。 因此、我不建议将其关闭。 在当前设置中、CPU1 长时间保持 70%–75%的稳定负载、而 CPU0 以 40%–50%的频率运行。 如果 CPU0 上的负载随业务运营一起上升、禁用核心隔离可能会影响 CPU1 性能。

此致、

十一

对于未来的读者、我将关于使用 CodeSys 移动中断的讨论移到了另一个主题：
回复：AM62L：测试 CODESYS

此主题已经很长、因此我们将在此处重点介绍 cyclictest 结果。

您好、Xi、

1) 您是否测试了两个核心隔离=关闭且 DDR QoS =打开？  我建议同时使用这两个设置运行

2) 您是否创建了一个单独的主题来确认所讨论的 OP-TEE 行为？ 如果您确信您的用例未加载 OPTEE、那么我们不需要进一步研究。 我的假设是、启用 OPTEE TRNG 会通过在“常规“Linux 上下文和 OPTEE 上下文之间交换来导致延迟增加、因此如果您没有 OPTEE、就不需要担心 OPTEE 上下文切换。

此致、

Nick

您好、Nick、

是的、我已经尝试不启用 isolcpus、同时启用 DDR QoS、但我的测试命令仍然对指定的 CPU 内核应用固定应力：cyclictest -a 0-1 -t 2 -p 99 -m -D 0；taskset -c 1 stress-ng -cpu 1 --cpu-load 70 --vm 1 --vm-mbytes 80%&；taskset -cc 0 stress-load-cpu 1。

顺便说一下、  我对 CPU0 施加压力、因为根据 CODESYS 环境参考、对 CPU0 进行压力测试可以快速重现问题。 测试 6 小时后、电流最大抖动为 166us、而启用 isolcpus + DDR QoS 后、在相同的应力条件下、测试 6 小时后的最大抖动为 132us。

您好、Xi、

好的。 我一直在做一些背景研究不同的驱动器如何工作,试图确定下一个方向调查. 从驱动程序的角度来看、没有什么重要的要报告的。

其他 DDR QoS 设置可能会获得更好的性能（如果我们提高从 CPSW DMA 到 DDR 的数据传输的优先级）。

我没有 CodeSys 设置。 如果我提供寄存器设置、您是否能够运行测试并发回报告？

此致、

Nick

您好、Nick、

您好、Xi、

好的、我们从之前的测试略有不同的地方开始。 请记住、首先有 CBASS QoS（服务质量）表示哪些启动器在处理器内部的总线结构内具有优先级、然后是 DDR CoS（服务类别）、它将 CBASS 优先级与 DDR 控制器中的优先级映射在一起。

PREVIOUS TEST

CBASS QoS
EPRIORITY=0 is highest priority, 7 is lowest priority
CPSW DMA = 0 (unchanged)
A53 read = 6 (changed)
A53 writes & everything else = 7 (unchanged)

DDR CoS
priority 0 is highest priority, 7 is lowest priority
CPSW DMA = 0 (unchanged)
A53 read = 0 (unchanged)
A53 writes & everything else = 1 (changed)

对于 CBASS QoS、无法从 EPRIORITY = 0 更改 CPSW DMA。 调整测试的简单方法有 2 种：

1) 我们可以在 DDR CoS 处降低 CPSW 的优先级、以便在 CBASS 和 DDR 中都赋予 CPSW DMA 优先级 （如果延迟是由于 CPSW 未始终将数据包传入 DDR 而导致的，这可能会有所帮助）

2) 我们可以将 CBASS 中 A53 读取的优先级提高到与 CPSW DMA 相同、并调整 DDR CoS 以优于 A53 读取而非所有其他条目 （如果延迟是由 DMA 写入抢占 A53 读取以刷新高速缓存引起的，这可能会有所帮助）

通过寄存器写入来测试 CPSW DMA > A53 读取>所有其他内容  

CPSW > A53 reads > everything else

# Stage 1: CBASS — set A53 reads EPRIORITY=1
devmem2 0x45D20500 w 0x00001000
devmem2 0x45D20500               # expect 0x00001000

# Stage 2: DDRSS DEF_PRI_MAP
# PRIMAP0[30:28]=0: pktDMA/BCDMA (VBUSM 0) → AXI 0
# PRIMAP1[26:24]=1: A53 reads  (VBUSM 1) → AXI 1
# PRIMAP7[ 2: 0]=2: everything else (VBUSM 7) → AXI 2
# = (0<<28)|(1<<24)|(2<<0) = 0x01000002
devmem2 0x0F300030 w 0x01000002
devmem2 0x0F300030               # expect 0x01000002

通过寄存器写入来测试 A53 读取> CPSW DMA >所有其他内容

A53 reads > CPSW (Route ID match) > everything else

# Stage 1: CBASS — set A53 reads to EPRIORITY=0 (same bucket as pktDMA)
devmem2 0x45D20500 w 0x00000000
devmem2 0x45D20500               # expect 0x00000000

# This assumes route IDs for AM62L A53 cores match AM62x
# Stage 2: DDRSS — R1_MAT: match Route IDs 16-23 (A53 reads)
# R1_MAT: RANGEEN_A=1, MASK_A=3 (match octets), ROUTEID_A=16 → matches Route IDs 16-23 (A53 reads)
# = (1<<31)|(3<<28)|(16<<16) = 0x80000000|0x30000000|0x00100000 = 0xB0100000
devmem2 0x0F300024 w 0xB0100000
devmem2 0x0F300024               # expect 0xB0100000

# R1_PRI_MAP at 0x0F300034 stays at reset (0x00000000) — no write needed
# PRIMAP0=0 in R1_PRI_MAP → matched A53 reads (VBUSM 0) → DDR AXI 0

# DDRSS DEF_PRI_MAP
# PRIMAP0[30:28]=1: VBUSM 0 (pktDMA/BCDMA, unmatched) → AXI 1
# PRIMAP7[ 2: 0]=2: everything else (VBUSM 7) → AXI 2
# = (1<<28)|(2<<0) = 0x10000002
devmem2 0x0F300030 w 0x10000002
devmem2 0x0F300030               # expect 0x10000002

此致、

Nick

您好、Xi、

我将很快开始新一轮测试。 这是否看起来像您希望我运行以更紧密地复制您的环境的测试？

taskset -c 1 stress-ng --cpu 1 --cpu-load 70 --vm 1 --vm-bytes 80% &
taskset -c 0 stress-ng --cpu 1 --cpu-load 50 &
cyclictest -m -a 0-1 -t 2 -p99 -D6h -h600 -i1000 -q

此致、

Nick

您好、Nick、

您好、Xi、

感谢您发送编修。 本周晚些时候、我将详细介绍未通过的寄存器写入操作。

我现在正在使用内核配置开始新一轮测试 — 可能需要几天时间来运行所有测试。 预计下周早些时候会看到更多。

仅供参考、我仍在使用您的核心隔离设置、但其中一些设置实际上不适用于 AM62L：

root@am62lxx-evm:~# dmesg | grep -i "unknown\|command line"
[    0.000000] Kernel command line: console=ttyS0,115200n8 vt.global_cursor_default=0 rcu_nocb_poll rcu_nohz=1 rcu_nocbs=1 idle=poll no
hz=on nohz_full=1 kthread_cpus=0 irqaffinity=0 isolcpus=managed_irq,domain,1 earlycon=ns16550a,mmio32,0x02800000 root=PARTUUID=076c4a2a
-02 rw rootfstype=ext4 rootwait
[    0.000000] Unknown kernel command line parameters "rcu_nohz=1 idle=poll kthread_cpus=0", will be passed to user space.
[    5.787020] systemd[1]: Starting Generate network units from Kernel command line...
[    6.370733] systemd[1]: Finished Generate network units from Kernel command line.

以下是 AI 工具的分析摘要：

  What is actually active vs. dropped

  Dropped (passed to userspace, no kernel effect):
  - rcu_nohz=1 — confirmed not a real param.
  - kthread_cpus=0 — confirmed not upstream / not in this kernel.
  - idle=poll — [GENERAL KNOWLEDGE] this is an x86-only parameter, parsed in arch/x86/kernel/process.c. On arm64 (AM62Lx is
  Cortex-A53/A35-class arm64) the idle= knob is not registered, so it is silently ignored.

  Active and recognized:
  - rcu_nocb_poll, rcu_nocbs=1, nohz=on, nohz_full=1, irqaffinity=0, isolcpus=managed_irq,domain,1.

  The "no kernel threads on CPU 1" and "no idle entry on CPU 1" properties Set 1 appears to claim are not happening — those parameters
  are unknown.

  What to use instead on this arm64 kernel

  To actually get the protections that the dropped parameters were trying to provide:

  - Idle-state suppression on CPU 1 — at runtime, disable cpuidle states per-CPU:
  for s in /sys/devices/system/cpu/cpu1/cpuidle/state*/disable; do echo 1 > "$s"; done
  - Or use PM-QoS via /dev/cpu_dma_latency (write a 32-bit 0 and hold the fd open) for a global cap. [GENERAL KNOWLEDGE] cpuidle.off=1
  is a kernel param that disables cpuidle entirely; verify in this kernel before relying on it.
  - Kernel-thread placement — there is no upstream kthread_cpus= boot param. The closest mechanisms are:
    - nohz_full= already routes some kthreads off the full-dynticks CPUs automatically.
    - For unbound kthreads that remain, set affinity at runtime (taskset -p 1 <pid> for each unbound kworker) or use cgroup cpusets
  with the housekeeping mask.
  - rcu_nohz — drop it; not a real parameter.
  - nohz=on — drop it; redundant with the kernel default.

此致、

Nick

您好、Xi、

我能让您分享最新的内核配置吗？

我仍在编写该报告并测试 QoS 寄存器写入。

此致、

Nick

我无法复制您关于写入寄存器地址的观察结果：

root@am62lxx-evm:~# # writes for CPSW DMA > A53 reads > everything else
root@am62lxx-evm:~# devmem2 0x45D20500 w 0x00001000
/dev/mem opened.
Memory mapped at address 0xffff9f4dc000.
Read at address  0x45D20500 (0xffff9f4dc500): 0x00007000
Write at address 0x45D20500 (0xffff9f4dc500): 0x00001000, readback 0x00001000
root@am62lxx-evm:~# devmem2 0x0F300030 w 0x01000002
/dev/mem opened.
Memory mapped at address 0xffff9518a000.
Read at address  0x0F300030 (0xffff9518a030): 0x00000000
Write at address 0x0F300030 (0xffff9518a030): 0x01000002, readback 0x01000002

root@am62lxx-evm:~# # now writes for A53 reads > CPSW DMA > everything else
root@am62lxx-evm:~# devmem2 0x45D20500 w 0x00000000
/dev/mem opened.
Memory mapped at address 0xffff8103d000.
Read at address  0x45D20500 (0xffff8103d500): 0x00001000
Write at address 0x45D20500 (0xffff8103d500): 0x00000000, readback 0x00000000
root@am62lxx-evm:~# devmem2 0x0F300024 w 0xB0100000
/dev/mem opened.
Memory mapped at address 0xffffad545000.
Read at address  0x0F300024 (0xffffad545024): 0x00000000
Write at address 0x0F300024 (0xffffad545024): 0xB0100000, readback 0xB0100000
root@am62lxx-evm:~# devmem2 0x0F300024 w
/dev/mem opened.
Memory mapped at address 0xffffb93f7000.
Read at address  0x0F300024 (0xffffb93f7024): 0xB0100000
root@am62lxx-evm:~# devmem2 0x0F300030 w 0x10000002
/dev/mem opened.
Memory mapped at address 0xffff8a297000.
Read at address  0x0F300030 (0xffff8a297030): 0x01000002
Write at address 0x0F300030 (0xffff8a297030): 0x10000002, readback 0x10000002

读取命令应为“devmem2 0x0f300024“、而不是“devmem2 0x0f300024 w“。 我已经修复了我以前的帖子。 但无论是哪种方式、我都可以写入寄存器。

e2e.ti.com/.../6131.config.gz

您好、 Nick、

这是我最新的内核配置。

至于寄存器地址  0x0F300030、我仍然写入错误、没有弄清原因。 以下是错误日志：

root@am62xx-EVM：~# devmem2 0x0F300024、w 0xB0100000
/dev/mem 已打开。
存储器映射到地址 0xffffbe524000。
总线错误

您好、Nick、

您可以想到为什么 xi 仍然无法写入此寄存器吗？ （例如防火墙限制？）

谢谢、

Kevin

最终响应、讨论寄存器写入：

1) 我刚刚注意到您的终端输出显示“root@am62xx-EVM“、它通常与 AM62x 相关联、而不是 AM62L（请参阅我的终端输出“root@am62lxx-EVM“）。 您实际使用的是 AM62L 还是 AM62x？

2) 6 月 10 日、您表示 0x0f300024 是唯一无法写入的寄存器。 6 月 23 日、您表示 无法写入 0x0F300030、但针对 0x0f300024 复制/粘贴了输出 。 这将指向不同的问题。

案例 1：可以写入 0x0F300030、但不能写入 0x0f300024 

我在 TRM 中没有看到任何会导致此行为模式的因素：

- 0x0F300024 = EMIF_SSCFG_V2A_R1_MAT_REG、DDR16SS0_REGS_SS_CFG_SSCFG 中的偏移 0x24
- 0x0F300030 = EMIF_SSCFG_V2A_DEF_PRI_MAP_REG、偏移量 0x30—相同的 512 字节块、距离 12 字节

这两个寄存器都存在于 AM62L TRM (SPRUJB4A) 和 AM62x TRM (SPRUIV7C) 中具有相同的偏移量。 两者都是 R/W、RESET 0h、RESET
源 ctl_smod_g_rst_n

我排除了一些事情

- KICK 寄存器:任何一个器件的 DDR16SS SS_CFG 块中都没有脚踢解锁机制。 不是原因。
- CBASS 防火墙:两个 TRMS 显示没有（无防火墙）DDR16SS0SS_CFG (0x0F300000–0x0F3001FF )。 CBASS_FW_DDR_WRAP_MAIN_0_DDRSS_FW
防火墙位于 0x45000400 并保护 DDR 数据空间 (SDRAM)、而不是 SS_CFG CONFIG 寄存器。
-整个块的电源/时钟域:如果 DDR16SS 模块时钟被选通,0x0F300030 也会失败。 不过、
- V2A_CTL_REG 启用门控：EMIF_SSCFG_V2A_CTL_REG 仅包含 SDRAM_IDX、REGION_IDX 和 SDRAM_3QT—没有可以启用的位
通过门访问范围匹配寄存器。
- SS_CTL_REG 写保护：EMIF_SSCFG_SS_CTL_REG 在位上只有 PHY_PLL_BYPASS  0.无写保护机制。

案例 2：无法写入 0x0F300030 或 0x0f300024

AI 假设：当客户运行 devmem2 时禁用 LPSC_EMIF_LOCAL。 检查数据

AI 生成的摘要。 可能有错误的信息、我没有时间验证：

主题：devmem2 至 0x0F300024 / 0x0F300030 的总线错误—诊断和修复

两个失败的寄存器 (0x0F300024 = EMIF_SSCFG_V2A_R1_MAT_REG、0x0F300030 = EMIF_SSCFG_V2A_DEF_PRI_MAP_REG) 都位于 DDR16SS 中
0x0F300000–0x0F3001FF 处的 SS_CFG 块。 对该块的访问由 LPSC_EMIF_LOCAL (PSC0、LPSC 索引 9、TI SCI 器件 170) 进行控制。 。
AM62x TRM 确认此 LPSC 默认为关闭。 这两个寄存器都没有 KICK 寄存器锁、也没有 CBASS 防火墙（在 AM62x 中确认）
TRM)。 两个寄存器上的总线错误与在 devmem2 运行时禁用的 LPSC 一致。

SDK 中确认了以下事实：ti-processor-sdk-linux-rt-am62lxx-evm-11.02.08.02：

- AM62x Linux 设备树 (arch/arm64/boot/dts/ti/k3-am62-main.dtsi ,节点内存控制器@f300000) 声明电源域=
<&K3_PDS 170 TI_SCI_PD_EXCLUSCE>。
-唯一绑定到该节点的 Linux 驱动程序是 drivers/memory/k3-ddr.c、由 config_TI_k3_ddr 控制。 当该驱动程序绑定时、
drivers/pmdomain/ti/ti_sci_pm_domains.c 向 TIFS 调用 get_device_exclusive (170)、从而启用 LPSC 并将其保持有效。
- AM62L SDK 内核构建中未设置 CONFIG_TI_K3_DDR。 注意：检查的.config 是 AM62L 构建配置；是否是
AM62x 内核设置了 CONFIG_TI_K3_DDR、或不需要验证。
- U-Boot (drivers/ram/k3-ddrss/k3-ddrss.c) 在 DDR 初始化期间将器件 170 启用为 TI_SCI_PD_SHARED、并且不包含 power_domain_off ()
调用—它不会明确禁用 LPSC。

【假设】如果内核中未设置 CONFIG_TI_K3_DDR、则没有驱动程序绑定到存储器控制器@f300000、get_device_exclusive (170)
从不调用、并且 Linux 从不主动打开 LPSC_EMIF_LOCAL。 LPSC 随后被禁用的确切机制—
无论是在主机上下文切换期间通过 TIFS 撤销 U-Boot 的共享引用，还是其他路径 — 均未从源代码确认
代码检查、需要 TI 进行验证。

用户的 AM62L EVM 不会出现此问题、因为 AM62L 设备树没有用于 DDR SS_CFG 的存储器控制器节点
Linux 永远不会与 LPSC 交互。

步骤 1—检查内核配置：

zcat /proc/config.gz | grep TI_K3_DDR
#或
CAT /boot/config-(uname -r)| grep TI_K3_DDR

步骤 2 — 确认 LPSC 状态：

# PSC0 BASE = 0x400000; mdstat[j] at base + 0x800 + j*4; j=9→0x400824

devmem2 0x00400824 带

状态字段是位[5：0]。 值 3 =已启用。 任何其他值=禁用、确认总线错误是 LPSC 门控。

步骤 3—确认和取消阻止的解决方法：

Echo on >/sys/bus/platform/devices/f300000.memory-controller/power/control
devmem2 0x0f300024（带
devmem2 0x0f300030（带

永久修复：

在内核配置中启用 CONFIG_TI_K3_DDR=y 并重新编译。 这会使 drivers/memory/k3-ddr.c 绑定到存储器控制器@f300000
在引导时、通过 drivers/pmdomain/ti/ti_sci_pm_domains.c 激活 get_device_exclusive (170) 调用、并保留 LPSC_EMIF_LOCAL
被启用。

此致、

Nick

此外、还随附了我在 5 月和 6 月进行的测试摘要：

e2e.ti.com/.../RT_5F00_Linux_5F00_Optimization_5F00_Summary_5F00_customer.md