[参考译文] Linux/AM5728：DSP 加载故障

Gerard、您好！

我将对此进行研究。
您能否分享这是 AM57xx GP EVM 还是定制板？ 如果这是定制板、您可以共享.dts 文件和完整的引导日志(dmesg)吗？

此致、
Yordan

[引用 user="Yordan"]
您能否分享这是 AM57xx GP EVM 还是定制板？ 如果这是定制板、您可以共享.dts 文件和完整的引导日志(dmesg)吗？  [/报价]

这是基于 AM5728的定制板。 我已附加.dts 文件和完整的 bootlog。

谢谢！

e2e.ti.com/.../3731.boot_5F00_log.txt

e2e.ti.com/.../2806.am572x_2D00_custom_2D00_main.dts.txt

您好！

是否可以从设备树中删除内部 RTC。 它的条目位于 arch/arm/boot/dts/dra7.dtsi 中、这似乎与 OMAP-hwmod 驱动程序不一样...

此外、我对您的定制 DTS 中的以下条目感到非常困惑：
mmc2｛(&M)
状态="正常"；

pinctrl-names ="default"；
pinctrl-0 =<
mmc1_PINS_DEFAULT
mmc2_PINS_DEFAULT
i2c2_PINS_DEFAULT
i2c5_PINS_DEFAULT
clkout3_PINS_DEFAULT
Dcan1_PINS_DEFAULT
仿真引脚默认值(&E)
GPIO1_PINS_DEFAULT
GPIO2_PINS_DEFAULT
GPIO3_PINS_DEFAULT
GPIO4_PINS_DEFAULT
GPIO5_PINS_DEFAULT
GPIO6_PINS_DEFAULT
GPIO7_PINS_DEFAULT
GPIO8_PINS_DEFAULT
MDIO_PINS_DEFAULT
nMIN_PINS_DEFAULT
OnReset_PINS_DEFAULT
rgmii0_PINS_DEFAULT
RTC_MISC_PINS_DEFAULT
rgmii1_PINS_DEFAULT
RMII_PINS_DEFAULT
uart1_PINS_DEFAULT
uart3_PINS_DEFAULT
uart5_PINS_DEFAULT
USB1_PINS_DEFAULT
WAKEUP_PINS_DEFAULT
vin2a_iodelay_manual1_conf
rgmii0_iodelay_manual1_conf
mmc3_iodelay_manual1_conf
RMII_iodelay_manual1_conf
>；

为什么要在 mmc2驱动器中启用所有这些引脚？ 此外&RTC_MISC_PINS_DEFAULT (？)的用途是什么？ 正如我看到的、这些主要是中断、RTC 时钟和 JTAG 引脚...

此致、
Yordan

[引用用户="Yordan Kovachev"]
是否可以从设备树中删除内部 RTC。 它的条目位于 arch/arm/boot/dts/dra7.dtsi 中、这似乎与 OMAP-hwmod 驱动程序不一样...

[/报价]

已完成；我已从 dra7.dtsi 中删除内部 RTC 参考。

[引用用户="Yordan Kovachev"]
为什么要在 mmc2驱动器中启用所有这些引脚？

[/报价]

我们发现自定义电路板在断电时仍消耗电流；尝试通过器件树对此进行不同的校正、此黑客攻击最终奏效。 这可能是一个单独的讨论主题、但我很想听听您对这个问题的看法。

[引用用户="Yordan Kovachev"]
此外&RTC_MISC_PINS_DEFAULT (？)的用途是什么？ 正如我看到的、这些主要是中断、RTC 时钟和 JTAG 引脚...

[/报价]

这是引脚多路复用工具的结果；我们不使用内部 RTC、而是将其包含在 DTS 中、因为我们认为有必要使引脚具有已知状态(降低电流、防止损坏等)。 这不是真的吗？ 我们是否也应该移除该参考？  

谢谢

为了跟进、从 dra7.dtsi 文件中删除内部 RTC 引用对 DSP 加载可靠性没有影响。

期待进一步的反馈；这个问题是我发展努力的当前障碍。 我们必须能够使用不同的固件映像可靠地启动和停止 DSP。

谢谢你

您好！

