[参考译文] AM5726：memset 到 DDR 垄断了整个 EMIF 带宽

尊敬的 Rasty：

我已将问题分配给相应的专家。他会回来给你。

此致

Gokul

您好 Josue、

我找到了一些解释一些性能"旋钮"的文档。 我只理解关于带宽控制的第一部分、 它没有做到 是我所期望的 Seconds 部分是关于 COS,但它只是"复制粘贴"从 Sitara 手册,没有例子,在这部分的 doc 没有附加值

似乎 COS 是我需要的,但它谈到一些"主 ID ",我没有在 Sitara 手册中找到任何听起来像 "主 ID " 在 COS 的上下文.

我的目标是在访问 DDR 时赋予 A15内核1优先于内核0。  

我想强调的 是、我们讨论的是 A15核心级别的优先级。 一个磁芯比另一个磁芯更重要。

有人能举个例子吗？

谢谢

Rasty

您好、Rasty、

您指的是什么文档？

Unknown 说：

我找到了一些说明某些性能"旋钮"

我想我找到了文档。。。 这是一个吗？  https://www.ti.com/lit/an/sprabx1a/sprabx1a.pdf

无论如何、我相信您会发现我们有任何将 A15内核分离到各个内核的示例、因为 A 内核几乎总是在 SMP 模式下使用、而 HLOS 用于 TI 部署的用例。

此外、在主器件 ID 线程之后、A 内核没有差异、A15仅被称为 MPU。  

-Josue

你(们)好

我明白。

我们使用管理程序、因此不需要 SMP。

您能否详细介绍一下"SMP 模式与适用于 TI 部署的用例的 HLOS "。  如何将 A15置于非 SMP 模式？ 在 A15中我们不需要高速缓存一致性。 每个内核都是独立的- AMP。

谢谢

Rasty

您好、

是否可以修改高速缓存策略？  

什么是默认写入策略？ 直写还是回写？

是否可以对缓存控制器(L2CACHE_CTRL_MPU)重新编程？

谢谢

Rasty

Rasty、

您正在使用/计划使用什么 SDK？  
请阅读 TRM 4.3.2.1 MPU L2高速缓存存储器系统中的以下章节。

将需要请您联系同事以了解更多详细信息。

-Josue

你(们)好

SDK 并不重要、我们可以从您建议的每个 SDK 中获取示例和代码。

我的问题正是关于第4.3.2.1章！

该 章中提到的 MPU_L2CACHE_CTRL 的说明在哪里？

我正在寻找 高速缓存控制器的"旋钮"。

谢谢

Rasty

Rasty、

SDK 很重要、因为它描述了我们的标准支持。 不支持这些边界之外的任何内容。

其次、TRM 没有 列出"旋钮"这一事实让我可以理解、这不是您可以更改的内容、至少似乎 我们的 SOC 中没有提供 MPU_L2CACHE_CTRL。 我们的 ARM 工程师是不在办公室,直到2/25 ,只要他能够,他将跟进你的查询。  

好极了

Josue

尊敬的 Richard：

我使用了  EMIF_OCP_CONFIG 和 MPU_THRESH_MAX。 它没有达到我的预期。 可能是因为来自两个内核的流量 通过相同的瓶颈进行验证。  

但您给了我一个有趣的方向。

如何限制/暂停一个磁芯与另一个磁芯之间的距离？

在哪里可以阅读"CPU SEV"?

如果我们每个内核使用单独的 DDR (控制器)、该怎么办？ 它会有帮助吗？

另一件让我感到困扰的事情是暴冲大小。 根据我发现突发限制为120字节的信息、它产生的延迟远低于我们的测量值。

从高速缓存到 DDR 的最坏情况是什么？ 可能缓存的方向不正确？

谢谢

Rasty

您好、Rasty、

背景主导问题将是可接受延迟的范围是多少、各软件/硬件组件的预算编制是怎样的？  如果目标像我们这样、那么 DDR 本身可能不是一个好的选择、因为它的更新和定期培训可能更是这样。  将 OCMC 用于关键 RT 可能更可靠。   如果需要在较低的 MS 范围内、则可能更容易实现。 使用的 SW 非常重要。

