[参考译文] TDA4VM：无法访问 PCIe2_DAT0

您好、Thomas：

免责声明：TI 不提供 PCIe RTOS 驱动程序的软件支持、因此 R5F 上不支持 PCIe。  TI 仅支持托管在 A72内核上的 Linux 驱动程序。 因此,虽然你正在尝试的不是一个完整的驱动器实现,它是未知的领域。  

您刚才提到 U-Boot 在发挥作用、但是在使用 MCU2-0和 A72两者都访问 PCIe 存储器空间以窥视存储器的情况下、什么时候会访问该 PCIe 存储器空间？ 它是在 Linux 启动并初始化 PCIe 模块后在两种情况下访问、还是在进入 Linux 之前在 U-Boot 中停止？

此致、

Takuma

你好、Takuma、

感谢您的答复。 是的、我知道这一点。 我不要求支持如何正确配置 PCIe 模块、并且在两个 PCI 模块之间建立了 PCI 链路(这在工作中)。

我认为任何内核(A72、MCU2-0)和 PCIe2_DAT0之间的路径上都存在一些问题。 我需要支持。

要回答您的问题：在所有三种情况下、会发生以下情况：

1. u-boot 正在引导
2. u-boot 加载 MCU2-0固件并从中启动 MCU2-0
3.此时,A72根本不做任何事情。 未引导 Linux。 它只是在 u-boot 环境中空闲。
4. MCU2-0固件对串行器/解串器和 PCIe 模块进行初始化和配置
5. MCU2-0固件成功建立 PCIe 模块与另一个板的数据链路。 (LTSSM 达到 L0)
6.此时、我开始尝试通过 CCS 存储器浏览器访问 PCIe2_DAT0、如我的第一篇文章所述。

作为我的3。 第一篇文章中的场景显示、我可以使用内存浏览器(连接到 A72)在 PCIe2_DAT0上成功读取/写入、但使用" Physical memory (物理内存)视图 "。 因此、这不是 PCI 模块配置的一般问题。

因此、我认为它在某种程度上是内核和 PCIe2_DAT0之间的路径。

我不是 TDA4专家、但我想是这样

1. R5的 MPU 配置
2. Rat 配置 R5
3.防火墙配置
4. QoS 配置

潜在问题。 甚至更多的预言,我只是不知道。

我的快速测试是简单地使用 A72进行 PCIe2_DAT0访问、这个测试具有将1和2从该列表中删除的背景。
希望大家能帮我解决这个问题。 我也希望不会出现普遍的"芯片问题"、从而阻止访问。
谢谢、此致、
Thomas

您好、Thomas：

对于 Linux、有一种机制来定义内存空间的某些标志、就像本文档中那样： https://elinux.org/Device_Tree_Usage 

我不知道如何为您的代码处理这一情况、但这可能缺失了？

此致、

Takuma

你好、Takuma、

您的屏幕截图中是 phy.high 位吗？ 它们由 PCI 驱动程序处理、从我的角度来看、PCI 模块已正确配置。

我们在同一个页面上吗？ Linux 如何使用此信息来配置 QoS (TDA4 TRM SPRUIL1B 的第3.3.2章)或防火墙(第3.3.4章/ 3.4相同文档)、这可能会影响从 MCU2_0到 PCIe2_DAT0的数据访问？

此致、
Thomas

您好、Thomas：

是的、主要有 phys.hi 位标志、如可预取和空间码、因为这会影响缓存。 我有一个怀疑是高速缓存中的数据未失效的问题。 如果物理存储器由于外部器件写入数据而发生了变化、但内核无法读取正确的值、则可能是由高速缓存一致性问题引起的。

至于防火墙、除非器件是明确启用了 FS 防火墙的 HS-SoC (高安全性-现场安全)器件、否则不用担心。 大多数用户使用 禁用了所有防火墙的通用 GP 器件、或未强制实施安全性的 FS 器件。 如果您使用的是 FS 已被密钥烧坏的 HS-防火墙、而这正是您担心防火墙的原因、那么我们可以继续采用这种方法。

至于 QoS、这主要用于为某些数据事务提供优先级、当整个 SoC 上有大量活动并导致显示器/GPU 等一些实时数据事务由于 DDR 带宽问题等原因而出现毛刺脉冲时非常有用。 它还会影响 ASEL、后者会影响高速缓存一致性。

此致、

Takuma

您好、Thomas：

[报价 userid="351163" url="~/support/processors-group/processors/f/processors-forum/1446155/tda4vm-can-not-access-pcie2_dat0/5553150 #5553150"]

我在错误的道路上吗？

[报价]

不,我不这么认为。 但是、问题的描述方式(又称物理内存有实际数据、但内核无法访问数据) 与高速缓存问题非常相似。  

[报价 userid="351163" url="~/support/processors-group/processors/f/processors-forum/1446155/tda4vm-can-not-access-pcie2_dat0/5553150 #5553150"]

可以帮助我吗？

[报价]

不适用于在日志记录中使用防火墙。 防火墙仅在启用时发送异常日志。