我建议删除 RTC、因为您的引导日志中出现第一个内核严重错误：
[0.108632] omap_hwmod：L3_main_2、使用来自 OCP 的断开 dt 数据
[0.216626] omap_hwmod：rtcss：no dt 节点
[0.216634]------ [在此处剪切]-----
[0.216649]警告：CPU：0 PID：1 at /vobs/cra_os/Ec/System/src/open_source/linux/linux-4.4.41 +gitAUTOINC+f9f6f0db2d-gf9f6f0db2d/arch/arm/mach-omap2/omap_hwmod.c：2523 _init+0x1F4/0x418 ()
[0.216657] OMAP-hwmod：rtcss：没有 MPU 寄存器目标基址

您可以看到、它与设备 hwmod 不一致、但内核从该错误中恢复。

稍后您将：
[7.284958] mpu9250：模块来自暂存目录、质量未知、您已收到警告。
正在加载模块 bq40z60_battery
正在加载模块 FPGA_CONFIG
正在加载模块 HW_INFO
…
然后、remoteproc/rpmsg 崩溃并无法加载 DSP 二进制文件、原因是从 l4_per...

之后、我怀疑内核进入了一个相当长的循环、尝试对二进制文件执行 LAD、并且无法进入用户空间(控制台)、对吧？ 这就是为什么在我看来、您应该确保不调用 RTC 模块(除非它对您的系统设置至关重要)。 我将深入探究并使用我的任何反馈更新此内容。

[引用]我们发现、我们的定制板在断电时仍消耗电流；我们尝试通过器件树对此进行了不同的纠正、这种破解最终奏效。 这可能是一个单独的讨论主题、但我很想听听您对这个问题的看法。[引述]
关于断电后汲取电流、您还应修改您的硬件设计。

[引用]这是引脚多路复用工具的结果；我们不使用内部 RTC、而是将其包含在 DTS 中、因为我们认为有必要使引脚具有已知状态(降低电流、防止损坏等)。 这不是真的吗？ 我们是否也应该移除该参考？ [/报价]
如果未使用、则应遵循数据手册关于绑定未使用引脚的建议(第4.1.1节"未使用的焊球连接要求")、并且可以从 DTS 文件中删除这些条目。

此致、
Yordan

[引用用户="Yordan Kovachev"]
然后、remoteproc/rpmsg 崩溃并无法加载 DSP 二进制文件、原因是从 l4_per...

之后、我怀疑内核进入了一个相当长的循环、尝试对二进制文件执行 LAD、并且无法进入用户空间(控制台)、对吧？

[/报价]

不可以、系统启动后、所有功能最初都可以正常工作。 每次加载 DSP 时、都有一个自定义错误-我在一段时间前创建了一个有关此问题的单独论坛帖子、但未对原因得出结论。 通常、在我遇到此主题中描述的故障之前、我可以启动和加载/卸载 DSP 5次或更多次。

为什么远程处理器框架报告 DSP 已成功启动、但 DSP 并未真正运行？ 它感觉像是某种缓存问题。 从 eMMC 到存储器的 DSP 映像初始加载时间接近~6秒、但后续加载仅需~200毫秒。 我假设速度的提高是由于正在缓存图像。 加载之间的缓存可能会出现问题、因此我们在存储器中保留了无效的 DSP 映像、从而导致仿真器甚至无法连接？

您是否加载/卸载相同的 DSP 映像？
我将在我的 AM5728 GP EVM 上进行测试、以尝试在您一侧重新创建行为。

此致、
Yordan

是的、我正在加载/卸载相同的 DSP 映像。

谢谢你

您好、Gerard、

绑定和取消绑定之间的间隔是多少？ 如果您没有尝试过它们之间的延迟、是否可以尝试添加15秒延迟？ 这就是 bind - 15s delay - unbind - 15s - bind - 15s -等等 我们怀疑、如果问题发布得太近、则会出现不同步的情况。

雷克斯

当前，解除绑定和绑定之间有1秒的延迟。 我用7、15和20秒的时间进行了实验、但运气不好。

我们系统的更多背景信息：

• DSP 在运行时与 FPGA 进行通信；FPGA 通过 GPMC 进行配置、然后通过 PCIe 传输数据
• FPGA 使用 GPIO 向 DSP 触发中断
• 在这些测试中、FPGA 与 DSP 同时进行上电

