[参考译文] AM62A7：C7x 干扰 A53 内核和 R5 性能

尊敬的 Ming：

我与 Victor 合作、在 AM62A7 系统中、我们遵循 SPL 引导流程、其中 Linux 中的 Remoteproc 驱动程序启动了远程内核 (R5、C7x)。

我不完全了解有关附加 AM62D_DDR_QoS.pptx 的说明。 我们应修改哪个 syscfg 以将 A53 和 R5F 更改为 DDR_RT？ 此外、如何将 qos_data.h 重建到 SPL 引导流程中？

我尝试了加载 C7x 和 R5 syscfg、但在 syscfg 中没有看到 QoS 配置。 我们使用的是 mcu_plus_sdk_am62ax_10_01_00_33。

谢谢、

Joseph

尊敬的 Ming：

QoS 配置好像在 WKUP R5 syscfg 中、而不是在 C7x 或 MCU R5 syscfg 中。

如果我在 U-Boot 中构建了一个新的 DM FW 映像和软件包、是否足以应用这些更改？

谢谢、

Joseph

尊敬的 Ming：

我能够应用您随附的 qos_data.h 更改并构建新的 DM FW。 我们看到 QoS 略有改进、但这仍不是我们所期望的。

通过更改 DDR_NON_RT 设置、是否可以为 A53/R5 获得更高的优先级？ 如果是、如何实现？

谢谢、
Joseph

您好、Joseph：

我发送给您的修复程序是针对 FreeRTOS SDK。 您需要重新编译 SBL_SD 或 SBL_OSPI。  对于 Linux、必须在 U-boot 中进行更改：

elixir.bootlin.com/.../am62a_qos_uboot.c

此致   

Ming  

尊敬的 Ming：

感谢您提供此信息！ 您能否确认在用于 Linux SPL 的 DM FW 引导流程中不需要更改？

此外、我还尝试在 U-Boot 中应用以下更改、将 C7x 内核的优先级降至最低、并提高性能。

{
		.reg = K3_QOS_REG(SAM62A_C7XV_WRAP_MAIN_0_C7XV_SOC, 0),
		.val = K3_QOS_VAL(7, 0, 0, 0, 0, 0),
},

您能否介绍一下尝试使用“A53和 R5F“建议并将 C7x 保持在 DDR_NON_RT 路径所需的更改“。

谢谢、

Joseph

尊敬的 Ming：

感谢您分享这些更改。 我能够构建新的 U-boot 和测试、但仍会看到性能延迟。 例如、在运行 C7x 代码时、R5 中的中断未达到预期频率。 我看到在该时间范围内从 100us 到 400us 的延迟。

我尝试在现有 QoS_DATA[]的基础上应用您的更改 、并在 K3_QoS_VAL 中尝试了不同的配置、例如将 C7x 的 epriority 字段更改为最低优先级。 我将 OrderID 字段 0x0 设置为 0x0、因为 TRM 提示将其保持为 0x0。

这些设置是否正确？ 请注意、我尝试了 C7x 的 IF 0 和#if 1 设置