每个内核的 EMIF 可能有助于减少一个抖动源。  L2缓存仍然是共享资源、因此争用可能占主导地位。  如果您可以将关键区域标记为正常的非缓存、可能会不太频繁、但是、这些硬件路径的性能较低、并且您不会得到缓存位置提升。

我建议将 WFE-SEV 作为一种低开销的跨核同步方法。  它记录在 ARM TRM 中。  通常、自旋锁是在这些基础上构建的。  其他方法(如跨 CPU PPI 中断)也将是开销较低的异步消息传递。  您的软件和预算将决定要使用的跨核心同步方法。   基本上、我建议在开始低延迟事件之前使用交叉核心半 phore/旋 锁等工具、获取资源锁、这会导致通用 CPU 旋转(无冲突流量)、让 RT 正常工作、然后释放锁。  使另一个 CPU 失速有点沉重、但可能适用于您的用例。

DDR 部分本身具有基本的突发大小、用于拉取/推送数据。  小尺寸可能会发生一些斩波或中断。  高速缓存的 A15将以高速缓存行大小(64字节)进行讨论。   

你(们)好

核心是完全独立的、不需要进行硬件同步。

我假设最坏情况下的延迟是几 usec、可能为10usec。 这仍然很好。

RTOS 侧的中断延迟非常小。 符合预期。 此外、任务延迟也很好。

但当我们移植完整的应用程序,我们已经开始看到一些奇怪的东西。

由 ISR 及时触发的应用程序(RTOS 线程)在某些情况下无法按时完成工作！

这是一种黑洞、运行 RTOS 的第二个内核在某处花费了数十个 usec。 在该程序流中不调用 RTOS。 看起来像 CPU 停滞。

起初我们认为它可能是 DMA/EMMC、但经过某些保留后、我们能够在 Linux 端使用3行代码重现此行为

main()

｛

X = malloc (2MB)

memset (x、0)

自由(x)

}

有两个 重要注意事项  

1.没有 memset+free 问题不会发生。 从进程堆到 Linux 空闲池的脏内存处理(brk/sbrk)似乎会导致此问题。

2.如果我分配的内存少于2兆字节,问题就无法解决!

2 MB 是 L3高速缓存的大小。  这就是我关注缓存的原因。  

此致

Rasty

您好：

使用 HW ETM 跟踪是了解每个内核上发生的情况的有效方法。  TI EVM 具有 MIPI-60连接器、可导出所有内核执行信息。   过去、我和另一位工程师一起调试了您提到的几乎确切的场景(Linux + RTOS)以及定期错过的最后期限。  使用 ETM 跟踪可以看到、Linux 运行了 cpufreq、有时它更改了共享的 a15内核时钟频率、这对 RTOS 有几个影响。  速度是第一个、但 RTOS 使用的 PMU 周期计时器的速率假设错误、因此它错误地计算了某个最后期限的时间差。  固定频率后、延迟是一致的、并且满足了用例截止日期。

上述内容很容易融入您的观察中。  "大型"memset 还会影响计时、但会影响多大的计时。  在某些情况下、memset 可能会低于完整的 L2缓存、从而强制重新加载大量代码。  一堆载荷的总和很容易使我们的东西增加很多。  不受控制的 Linux UI 可以执行许多破坏性操作... 假设有一个持续的缓存刷新调用或 tLB 使广播无效、它会同时命中两个内核 MMU。  正如 IO 所述、A15mpcore 和 Linux 的默认机器将在硬件信号级别定义内核之间共享的内容。  "SB"用于刷新 CPU0上的缓冲区、也会向 CPU1发送信号以刷新其缓冲区并等待完成、然后再继续。   如果您在 Linux 端将许多 MMU 项目标记为"非共享"、它对于这个角度也会有所帮助。  如果您试图保证低 us 范围内的某些内容、强制使备用核心安静、正如我所提到的、这可能是一个不错的选择... 这甚至可能意味着要"预先接触" ISR、以确保在启动抖动敏感型例程之前缓存 ISR。  