以下是使用持续加载/卸载 DSP 的脚本进行测试后的一些新数据：

• 为 AM5728EVM 生成了测试 DSP 构建-未重新创建问题(EVM 上显然没有 FPGA)
• 为我们的定制硬件生成了测试 DSP 构建-未重新创建问题(未使用 FPGA)
• 生产 DSP + FPGA 构建环路测试失败
• 仅生产 DSP (FPGA 保持禁用状态)构建环路测试成功

因此、与 DSP-FPGA 交互的原因似乎是后续 DSP 加载失败的原因。 我最好的猜测是 DSP/FPGA 与之交互的外设在电源周期内干扰 DSP。 对于此动态电源循环使用案例、是否有最佳实践？ 例如、是否要求 DSP 在关闭之前禁用所有外设/中断？ 人们可能会认为怠惰路径-不禁用外设/中断-是可以接受的、因为我们正在对处理器进行电源循环。 这也许不是一个安全的假设。

谢谢

您好！

我想到的另一件事。 您在哪个 OPP 上运行 AM57xx 器件？
您可以尝试将其设置为 OPP_HIGH 吗？

此致、
Yordan

我假设我们处于任何 OPP 为默认值、因为我没有更改它。

我找到了一篇您链接 processors.wiki.ti.com/.../Sitara_Linux_Training:_Power_Management 的文章、 但我看不到引用的某些 sysfs 节点能够确定 OPP/change the OPP。

Gerard

Gerard、您好！

默认情况下、运行未修改的 SDK03.03.00.04 (内核4.4.41)的 AM57xx GP EVM 在1GHz 下工作、这是 cpufreq 中可用频率中的最低频率：
root@am57xx-evm：/sys/class/regulator/regulator.3 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
1000000 1176000 1500000
这对应于 OPP_NOM、请参阅 dra7.dtsi：
opp_nom@1000000000｛
opp-Hz =/bits/64 <1000000000>；
op-microvolt =<1060000 850000 1150000>；
opp-supported-HW =<0xFF 0x01>；
opp-suspend；
}；

您应将调速器更改为 userspace：
root@am57xx-EVM~# echo userspace >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
并选择最高 CPU 频率1.5GHz：
root@am57xx-EVM：~# echo 1500000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

另一个选项是修改 dra7.dtsi 中的 opp 表。

如果您在构建时启用了 cpufreq 驱动程序、您应该在内核中包含这些 sysfs 条目。

此致、
Yordan

此外、我还设法在 GP EVM 上获得 DPS 负载故障、但正如 Rex 提到的：
如果我在 bind->unbind 之间使用较短的间隔，系统将无法加载 DSP 固件。 但是、如果我使用下面的脚本：
！/bin/sh
CD /sys/bus/platform/drivers/omap-rproc
echo 40800000.dsp >解除绑定
睡眠5.
LN -s /lib/firmware/dra7-dsp1-fw.xe66.dspdce-fw /lib/firmware/dra7-dsp1_new.xe66
echo 40800000.dsp >绑定
睡眠15.
echo 40800000.dsp >解除绑定
睡眠5.
LN -s /lib/firmware/dra7-dsp1-fw.xe66.dspdce-fw /lib/firmware/dra7-dsp1-fw.xe66
echo 40800000.dsp >绑定
睡眠15.

在 bind->unbind 之间休眠20秒，我在加载和卸载固件时没有任何问题。

此致、
Yordan

您好！

一些其他信息、基于您在第一封邮件中共享的日志。

该错误源于名称服务器守护程序(位于以下位置的源代码： git.ti.com/.../demon)，特别是以下部分：

  /*将超时设置为等待：*/

  tV.tV_sec = 0；

  tV.tV_usec =名称服务器_get_timeout；

  /*创建请求消息并发送到远程：*/

  clusterid = ProcID - MultiProc_getBaseIdOfCluster()；

  sock = nameserver_module->comm[clusterid].sendSock；

  if (sock == INVALIDSOCKET)｛

    log1 ("nameserver_getRemote：没有到处理器%d\n"的套接字连接、

      ProcID)；

    status = nameserver_E_resource；

    转到出口；

  ｝

此致、  
Yordan

