您好、Xiao、

感谢您的举报。

1)您使用的是哪个版本的 Linux SDK？

2)您使用哪个版本的 ti-rpmsg-char 项目?

3)你要杀死演示的确切步骤是什么? 我们是否需要任何其他信息、以便遵循您的确切步骤并查看我们的行为？

此致、

Nick

您好、Nick：

1) SDK 版本是10.00.07.04。

2)  ti-rpmsg-char 版本为 0.6.7版本。

 am62-mcu-m4f0_0-fw 版本为  10.01.10、您可能 对此感兴趣。

3)我发送一个 kill 信号(Ctrl+c )到我的演示, 在这个演示中,我捕获这个信号,并 在发生时调用"rpmsg_char_close"。

只需确保 只有在 am62-mcu-m4f0_0-fw 停止后、  调用 rpmsg_char_close 才会阻止、 内核将显示这些行为。

我不确定以下信息是否有帮助。   当我们尝试从深度睡眠中唤醒 soc 时、我们发现了这些情况。  然后、我们发现 A53和 M4F 之间的 rpmsg 通信不能使用、 (由于我们的 MCU 代码、rpmsg 从深度睡眠中唤醒后肯定不会正常工作、我们现在也在尝试修复这些错误。) 然后,我们要停止 M4F 并手动重新启动它,在这段尝试时间内,我们发现在重启 M4F 之前,我们无法正常地在 soc 端退出我们的应用程序。 最后、 我们发现它在退出步骤中被 rpmsg_char_close 阻止。 然后、我们   在 am62xx«ti-IPC - processor-firmware/ti-linux-firmware -之前在不同位置托管的各种 TI 固件源和二进制工程的整合中央位置中将 M4F 固件替换为 am62-mcu-m4f0_0-FW。 它会发生同样的事情,然后我们检查上面找到的关于转储信息的内核消息。

如果我们忽略关闭 rpmsg dev 并 在重新启动 MCU 后再次重新打开 rpmsg、则它会正常工作、并且可以与 MCU 通信。 但是、如果我们不关闭它、我们不能确定这些问题会导致资源泄漏。

此致、

Xiao-An。

嗨、Nick  

您能给我们一些意见吗？

我也试图澄清这个问题,这里是我的评论

(一)您好、 晓安。 我很好奇,想知道什么是 RPMsg 项目为你做这个实验? 或者、您只使用默认的二进制文件" am62-mcu-m4f0_0-fw"？

(2)您的"演示"是否表示 Linux 工具"rpmsg_char_simple"？

(3)我想(猜测)我们确实按照正常步骤在进入深度睡眠模式之前关闭 A53和 R5之间的 rpmsg 服务通信。 我们是否有重新启动 rpmsg 通信的正常程序？

谢谢你。

Gibbs

另一个参考、

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/08_03_00_19/exports/docs/linux/Foundational_Components_IPC62x.html

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/10_01_00_33/exports/docs/api_guide_am62x/IPC_GUIDE.html

嗨、Gibbs：

(1)。 只需使用默认二进制文件  " am62-mcu-m4f0_0-fw"、  

(2)。  这个演示并不意味着 Linux 工具的 rpmsg_char_simple,但 我们写代码引用它,我们尝试了你在这里说的工具,它 有段故障 行为. 此外、只需确保 使用"echo stop >/sys/class/remoteproc/remoteproc0/state "停止远程内核 、当它运行到第155行时、它将在那里崩溃并报告段故障。

(3)。 在这种情况下、重新启动 RPMSG 通信无效。 通常、在重新启动演示应用和 am62-mcu-m4f0_0-fw 时、与 M4内核的通信将不间断地恢复。 我们的主要目标是解决调用 rpmsg_char_close 来结束通信时发生的阻塞/崩溃问题。 如果没有解决问题、我们在调用 rpmsg_char_close 或 rpmsg_char_exit 时必须小心、因为它们在阻塞或崩溃情况下的安全性存在不确定性。

目前、我们知道、在进入深度睡眠模式时、我们应确保在停止远程内核之前关闭 RPMSG 器件。 但是、在某些情况下、M4远程内核可能会在我们 按照"ti-rpmsg-char 库"的建议关闭之前先在其他地方停止。

此致、

Xiao-An。

您好、 Xiao-an & Gibbs、

设定期望

对此处延迟的回复表示歉意。 我几乎可以回到这个主题的工作-如果我没有在星期五再次回复,请随时 ping 该主题。