您好、

对于 RTOS 内核、我们通过 nirq 引脚使用来自 FPGA 的外部中断。 ISR 延迟非常好(我们使用 FPGA 计时器来测量它、并使用 CPU 时钟时间戳测量中断之间的距离、这两个时间戳都能提供协调结果)、所有这些都可以很好地抑制中断延迟。

我们在线程中完成所有有用的工作。

系统对5-10usec 抖动会有所犹豫、但我们错过了30秒可能是50usec 的情况。 很难准确地说出来。 对于相同代码、这看起来只是执行时间存在不规则性。 准时开始、但在上次运行完全相同的代码后完成30-40 μ s。

 Linux 中会禁用 CPU 频率节流和温度管理、并且 CPU 已正确冷却。

我们还使用仅几个字节的 memset 进行测试-同样的结果、Linux mmap 将整个块标记为"脏"。

memset 的大小无关紧要、整个 分配块的一个脏字节 已经包含相同的结果。

您还记得如何 在 Linux/Jailhous 中将整个 DDR 声明为非共享吗？

Thansk

Rasty

您好：

我不知道在现代 Linux 内核中如何做到这一点。 在过去,我试图黑客手术做这与实验成功,但它是脆弱的,并在下一个更新打破.  如果系统使用的是短描述符格式、您可以使用 PRRR 重新映射区域的可共享性。  使用 NMRR/PRRR 或 MAIR 有时是一个很好的角度、因为这些属性重映射器在初始化后不会经常被触及。  

另一个外科实验"黑客"可能是清除 两个核心中的 ACTLR.SMP 位。  这一行动的定义是 从一致性中取一个核心。  在 A15中、这是用于离线 CPU 的断电过程中对它的描述。  在 A9上、该序列是相似的、并且确实会导致广播操作被阻止(不再需要确认 DSB++请求)。  在 A15上、硬件有时会忽略这些设置并按照定义的方式修复内容、这一切都更加复杂。  这应该是一个~更容易的快速黑客.

我仍然会推荐一些更直接的方法、比如查看 ETM 跟踪。 如果您可以从高延迟事件设置 CTI 暂停触发器、则跟踪历史记录可能包含内核的确切操作。  通常、这种情况很容易观察到、有时会强制使用 JTAG 工具。 对于 MMU 检查和 ETM 跟踪,我发现 TRACE32提供了一个可信的解码,否则很难使用其他方法。  

你(们)好

将 内核1 (RT 内核)上的 ACTLR.SMP 设置为0没有帮助。 根据 Chatgpt 的说法、该寄存器在内核之间共享。

我们在定制电路板上只有基本的 JTAG 连接 TDI/TDO。

此致

Rasty

您好：

Chatgpt 错误、该寄存器是每个内核。  AI 是搜索的起点、但对于相对较少接触路径中的详细实验、需要查阅规范。

任何数量的引脚都可以获得良好的长运行 CPU 跟踪信息。  但是、即使没有导出跟踪引脚(仅限简单 JTAG 控制)、ETM 跟踪也可以用于这种情况、因为它会流式传输到一个小型的内部缓冲器中。  使用时间违例作为停止触发器、并通过一些滤波、您可以看到两个内核正在执行什么操作。  该流程在逻辑上类似于包含存储器的范围的使用方式。

我将随附一个简短的视频、其中介绍 ACTLR 检查和基本跟踪用法、以具体地展示方法。  使用时间因工具提供的支持级别而异。

e2e.ti.com/.../aux_5F00_trace_5F00_2025_2D00_02_2D00_27_5F00_08h21_5F00_12.mp4

你(们)好  

我从假期回来。

我们尝试在两个内核上运行以下代码。 相同的结果。  

其他想法?

谢谢

Rasty