谢谢您；我将使用 cpufreq 驱动程序重建我的内核、因为这必须解释为什么我没有看到 Wiki 列出的所有节点以及上面列出的所有节点。 尝试其他 OPP 设置后、我将再次报告。

谢谢

问题是、DSP 启动/停止之间有这么长的延迟对我们来说是一个阻碍因素。 它需要在20秒内发生-理想情况下只需几秒。

是否有根本原因可以解决(内核修补程序)以解决即使您现在重新创建的快速启动/停止问题？

谢谢

Gerard、

如果在您的情况下使用较长的延迟可以可靠地工作、那么您可以开始对其进行修整、以找到适合您的硬件情况的最短延迟。 由于 Yordan 不能复制您的所有客户硬件和外部设备、因此可能很难找到要使用的准确数字、例如、在您的终端上进行试验。

一旦您确认长延迟对您有效、这将是我们在调试过程中要考虑的一个大数据点。 请在测试完成后告知我们、以便我们一起朝着正确的方向前进。

此致、
RandyP

[引用 user="Yordan Kovachev"]Hi Gerard、

如果您在构建时启用了 cpufreq 驱动程序、您应该在内核中包含这些 sysfs 条目。  

[/报价]

我已启用 cpufreq 驱动程序、但仍看不到节点。 我确实注意到这在启动时发生：

[0.00178]/cpus/cpu@0缺少时钟频率属性
[0.001733]/cpus/cpu@1缺少时钟频率属性

对于 CPU 0和 CPU 1，此属性是否应分别添加到 dra7.dtsi 和 dra74x.dtsi 中？

谢谢

Gerard、您好！

您的 DTS 中是否有相关的 opp 设置：
在 beagle-x15-common.dtsi 中、您应该具有 oppdm_MPU/dspeve/GPU/ivahd/core 电源：
oppdm_MPU｛(&O)
VDD-SUPPLY =<&S；
}；

oppdm_dspve｛(&O)
VDD-SUPPLY =<&S s45_reg>；
}；

oppdm_GPU｛(&O)
VDD-SUPPLY =<&S s45_reg>；
}；

oppdm_ivahd｛(&O)
VDD-SUPPLY =<&S s45_reg>；
}；

oppdm_core｛(&O)
VDD-SUPPLY =<&S；
}；

中应存在这些参数
i2c1｛(&I)
状态="正常"；
时钟频率=<400000>；

tps659038：tps659038@58｛
…

此外、您还应在 dra7.dtsi 中定义 opp 表：
CPU0_opp_table：opp_table0｛

在 dra74x.dtsi 中被调用：
CPU@1｛
DEVICE_TYPE ="CPU"；
兼容="arm、cortex-a15"；
reg =<1>；
运行点-v2 =<&CPU0_opp_table>；
}；

您的 DTS 文件中是否有这些文件？

此致、
Yordan

[引用 user="Yordan Kovachev"]Hi Gerard、

您的 DTS 文件中是否有这些文件？

[/报价]

是的；我已确认您在相关 DTS 文件中列出了所有属性。

谢谢、

Gerard

此外、下面是我已启用的所有与 cpufreq 相关的内核选项：
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_common=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_Details=y
未设置# CONFIG_CPU_FREQ_DEFAULT_GOV_performance
未设置# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE
未设置# CONFIG_CPU_FREQ_DEFAULT_GOV_userspace
CONFIG_CPU_FREQ_DEFAULT_GOV_OnDemand=y
未设置# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSTICATION
CONFIG_CPU_FREQ_GOV_performance=y
CONFIG_CPU_FREQ_GOV_POWERSAVe=y
CONFIG_CPU_FREQ_GOV_userspace=y
CONFIG_CPU_FREQ_GOV_OnDemand=y
CONFIG_CPU_FREQ_GOV_保守= y

编号
#个 CPU 频率调节驱动器
编号
CONFIG_cpufreq_DT=y
未设置# CONFIG_ARM_BIG_BIT_cpufreq
未设置# CONFIG_ARM_Kirkwood_cpufreq
CONFIG_ARM_OMAP2PLUS_cpufreq=y
CONFIG_ARM_TI_cpufreq=y