今天我与 Anshu (https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1472535/am620-q1-mcu-work-failed-when-am62x-wakeup-return-from-deep-sleep-mode)讨论了此主题、我要键入对此主题的初始响应。 在我的下一个答复中,我将尝试复制你在我身边观察到的行为。

这种情况下的预期行为是什么？  

我怀疑这是一个未经测试的用例。 请记住,我们的 RemoteProc 驱动程序的"挂起"框架仍在积极开发中。 稍后将提供更多详细信息。

当前测试的是什么？

我们已经测试： (所有 AM6x 处理器上均为 M4F、AM64x 等处理器上为 R5F、AM62A/AM62P 上为 MCU R5F)
* Linux 与远程内核之间的 RPMsg IPC  
*通过回波停止将远程内核降下
*启动远程内核并启动回波
* Linux 与远程内核之间的 RPMsg IPC

我们还测试了低功耗模式转换。

我认为我们没有经过测试
* RPMsg ,其中 Linux 端应用程序被关闭,然后备份,而不是远程内核。
*低功耗模式转换后的 RPMsg

我将与开发人员一起仔细检查当前正在测试的内容。

此致、

Nick

您好、 Nick：

 感谢您提供这些信息。  它帮助我了解更多。  您是否  在您身边复制它？

此致、

Xiao-An。

嗨、Gibbs：

>> 对于外壳 A 和 B、控制台都不挂起

>>  我认为"分段故障"是合理的、因为您已经强制关闭远程 M4内核。  (请注意、M4是 rpmsg 服务器端)

是的, 控制台不会挂起, rpmsg_char_simplex 将崩溃,我们的应用程序将在同一个 API 中挂起,我不能再同意你关于"我认为"分段故障"是合理的。

>> 但您可以再次启动远程内核(M4)、客户端测试程序可以继续运行、并且 RPMsg 正常。

 让我们做一个这样的测试,首先添加一个延迟时间(例如: 5秒)之前关闭通道,如下面的行号155:

目的是确保    在我们调用 rpmsg_char_close 来结束程序之前、远程内核(M4)有机会再次启动。

现在、

1.  在 shell A 中运行 rpmsg_char_simple,  

2.登录 shell B,"cd /sys/class/remoteproc/remoteproc0 /"

3.在 shell B 中运行"root@am62xx-LP-EVM:remoteproc0# echo stop > state && echo start > state "

4. rpmsg_char_simplet 将崩溃,报告"分段故障"

因此、  如果远程内核(M4)在之前重新启动一次而未注意到 A53、则 A53中的应用程序不知道 rpmsg 是否应关闭。

顺便说一句,如果远程核心已经重新启动,我们必须重新打开 rpmsg 才能继续与远程核心通信,如果它不应该先关闭, 这意味着我们不释放之前分配的资源,这是非常奇怪的。

你好 Nick & Gibbs :  

 现在情况如何？

BR

Xiao-An

嗨、Xiao-an

(1)"分段故障"是由于 rpmsg_char_close (rcdev)失败、因为您已经停止远程内核、我认为此 rpmsg Endpt (FD)已经不存在。

您的问题应该是：

* 当客户程序尝试执行时,为什么会出现"分段故障" rpmsg_char_close(rcdev)? 如何防止出现此错误？

*这是否意味着 M4内核停止前, M4代码应该发送一条关闭消息来通知 rpmsg_char_sample(client)? 如何实现？  

我认为 RPMsg_client 应 首先关闭 Endpt、然后 M4进入停止状态。

Sending message #70419: hello there 70419!
Received message #70419: round trip delay(usecs) = 82365
hello there 70419!
Sending message #70420: hello there 70420!
Can't write to rpmsg endpt device
: Broken pipe
send_msg failed for iteration 70420, ret = -1
Segmentation fault
root@am62xx-lp-evm:~# 

(2)当我们不调用 函数时、它是否有任何副作用  rpmsg_char_close() when M4 Core manual stop?

Gibbs

H Gibbs：

(1)：

》 当客户程序尝试执行时,为什么会出现"分段故障" rpmsg_char_close(rcdev)? 如何防止出现此错误？

是的,你是对的,"如何防止这种错误发生", 我不认为当我挂断电话,我还必须确保另一方等待我挂断前,他们做同样的.  通常情况下、每一方在自己方便的情况下挂断电话是合理的、而不会干扰对方。 换言之,当你完成时,你会挂断,当对方完成时,对方也会做同样的事情,彼此独立。

》 *这是否意味着 M4代码应发送一条关闭消息、以便在 M4内核停止之前通知 rpmsg_char_sample (client)？ 如何实现？  