[报价 userid="351163" url="~/support/processors-group/processors/f/processors-forum/1446155/tda4vm-can-not-access-pcie2_dat0/5553150 #5553150"]

"你以为你赢了吗?

[报价]

也许吧。 我不知道 QoS 会以这种方式产生影响、但我知道在较新的 SDK 版本中、被上一个问题触及的 QoS 寄存器正在进行修改、以解决 DDR 与显示流水线之间的带宽问题。 您可以尝试对 NAVSS 北桥寄存器应用补丁作为实验、因为这看起来像是过去的问题、是由于设置了实时寄存器导致无法进行访问：

From e6fa2b99343909adb60d9eaa766afc36d3ce3654 Mon Sep 17 00:00:00 2001
From: Neha Malcom Francis <n-francis@ti.com>
Date: Tue, 18 Jul 2023 13:21:00 +0530
Subject: [PATCH] arm: mach-k3: j721e: Drop write to NB0 threadmap

Drop write to NAVSS0 NB0 threadmap register. Writing to bit 1 of this
register makes DRU registers inaccessible. Capture/display paths are not
affected.

Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
 arch/arm/mach-k3/j721e_init.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index c3371d4969..ec0d976691 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -196,7 +196,6 @@ void do_dt_magic(void)
 void setup_navss_nb(void)
 {
         /* Map orderid 8-15 to VBUSM.C thread 2 (real-time traffic) */
-        writel(2, NAVSS0_NBSS_NB0_CFG_NB_THREADMAP);
         writel(2, NAVSS0_NBSS_NB1_CFG_NB_THREADMAP);
 }
 
-- 
2.34.1

此致、

Takuma

你好、Takuma、

Unknown 说：

不能使用防火墙进行日志记录。 防火墙仅在启用时发出异常日志。

我的想法是、使用防火墙作为"记录设备"。 例如、要启用 PCIe2_DAT0防火墙、要验证 MCU2_0执行读取访问时是否有任何活动、或查看 A72的读取访问正常/不起作用时的差异。

然后"向后"按照从 MCU2_0到 PCIe2_DAT0的"访问路径"来缩小问题范围。
这是我的最后一个想法,我有一个脚走进门,以某种方式诊断问题。

关于补丁、我今天将进行尝试并向您反馈结果。

更新：我检查了补丁。

线路上
 writel (2、NAVSS0_NBSS_NB0_CFG_NB_THREADMAP)；
已经在 u-boot 中删除。

此致、
Thomas

您好、Thomas：

您是否还可以确认是否删除了 NB1线路？ 根据 TRM、我看到 NB0适用于 MSMC0、NB1适用于 DDR。

至于防火墙,我不是太精明在这个领域。 但是,我确实看到你已经为这个打开了一个单独的线程,我的一位在这个领域更有知识的同事已经收到通知(虽然,他的答复会有一个延迟,因为他不在办公室): https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1449673/tda4vm-inconsistency-with-ti_sci-firewall-configuration?tisearch=e2e-sitesearch&keymatch=firewall#

根据该其他论坛主题、我假设您可能找到了适用于防火墙的 TISCI 文档、但在此处链接以防万一： https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/firewall_api.html

此致、

Takuma

您好、Thomas：

Unknown 说：

未删除 NB1行。 为了完整起见、我将整个 j721e_init.c 文件粘贴到此处：
[报价]

谢谢、我会查看这篇文章。

Unknown 说：

未删除 NB1行。 为了完整起见、我将整个 j721e_init.c 文件粘贴到此处：
[报价]

SoC 内部互连时、R5FSS 应该能够根据下图访问 PCIe。

但是、作为一个我将再次重申的免责声明、使用 RTOS 的 PCIe (也意味着通过 R5F MCU 的 PCIe)尚未经过验证、我们也没有计划在 SDK 中启用此功能。

此致、

Takuma

[/quote]

你好、Takuma、

我们又前进了一步。

在我注释/删除该行之后

       setup_main_r5f_qos ()；

(我之前粘贴了2个帖子的 j721e_init.c 中的第567行)

MCU2_0成功读取/写入 PCIe2_DAT0。

事实证明、我对 QoS 的"直觉"在某种程度上是正确的。
我们在 TDA4的 TRM 和 AM65的 TRM 中进行了搜索、以了解这种特定的 QoS 配置意味着什么、以及它导致此类错误的原因。 而没有成功。

您能否帮助我们了解 TI 的此特定 QoS 配置功能、以及为何它会阻止 MCU2_0 (和潜在的其他内核)无法访问 PCIe2_DAT0？

也许您可以把我重定向到您的一位同事、如果需要、他在 TDA4这部分方面有更丰富的经验？

谢谢大家、新年快乐！

Thomas

你好、Takuma、

感谢您提供的信息、听起来合乎逻辑。

我没有时间深入探究整个 VirtSS,似乎包含 PVU/PART+PVU ,而且我还没有欠下, 在 PVU 或 PAT 开始发挥作用。

-"谁"正在利用这些翻译单元?

-他们应该/应该在哪些环境中使用?

我们现在决定作为权变措施,我们只是在 uboot 中注释整个 setup_main_r5f_qos ()。

谢谢、此致、
Thomas