[引用 user="Yordan Kovachev"]此外、我还成功地在 GP EVM 上获得了 DPS 负载故障、但正如 Rex 提到的：
如果我在 bind->unbind 之间使用较短的间隔，系统将无法加载 DSP 固件。 但是、如果我使用下面的脚本：
！/bin/sh
CD /sys/bus/platform/drivers/omap-rproc
echo 40800000.dsp >解除绑定
睡眠5.
LN -s /lib/firmware/dra7-dsp1-fw.xe66.dspdce-fw /lib/firmware/dra7-dsp1_new.xe66
echo 40800000.dsp >绑定
睡眠15.
echo 40800000.dsp >解除绑定
睡眠5.
LN -s /lib/firmware/dra7-dsp1-fw.xe66.dspdce-fw /lib/firmware/dra7-dsp1-fw.xe66
echo 40800000.dsp >绑定
睡眠15.

[/报价]

我想报告这个较长的延迟测试：即使延迟与您的延迟相匹配、我也最终会遇到负载故障。

AM572x TRM 的第5.3.4.2节介绍了 C66x 的断电序列。 有一个指向主机(在我们的情况下是 ARM)发送到 DSP 的"断电"消息的引用。 是否有关于此预期过程和/或说明 DSP 在收到此"断电"消息时应执行的操作的任何示例代码的更多详细信息？

谢谢、
Gerard

Gerard、您好！

很抱歉耽误你的回答。

[引用]是否有关于此预期过程和/或说明 DSP 在收到此"断电"消息时应执行的操作的任何示例代码的更多详细信息？[/引用]

我不知道任何详细介绍这一程序的公开文件。 至于示例代码、您可以查看内核远程驱动程序：
drivers/remoteproc/repoteproc_core.c -> rproc_shutdown ()
drivers/remoteproc/OMA_remoteproc.c

这些是加载/卸载 DSP 固件的功能。

因为您的 sysfs 中没有 cpufreq。 我还找不到有效的解释。 我正在处理这个问题。

此致、
Yordan

[引用用户="Yordan Kovachev"]

我不知道任何详细介绍这一程序的公开文件。 至于示例代码、您可以查看内核远程驱动程序：
drivers/remoteproc/repoteproc_core.c -> rproc_shutdown ()
drivers/remoteproc/OMA_remoteproc.c

这些是加载/卸载 DSP 固件的功能。  

[/报价]

我更关心 DSP 需要做什么。 TRM 引用了在 DSP 端的软件中实现的关断过程。 假设此 DSP SW 过程的目的是将事情保持在良好状态、以便在下次上电时不会出现问题。

谢谢

Gerard、您好！

我找到了一些有关 DSP 断电的文档。 AM572x 中集成的 corepack 具有其自己的用户指南：
www.ti.com/.../sprugw0c.pdf
请参阅第12章"断电控制器"、特别是第12.2.5节 C66x CorePac 断电和12.2.6其他断电。
查看 C66x DSP 和指令集参考指南(SPRUGH7)(www.ti.com/.../sprugh7.pdf)中描述的 IDLE 指令也很有用、请参阅第3.8.12.5节 IDLE、4.158 IDLE 和 Figure H-2 NOP 和 IDLE 指令格式

实施的软件程序应符合上述说明。

此致、
Yordan

感谢您的介绍、Yordan。

下面是我们当前为在 DSP 启动并运行后关闭它所做的工作：

1. 主机(ARM)向 DSP 发送自定义关断消息(通过 MessageQ)
2. DSP 调用 PCIe 解构器(它本质上调用 PCIe_close())
3. DSP 向主机(ARM)发送 ACK 消息(通过 MessageQ)
4. DSP 休眠1毫秒以确保 EC 获得 ACK 消息
5. 常规取消初始化
   1. 从内部消息和计时器中分离
   2. 调用 MessageQ_delete()
   3. 调用 IPC_DET()
   4. 删除计时器
   5. 删除其他类
   6. 删除 McSpi 接口-为物理 SPI 接口调用 SPI_Close

6. 调用库函数 PMLIBCpuModePrepare (PMHAL_PRCM_MOD_DSP1、PMLIB_IDLE_CPU_MODE_OFF)；  

   我相信这将实现 TMS320C66x DSP CorePac 用户指南第12.2.5节中提供的列表中的第1步。  由于 DSP 将由 ARM 进行下电上电并复位、由于上面的步骤4禁用了所有中断、步骤2未被专门执行。  