struct k3_qos_data qos_data[] = {
	/* modules_qosConfig0 - 1 endpoints, 4 channels */
	{
		.reg = K3_QOS_REG(K3_DSS_UL_MAIN_0_VBUSM_DMA, 0),
		.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
	{
		.reg = K3_QOS_REG(K3_DSS_UL_MAIN_0_VBUSM_DMA, 1),
		.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
	{
		.reg = K3_QOS_REG(K3_DSS_UL_MAIN_0_VBUSM_DMA, 2),
		.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
	{
		.reg = K3_QOS_REG(K3_DSS_UL_MAIN_0_VBUSM_DMA, 3),
		.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},

	/* Following registers set 1:1 mapping for orderID MAP1/MAP2
	 * remap registers. orderID x is remapped to orderID x again
	 * This is to ensure orderID from MAP register is unchanged
	 */

	/* K3_DSS_UL_MAIN_0_VBUSM_DMA - 1 groups */
	{
		.reg = K3_QOS_GROUP_REG(K3_DSS_UL_MAIN_0_VBUSM_DMA, 0),
		.val = K3_QOS_GROUP_DEFAULT_VAL_LOW,
	},
	{
		.reg = K3_QOS_GROUP_REG(K3_DSS_UL_MAIN_0_VBUSM_DMA, 1),
		.val = K3_QOS_GROUP_DEFAULT_VAL_HIGH,
	},
	#if 1
	{
		.reg = K3_QOS_REG(SAM62A_C7XV_WRAP_MAIN_0_C7XV_SOC, 0),
		.val = K3_QOS_VAL(0, 0, 0, 7, 0, 0),
	},
	#endif
	{
	.reg = K3_QOS_REG(PULSAR_UL_WKUP_0_CPU0_RMST, 0),
	.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
	{
	.reg = K3_QOS_REG(PULSAR_UL_WKUP_0_CPU0_WMST, 0),
	.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
	{
	.reg = K3_QOS_REG(PULSAR_UL_WKUP_0_CPU0_PMST, 0),
	.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},{
	.reg = K3_QOS_REG(PULSAR_ULS_MCU_0_CPU0_RMST, 0),
	.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
	{
	.reg = K3_QOS_REG(PULSAR_ULS_MCU_0_CPU0_WMST, 0),
	.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
	{
	.reg = K3_QOS_REG(PULSAR_ULS_MCU_0_CPU0_PMST, 0),
	.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
	{
	.reg = K3_QOS_REG(SAM62A_A53_512KB_WRAP_MAIN_0_A53_QUAD_WRAP_CBA_AXI_R, 0),
	.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
	{
	.reg = K3_QOS_REG(SAM62A_A53_512KB_WRAP_MAIN_0_A53_QUAD_WRAP_CBA_AXI_W, 0),
	.val = K3_QOS_VAL(0, 8, 0, 0, 0, 0),
	},
};

谢谢、

Joseph

您好、Joseph：

“例如、在运行 C7x 代码时、R5 中的中断未达到预期频率。 在那段时间里、我看到从 100 μ s 到 400 μ s 的延迟。“

这表示问题可能不是由 QoS 设置引起的、因为 QoS 设置不应导致中断延迟。 它应该只影响数据路径和访问 DDR 的优先级。

您可能需要查看将中断长时间禁用的代码、尤其是对于 DSS 中的 DMA、因为它们也会设置为高优先级。

根据 TRM、 无法设置 SAM62A_C7XV_WRAP_MAIN_0_C7XV_SOC 的工龄、因此将其设置为 7 根本不会生效。

此致、

Ming

尊敬的 Ming：

我想我的最后一封邮件有些混淆、因此我会尝试澄清一下。 我们正在测量中断 (R5 和 A53) 中的延迟。 我们有一个保证的硬件触发下降沿中断、频率为 2kHz、我们使用 ISR 来取消置位该中断。 我们在整个应用程序中测量将中断置为无效所需的时间、当 C7x 代码运行时、该时间会增加。 另外、在示波器上、我们会看到该中断的上升沿（置为无效）被进一步延迟、这表明 ISR 需要更长的时间才能运行。

我确认、在 AM62A TRM 的第 3.5.2.2 节中、 C7X256V0 QoS 映射显示“支持优先级“说“不支持“ 我们可以对 C7x 或 A53/R5 QoS 做哪些其他更改来减少我们看到的延迟？

谢谢、

Joseph   

您好、Joseph：

由于 C7x 已设置为具有 epriority 0 的 DDR_NON_RT 路径、并且 A53 和 R5F 已设置为具有 epriority 0 的 DDR_RT 路径、因此、您无法通过 QoS 设置进行改进。

如前所述、您可能需要检查 C7x 内核代码、这将禁用来自 A53 或 R5F 内核的中断。

此致、

Ming

尊敬的 Ming：

您好、Joseph：

我在办公室里呆了 4 天。 我们将赶上 e2e 主题、明天继续回复您。

此致、

Ming

您好、Joseph：

由于您已将 R5F 和 A53 设置为 DDR_RT 路径、该路径的优先级高于 DDR_NON_RT 路径上的 C7x、因此、C7x 负载增加不会影响 R5F 和 A53 ISR 的延迟。 为了进行验证、您可以将所有 R5F 相关代码/数据放入 TCM 中（而不是在 DDR 中）。 如果延迟是正常的、则它与 QoS 相关。 如果延迟仍然很高、则还有其他因素会影响 R5F 延迟。

此致、

Ming

尊敬的 Ming：

感谢您的建议。 我实际上尝试了使用 C7XV_RSWS_BS_LIMITER 寄存器、能够大大降低延迟。 我们仍在测试最佳配置、但看起来我们能够限制每个内核的最大读写事务数。 默认情况下、这些设置设置为 64、我通过降低该数字进行测试、直到我们看到性能得到改进。

我认为可以通过配置带宽限制寄存器 (CIR/PIR) 来进一步调优。 这些寄存器中每个寄存器的速率单位是什么？ TRM 未指定此项。

此致、

Joseph

尊敬的 Ming：

感谢您提供了编码。 对于 C7XV_RSWS_BS_limit 、我实际上在 U-boot 中设置了 am62a7_init.c 中的寄存器。 我不确定这是否应该在 DM R5F 中运行（就像您推荐的 SAM62A_C7XV_RSW_BS_LIMITER6 一样）、但当我  在 Linux 中读取 C7XV_RSWS_BS_LIMITER 寄存器地址时、这些设置仍然很重要。

此致、

Joseph