我对此有不同的选项、我认为 M4 在遇到崩溃时不能确保100%发送消息、因此我认为 SOC 端应该能够  独立调用 rpmsg_char_close、而不是 出现"分段故障"、并 在内核中报告"无法处理虚拟地址000000000020处的内核 NULL 指针解除引用"。

(2)：  

》当我们不调用 函数时,它是否有任何副作用  rpmsg_char_close() when M4 Core manual stop?

停止应用程序时、它应关闭并释放之前由自身打开和分配的所有资源。 这是编码设计中的通用原则。  

嗨、Nick

根据我前面的测试步骤、

让我们首先重点讨论这个主题。

为什么会 发生"分段故障"？ 我不知道这项测试是例外从你的一方。

即使 Endpt(FD)不存在(由内核发布？)、它也应返回错误值(-1)以通知用户。

Sending message #70419: hello there 70419!
Received message #70419: round trip delay(usecs) = 82365
hello there 70419!
Sending message #70420: hello there 70420!
Can't write to rpmsg endpt device
: Broken pipe
send_msg failed for iteration 70420, ret = -1
Segmentation fault
root@am62xx-lp-evm:~# 

非常感谢

Gibbs

您好、Gibbs、

我可能需要几天时间来研究这个问题。 如果我在星期五之前没有回复、请随时 ping 通该问题。

此致、

Nick

》它应该返回错误值(-1)以通知用户。

酷！ 这是一个完美的解决方案。

BR

Xiao-An。

以确保我了解此处的用例。 是否担心 M4F 内核崩溃时系统会发生什么情况？ 如果没有、您能帮助我了解我们关注的确切情况吗？

这不是低功耗模式转换的问题、如另一个主题所述。 低功耗模式转换将在进入和退出低功耗时正确关闭并重新初始化 M4F 内核。

在常规 Linux 运行时、这也应该不会成为问题。 如果 M4F 固件由于某种原因(例如、加载不同的固件或加载更新版本的固件)而被关闭、那么 Linux 系统应设计为在关闭 M4F 内核之前正确退出用户空间应用程序。

谢谢、

Nick

嗨、Nick

讨论仅取决于 Linux (A53)检测到  M4F 崩溃、以及 Linux 应用程序如何 正确关闭 RPmsg 套接字？

此崩溃可能是三种情况

(1) M4F 保持运行、但没有对 Linux 应用程序(APP)的心跳响应、APP 将在下一步中复位 M4。 (无平稳关机)

(2) M4F 保持运行、但没有对 Linux 应用程序(APP)的心跳响应、APP 将在下一步中复位 M4。 (带平稳关断)

(3)发生错误时 M4自动复位、但应用保持从 M4接收 RPMsg 并检测到 RPmsg 套接字问题。 基本上应用应该检测到这个问题,并正确关闭 RPmsg 套接字。

根据情况(1)、应用是否可能无法使用 正常关机来重置远程内核？ 唯一的选择是通过向 M4发送软件热复位来重置远程内核。 我认为这应该是一个潜在的情况。

根据情况(2)、此条件假定"正常关机"仍然有效。 我认为没关系。

根据情况(3)、我们使用此命令"echo stop >/sys/class/remoteproc/remoteproc0/state " 自行仿真 M4复位它、Linux 应用程序保持接收 RPMsg & Detected 错误。 根据我们的字段尝试, app (rpmsg_char_sample)不 能正确关闭 rpmsg socket (rpmsg_char_close ()),它返回"segmentation fault"。 但据我所知、此函数应该返回值"-1"。

我们都知道、当您重新启动远程内核时、rpmsg 将再次工作。(例如：echo Sart >/sys/class/remoteproc/remoteproc0/state)。 因为我们使用 平稳关断来执行该测试。

但是 "分段故障"可能是"自定义"应用程序的严重问题、因为它会导致意外问题、使用户的应用程序崩溃。  我们试着澄清一下。

我们所有的讨论都基于"禁用 FFI "。

RPMsg 是否适用于 FFI 或反向 FFI？ (MCU 隔离或隔离)

如果 MCU 隔离中的 RPMsg "不工作"、则我认为无需在本主题中深入讨论。

尝试简化问题、

我们所有的讨论只是强制 M4崩溃首先,我们不需要考虑深度睡眠模式的情况。

谢谢

Gibbs

您好、Gibbs、

今晚已经很晚了,所以如果我错过了你的任何问题,请为我重新陈述,我明天会给出更多的答复。

RPMsg 是否适用于 MCU 域隔离？  

