[参考译文] TDA4VM：TDA4VM A72紧急

您好！

您能向我们提供有关您正在运行的内容的更多信息：

1) 1)您正在使用的 SDK 版本

2) 2)您正在使用的操作系统

3) 3)有关正在运行的应用程序的任何信息

谢谢、

埃里克

1）SDK 版本 7.3

2）OS Linux  5.4.106

• 添加 了 CPU1的调用堆栈信息：

和 CPU1的寄存器信息：

您好！

感谢您提供详细信息。 遗憾的是、这并未特别指向任何驱动程序、因此我们仍然无法隔离负责该驱动程序的模块。 请您丢失重现问题的步骤吗？

您还可以尝试使用最新的8.4 SDK 吗？ 检查此问题是否仍然存在？

导致这种情况的用例是什么？ 请以文本文件附件的形式共享完整日志。

此致、

基尔西

您好、 请更新最新的有用结果。

1、我分析  了串行端口日志的“综合”字段(综合症=bbf000000)， 我可以确认发生了解码错误(外部中止->错误-> 解码错误)

2、我捕获 了 CBASS 空错误报告寄存器、 找到了一个 CBASS 解码错误

   异常事务是读取地址 0x05e1d680的64个字节、该地址是一个没有从器件的地址

您好！

再次请求从第一次 SPL 打印开始获取完整日志。 这将帮助我们隔离导致此问题的引导阶段。 这是定制板吗？

此致、

基尔西

您好，

按如下方式记录：

e2e.ti.com/.../56045.log.txt

这是一个定制板，  请使用 SBL 引导模式。

期待您的回复、

此致。

您好、Wang、

这几乎已引导至 Linux 内核。 您能否将目标文件系统的/lib/modules 重命名为/lib/modules_bk 之类的文件

这样就不会加载任何模块。 请告诉我、如果您在那之后仍然看到该崩溃。 然后、我们可以开始隔离导致这种情况的模块。

此致、

基尔西

您好！

完成并补充问题现象的背景。

这不是器件 启动错误、这是真实车辆上的电路板稳定性测试问题。
因此、如果不加载任何模块、我就无法重现问题

您好！

这是您发现的一次性问题、还是反复出现的问题？

此问题是否仅在1个系统上出现、或者是否在多个系统上出现？

错误签名是否始终与 CBASS 解码中看到的地址相同？  

RoutID 4和大小表示其中一个 A72内核对其具有 MMU 访问权限但无效的空间进行了缓存访问。  一些驱动程序本来会对该坏范围执行 MMAP、然后进行访问。   如果不存在 MMU 表条目、则错误将是同步的、堆栈帧转储将是有效的。   如果您在该地址上使用 Lauterbach 进行 mmu.info +扫描、则可以查看是否存在表条目。  如果是这样，您应该尝试查找创建此条目的用户并调整其大小，以便它只指向有效内存。

缓存访问可能会"以"方式"发生到错误映射(映射将非法地址空洞映射为正常存储器的 mmap)或错误的驱动程序访问。  可能有些 mmap 有错误的地址、打开了地图、处理器试图从那里获取数据、认为数据可能有用。  处理器可以自由地从任何具有 ex 属性的正常存储器中自动提取...  此映射可能来自不谨慎的驱动程序、甚至是在执行不安全的 dev2mem 类型访问的某些用户空间代码中。

此致、

您好！

这是您发现的一次性问题、还是反复出现的问题？

  这是一个重复出现的问题（低频重复）
此问题是否仅在1个系统上出现、或者是否在多个系统上出现？

  --目前，我们使用的 TAD4VM 平台上的 Linux 和 SYSBIOS 一直处于停滞状态
错误签名是否始终与 CBASS 解码中看到的地址相同？

  -在一个地址范围内（内存空洞：0x5e17fff - 0x5f00000 [R5FSS1_CORE0_BTCM 的结束- R5FSS1_Core1_ATCM 的开始]）

--

关于 RoutID ：
您能否 详细解释 RoutID 或相关文档的含义？
 我们在芯片手册中找到的 RoutID 解释在这个范围（在 NAVSS0）中、您能提供 一个关于 RoutID (__LW_AT__0-255的更详细的细分
2560-3071）

" RoutID 4、大小表示其中一个 A72内核对其有 MMU 访问权限但无效的空间进行了缓存访问。   "

  --"RoutID=4且 size=64Byte"的含义表明 A72内核之一对其有 MMU 访问权限但无效的空间进行了缓存访问？   我们能否确认这是唯一的可能性？

我们使用 uDMA 构建了类似的问题、如下所示：

强制执行更改 board-support\linux-5.4.106+gitAUTOINC+023faefa70-g023faefa70\drivers\net\ethernet/ti\j721e-cpsw-virt-mac.c

此更改将触发 Sililar  CABSS_RC0_ERR [RoutID=0xA9 (也在 NAVSS0中)、size=64Byte]

因此、我了解 uDMA 将导致64字节大小的 CABSS_RC0_ERR 记录

我们需要知道每个 RoutID 指向哪个主器件？

CABSS_RC0_ERR 寄存器数据

您好、Wang、

很抱歉、我们在美国假期外出时有一些延迟。  以下是您的评论/回答/问题。

 这是一个重复出现的问题（低频重复）

• 执行任何调制频率的操作
• 这种频率是多少，每小时1次，每天1次？

• Routid 将唯一标识从给定启动器起点到路由点的路径。
• 在转储中、此路径上的 A72起始点被分配为4。
• 您的路由 ID 为0xA9 (169)的构造问题将映射到 udmap0.MEM1 169

e2e.ti.com/.../map_5F00_active_5F00_bus_5F00_routes.cmm

A72上的某些任务似乎具有写入地址空洞的权限。  此映射是偶然的、也是由于 mmap 或 ioremap 中的过映射。  有时、它会对孔洞进行非法写入、并生成此 serror。  如果在运行时您可以查看 MMU 地图(Lauterbach with MMU .list.pagetable 或 mmu.info)