7. 调用库函数 PMLIBCpuIdle (PMHAL_PRCM_PD_State_off)；

   我认为这是执行12.2.5的第3步。  我通过单步执行代码来确认这一点、IDLE 本来已经被执行、但是当我单步执行 IDLE 命令时、DSP 进入复位状态、并且调试器断开连接、我认为这是预期的行为。

但是、我们最终仍然无法加载 DSP。 我们可以做些什么来改进此过程？

谢谢

您好！

只是想让您知道我们正在研究这个问题。

此致、
Yordan

您好、Gerard、

DSP 下载失败时是否有跟踪日志？ 它应该位于/sys/kernel/debug/remoteproc/remoteproc #/trace0中、其中#是从0开始的内核 ID。

雷克斯

您好、Gerard、

我们看到失败原因有两种可能、不确定您以前是否曾研究过它们：
a)当 GPIO 外设因某种原因断电时、DSP 正在写入 GPIO 寄存器。 您能否确认 GPIO 外设是否也在加电和断电？
b)当 FPGA PCIe 断开连接时、DSP 通过 PCIe 写入 FPGA。 这可能看起来是最可能的情形。 为避免这种情况、是否可以确保在关闭 DSP 和 FPGA 电源之前完全停止对 DSP 的 PCIe 访问？ (这还包括 DSP 不应响应任何 GPIO 中断、这可能会导致任何 PCIe 事务)

雷克斯

尊敬的 Rex：

我正在处理 Gerard 发布的问题的 DSP 方面。  我们希望在您的回复中进一步澄清问题。

至于跟踪日志记录、我是否希望在 DSP 中的.cfg 文件中添加特定的内容以获取您要查找的日志记录。  由于我们在 DSP 中对某些应用面临 MIPS 挑战、因此我可能启用了极少的日志记录。

有关 GPIO 外设的问题。  您是指关闭 AM5728 SOC 中的 GPIO 外设、还是 GPIO 所连接的定制板上的硬件？

关于 PCIe 事务的问题、我们认为、由于 FPGA 从未使用任务代码激活、并且由于 DSP 处于空闲指令、PCIe 也应处于空闲状态。  但是、我注意到、尽管我们调用了 PCIe_close 函数、但该函数可能不会真正关闭 AM5728中的 PCIe 硬件。  我们是否应该采取额外的硬件/寄存器操作来确保 PCIe 在5728中真正空闲？

感谢您的帮助、

Chris

您好、Chris、

您是否看到当前跟踪和 Linux dmesg 中显示的任何内容？ 无论 DSP 日志如何、它都显示在 AMR 端的跟踪文件中。 出于调试目的、是否可以启用某些 DSP 日志？

我记得、GPIO 被 FPGA 用作 DSP 的中断。 只是希望确保不会处理任何进入的中断。

成功的测试用例之一是禁用 FPGA。 禁用 FPGA 是否意味着关闭电源？ 如果加电但未配置/枚举 PCIe、是否会有所不同？

除了 PHY 电源控制外、AM572x 上的 PCIe 似乎不能断电。 由于我们无法重现此问题、因此我们无法提供更多有关问题根源的建议。

雷克斯

Rex、

当系统启动并运行时，我在 trace0日志中看到这一点：

[0.000]     0x8000000处20个资源条目

Gerard 将不得不评论失败后出现的其他事项。  是的、对于这些测试、我们应该能够启用您建议的任何日志记录。

是的、GPIO 用作从 FPGA 到 DSP 的中断。  但是，我们不认为 FPGA 应该生成任何中断，作为 DSP 关闭过程的一部分，我调用 Hwip_disable()；。  为了进行良好的测量，我刚刚将 GPIO_disableInt()添加到 断电时调用的 GPIO 驱动程序析构函数中。  以前、由于驱动程序代码中未提供关断 API、GPIO 驱动程序析构函数为空。

Gerard 需要对"FPGA Disabled (禁用 FPGA)"的含义进行评论。

我们正在进行基于 EVM 的设置、以帮助重现问题、但我们需要将移植回 EVM 并删除敏感代码、因此我们需要在几天内才能发送任何内容。