Void DISABLE_SMP_MODE ( Void )｛

   无符号 int actlr；

    //读取 ACTLR

   ASM 易失性 (

       "MRC P15、0、%0、C1、c0、 1\n" //将 ACTLR 读入 actlr

       :"=r"(actlr)                //输出操作数

   )；

    //清除 SMP 位(位6)

   actlr &=~(1 << 6)；

    //写回 ACTLR

   ASM 易失性 (

       "MCR P15、0、%0、C1、c0、 1\n" //将 actlr 写回 ACTLR

       ：

       ："r"(actlr)                 //输入操作数

   )；

    //确保更改立即生效

   ASM 易失性 ("ISB\n"：：："内存")；

}

更新、此代码不正确。

在您的视频中、我了解到我们也可以通过 JTAG 调试器访问此寄存器。

如果我们使用调试器复位该位、这会有所帮助、即使仅在 RTOS 内核上复位也是如此。

我们尝试修复此代码并进行更新。

您好、Rasty、

根据您的笔记、我解释您进行了一个清除该位的实验、但当与调试器关联时、您发现它不正确。  然后、您使用调试器强制清除 SMP、并测量了一个改进。  接下来、您将尝试通过运行时代码获得相同的结果(考虑调试器)。   SMP 显然有助于减少耦合以减少干扰、这将是非常好的。

尊敬的 Richard：

我们清除了它,让程序运行整个,并做了几次我们的原始测试。 结果是 有希望的。

问题在于、任何操作都会尝试从 RTOS 应用写入该 CP15寄存器、要么不会产生任何影响、要么会产生异常。

CPSW 显示我们处于系统模式。 是否正常或必须处于 SVC 模式？ CP15的其他保护？

还有一个观察结果。 如果我通过 RTOS 这样做、则使用汇编指令将 ACTLR 设置为零没有问题。 启动后的值为0x40

在 Linux/jaihouse 值0x41下、同一条指令不起作用。

您好：

这将是一条特权指令、并非在所有上下文中都起作用。  Linux 会重写其中的一些寄存器是勘误表权变措施的一部分。  Linux 假定要进行 SMP 操作、因此在任何实验中处理该位可能需要做更深入的手术。

尊敬的 Richard：

我们设法创建了一个 Linux ko 来完成这项工作。

在一台机器上、它按预期工作、一秒钟无效果。

您能给我发送一份勘误表参考、并分享 您对"手术"的想法吗？

我们没有放弃这一方向,我们在设备上有竞争,这就是为什么它移动缓慢。

此致

Rasty

您好、Rasty、

我不理解。  这两台机器之间有什么不同？  它们是不同的主板或 CPU 类型还是？  不同之处在于允许它在其中一个而不是在另一个上工作。

一些 ARM CP15寄存器具有特殊属性。  它们的访问可以成为每种模式的选择性(一些位可以写入、其他位可以不写入)、有些是分组的(安全和非安全中的不同值)。  虚拟机管理程序模式还可以在其他位置添加写入陷阱的其他指示。  对于安全与非安全、TI 确实有一个"监控模式"调用(因为只有在安全模式下才能写入这些位)、并根据芯片版本、可能会在启动时写入不同的值(对于勘误表)。   我可以想象一下,如果你改变了 SMP 位在一个地方,其他一些地方可以改变它(说它的事情勘误需要设置)... 或在 ARMsub系统"关闭代码"之后、将进行背景保存和恢复(以包含勘误表)、这将更改值... 因此、如果"CPU-idle"在 c 状态下运行且 ARM 关闭、或者您进入睡眠状态并关闭、则该值将被重新编程。

你(们)好

通过2个不同的机器,我打算2个应该相同的定制板。

您是否知道如何 检查 包含修订版的 Linux CPU 信息？

谢谢

Rasty

运行时需要通过 SMC 调用进行勘误和特殊 cp15s 调用  omap_smc1.   At run timer there are checks for ARM core revisions and SOC revisions.  Any erratas are applied at run time.  A different chip version can activate different paths.  The ARM specific ones can be seen here: https://source.puri.sm/Librem5/linux/-/blob/b96eb58a96d9564d1880c112af705cb463fc4910/arch/arm/mach-omap2/omap-smp.c