不可以。 隔离 MCU 域的过程会将所有 MCU 资源和存储器与主域访问隔离开来。 这意味着将用作 RPMsg 通信一部分的任何存储器缓冲区也将从 MCU 受到防火墙保护。

"echo > stop、echo > start"是否是模拟 M4F 内核自行复位的好方法？  

这取决于您所说的" M4F 内核正在复位自身"。

如果您能够对 M4F 进行编程以进行自我监视、并确保它不会卡在不良状态下、那么这就可以了(例如、如果等待 XX 秒来接收来自外设的数据并且数据流停止、请执行 YYY、而不是一直循环)。 在这种情况下、M4F 不需要进行下电上电、重新启动或者任何类似的操作。

如果 M4F 内核已真正锁定、我不希望它能够自行复位。 您可以对类似看门狗计时器的东西进行编程、该计时器在 M4F 内核停止检测看门狗时触发、但这样会复位整个芯片、或者向 Linux 发送中断以便 Linux 可以执行某些操作。

请记住、在使用"echo > stop、echo > start"时、您仍在使用 Linux remoteproc 驱动程序在 Linux 恢复 M4F 时正确地重新初始化 RPMsg 基础架构。

是否可以在不执行正常关机的情况下关闭内核？  

是的、您可以、但您需要修改 Linux Remoteproc 驱动程序、以便在发送正常关机消息后发生超时时、该驱动程序不再退出。 有关在进行此类修改之前需要考虑的事项的更多信息、请参见以下内容：
https://dev.ti.com/tirex/explore/node?node=A__AXsPVjrUN0EAU1ezb.8iuQ__AM62-ACADEMY__uiYMDcq__LATEST

您是否建议对 ti-rpmsg-char 进行特定修改？  

基于上述关于返回-1的讨论。 我今天没有时间真正深入这一讨论、以后需要再看一下。

此致、

Nick

嗨、Nick

非常感谢您的答复。

问题。

"rpmsg_char_close ()"返回"分割故障"而不是"值-1"

您可以告诉我们 RPMsg 的相关驱动程序代码在哪里。

现场侧或客户可能会尝试帮助您同时进行调试。

Gibbs

您好、Gibbs、

我能够复制您对分段故障的观察结果。 我仍然是导致正在发生的事情的根本原因-当 userspace 驱动程序调用以下 ioctl 函数时、它看起来是来自内核驱动程序本身的行为：

https://git.ti.com/cgit/rpmsg/ti-rpmsg-char/tree/src rpmsg_char.c 

static int _rpmsg_char_destroy_eptdev(int fd)
{
	int ret;

	ret = ioctl(fd, RPMSG_DESTROY_EPT_IOCTL, NULL);

我怀疑、当远程处理器正常关闭时、此端点(或端点的某些软件结构)已经被破坏、但在调用 ioctl 函数时、rpmsg_char 驱动程序代码不会检查资源的所有部分是否仍被分配。 因此、驱动程序试图访问 已释放的变量、并且出现分段故障。

Linux 驱动程序所有者将在下周休假。 我将花更多时间自行深入了解驱动程序、但由于这可能需要对 Linux 驱动程序代码进行一些更改、而不仅仅是用户空间代码、因此我不希望在软件所有者离职时推送修复程序。

此致、

Nick

您好：  

  这是我们的修复解决方案,你可以尝试一下,如果这不是最好的解决方法,请告诉我。

--- a/sources/meta-foxconn/recipes-kernel/linux/files/linux-6.6-foxconn/drivers/rpmsg/rpmsg_char.c
+++ b/sources/meta-foxconn/recipes-kernel/linux/files/linux-6.6-foxconn/drivers/rpmsg/rpmsg_char.c
@@ -86,6 +86,11 @@ int rpmsg_chrdev_eptdev_destroy(struct device *dev, void *data)
                        rpmsg_destroy_ept(eptdev->ept);
                eptdev->ept = NULL;
        }
+       else {
+               /* eptdev already destroyed */
+               mutex_unlock(&eptdev->ept_lock);
+               return 0;
+       }
        mutex_unlock(&eptdev->ept_lock);
 
        /* wake up any blocked readers */
@@ -191,6 +196,10 @@ static int rpmsg_eptdev_release(struct inode *inode, struct file *filp)
                        rpmsg_destroy_ept(eptdev->ept);
                eptdev->ept = NULL;
        }
+       else {
+               mutex_unlock(&eptdev->ept_lock);
+               return 0;
+       }
        mutex_unlock(&eptdev->ept_lock);
        eptdev->remote_flow_updated = false;