谢谢、

Chris

您好、Chris、

对于 GPIO 中断、我们只需确保将其涵盖在内、并不意味着它是原因之一。 使用基于 EVM 的设置重现问题、是否仍需要 FPGA？ 我们需要一种在 TI 重现的方法来对其进行调试。 对于连接到 AM572x EVM 的任何 PCIe 终端设备、是否会进行类似的设置、并使用您的 DSP 代码枚举 PCIe？ 我假设它是 DSP 初始化 PCIe、因为它是 FPGA 数据的使用方、反之亦然。 如果这与此类似、那么我可以禁用内核代码中的 PCIe 枚举、以查看我们是否可以在 TI 端重现它。

雷克斯

[引用 user="Rex Chang"]
您是否看到当前跟踪和 Linux dmesg 中显示的任何内容？  

[/报价]

这是我在这个线程上的原始帖子；dmesg 中的所有内容看起来都正常-我在下面包括了与 Remoteproc 相关的输出。 但是、IPC 守护程序在打印出没有与 DSP 的连接时提示存在问题。

远程处理器启动看起来正常：

[417.33373737] OMAP-rproc 40800000.dsp：分配的保留存储器节点 dsp1_cma@e0000000
[417.341684] remoteproc2：提供40800000.DSP
[417.346584] remoteproc2：注意：remoteproc 仍在开发中并被视为实验。
[417.355991] remoteproc2：二进制格式尚未最终确定、并且尚未保证向后兼容性。
[417.384513] remoteproc2：为40800000.DSP 加电
[417.389437] remoteproc2：引导 FW 映像 dra7-dsp1-fw.xe66、大小为15350528
[417.404130] OMAP-hwmod：mu0_dsp1：_wait_target_disable 失败
[417.410032] OMAP-iommu 40d01000.MMU：40d01000.MMU：版本3.0
[417.415976] OMAP-iommu 40d020.MMU：40d020.MMU：版本3.0
[417.498260] remoteproc2：远程处理器40800000.DSP 现已启动
[417.50494] virtio_rpmsg_bus virtio0：rpmsg 主机处于联机状态
[417.510484] remoteproc2：registered virtio0 (类型7)

IPC 守护程序日志显示了一些问题(在本例中没有与 DSP1的连接-处理器4 -我尝试启动的内容)：

[835.080166]正在检索命令...
[836.080428] LAD 名称服务器_GETUINT32：调用 nameserver_getUInt32 (0x304d0、'SP1：MSGQ：01')...
[836.080474] nameserver_getLocal：未找到输入密钥：'SP1：MSGQ：01'！
[836.080493] nameserver_getRemote：没有到处理器1的套接字连接
[836.08051] nameserver_getRemote：没有到处理器2的套接字连接
[836.080526] nameserver_getRemote：通过 sock 发送请求：5.
[836.080542] nameserver_getRemote：从 ProcID 3、MessageQ：DSP1：MSGQ：01请求
[836.080574] nameserver_getRemote：等待 waitFd：4.
[836.080663]名称服务器：从 select 返回()
[836.080685]名称服务器：侦听器从 sock 获得名称服务器消息：6！
[836.080709] listener_CB：Recvfrom socket：FD：6.
[836.080726]接收 ns msg：nbytes：484、来自 addr：61、来自 vproc：3.
[836.080742]名称服务器回复：InstanceName：MessageQ、name：DSP1：MSGQ：01、value：0x13a8e
[836.080767] nameserver：Waiting for unblockFd：2，SOCKS：maxfd：6.
[836.08080802] nameserver_getRemote：找不到 MessageQ：DSP1：MSGQ：01的值。
[836.080822] nameserver_getRemote：没有到处理器4的套接字连接
[836.080837]值= 0x80
[836.080852]状态=-5
[836.080867]完成

[引用 user="Rex Chang"]

成功的测试用例之一是禁用 FPGA。 禁用 FPGA 是否意味着关闭电源？ 如果加电但未配置/枚举 PCIe、是否会有所不同？  

[/报价]

是的、FPGA 本来会断电。 我们进行了一项测试、FPGA 已通电、但 PCIe 未执行任何操作、仍然失败。