[参考译文] AM620-Q1：AM62x 从深度睡眠模式唤醒返回时、MCU 工作失败

嗨、Gibbs、

此系统应用是否可以选择仅 MCU 低功耗模式？ 这种低功耗模式与深度睡眠模式类似、但 MCU 内核保持在线状态、因此可以在后台运行代码。 但是、请考虑、仅 MCU 模式将因此产生更多功耗。

Unknown 说：

(1)测试结果是我们默认不能提供的结果吗？

如果在 MCU 上运行的应用在暂停之前未保存其上下文、则它将丢失所执行的任何操作。 然后恢复、它不会在停止的地方继续。

如有其他疑问、需咨询 IPC 专家和软件开发团队。 此用例尚未经过测试。

此用例

您好、Anshu

感谢您的回复和帮助。

除了 IPC 问题之外、我们已经知道我们需要保存 IPC 资源表。

但我想知道在我们的深度睡眠唤醒演示中、

AM62x 可以唤醒、我们可以看到 A53内核从深度睡眠唤醒状态很好地运行 Linux。 这是否意味着我们的演示 在暂停之前已保存 A53 Linux 上下文？

我们的演示 在暂停之前不包含 MCU (M4)保存上下文、因此 M4程序运行失败是例外情况？

Gibbs

嗨、Gibbs、

Unknown 说：

这是否意味着我们的演示 在暂停之前已保存 A53 Linux 上下文？

有。


您可以尝试以下方法来查看结果吗？

root@am62xx-evm:~# rpmsg_char_simple -r9 -n4
root@am62xx-evm:~# rtcwake -s 10 -m mem 
root@am62xx-evm:~# rpmsg_char_simple -r9 -n4

我不熟悉 IPC、但我期待 IPC 专家的反馈。

此致、

Anshu

尊敬的 Anshu：

我在使用睡眠唤醒时遇到一些问题、我们的项目想使用 MCU_GPIO 作为唤醒源。

MCU_GPIO 中断路由在 M4F 内核上配置、第一个睡眠唤醒正常。

但第二次睡眠后、尝试再次唤醒将提示"[Error] Sciclient 事件配置失败！！" Sciclient_rmIrqSetRaw 返回错误。

您能给我一些帮助吗？

此致。

您好、Walter、

您是否正在与 Gibbs 合作开展此项目？ 如果没有、请创建新的 E2E 主题、将问题分开处理。

此致、

Anshu

尊敬的 Anshu：

是的、是同一个项目

大家好、Walter

我创建了该线程、尝试强制讨论该主题、

" 为什么 MCUSS 固件在 AM62从深度睡眠模式唤醒后运行失败？ "

根据前面的讨论、我们已经知道 MCUSS (M4)在深度睡眠模式下不支持"暂停"。 这意味着您可能还会在 MCUSS 中丢失 SRAM 上的所有数据。 因此、您的问题应该是 "如何在 MCUSS 中备份 SRAM 上的数据"以及"在 AM62唤醒时将这些数据恢复到 MCUSS SRAM"。

这里有两个主题需要学习

(1)备份/恢复 Linux IPC 资源表。

 ->因为您的应用程序不允许"正常关机",所以您有这个问题  
 ->另一个原因是、您使用的是仅 MCU 模式、它将重置主域 A53

(2) 备份/恢复 M4 SRAM 上下文。 (正在学习)

我们已在该主题中开始讨论、

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1468969/am620-q1-is-reset-isolation-for-mcu-domain-is-so-called-ffi-freedom-from-interference

根据本例、  

"[错误] Sciclient 事件配置失败！！"

我认为该错误消息是从 MCU M4中转储的、对吧？

顺便说一句、我不明白"MCU_GPIO 中断路由是在 M4F 内核上配置的"的含义  

第1步、在 am62唤醒时如何重新加载远程内核？  

echo "stop" > /sys/class/remoteproc/remoteproc0/state
offline

cat /sys/class/remoteproc/remoteproc0/firmware
am62-mcu-m4f0_0-fw

echo "start" > /sys/class/remoteproc/remoteproc0/state
cat /sys/class/remoteproc/remoteproc0/state
attached

步骤2  

重新启动"rpmsg_char_simple -r9 -n4"

运行是否正常？

参考

https://dev.ti.com/tirex/explore/node?node=A__AEIJm0rwIeU.2P1OBWwlaA__AM62-ACADEMY__uiYMDcq__LATEST

https://dev.ti.com/tirex/explore/node?node=A__AXsPVjrUN0EAU1ezb.8iuQ__AM62-ACADEMY__uiYMDcq__LATEST

https://dev.ti.com/tirex/explore/node?node=A__AXsPVjrUN0EAU1ezb.8iuQ__AM62-ACADEMY__uiYMDcq__LATEST

谢谢

Gibbs

嗨、Gibbs

如果我们在 A53侧使用指令"devmem2 0x04084050 w 0x28054087"而不是

在 MCU 侧配置 GPIO 中断组、

MCU 固件可以正常休眠和唤醒。

相反、如果我们将 GPIO 中断组配置添加到 MCU 代码、

我们将收到我之前提到的错误、在"[错误] Sciclient 事件配置失败！！"处停止 唤醒。

根据该实验、我们可以确认在睡眠和唤醒时不需要备份 IPC 资源表、对吧？

简而言之、 MCU_GPIO0_20在第二次唤醒时的中断初始化失败。

您能否请求 TI 专家以获得更快速的支持？

此致

嗨、Gibbs

1.We 已在 Linux 器件树中将 mcu_gpio0和 mcu_gpio_intr 的状态设置为"reserved"。

是否需要任何其他操作？

是的、我们需要在 MCU 侧处理此 GPIO 的唤醒事件、因为此 GPIO 属于 MCU 域。

我们应何时调用 Sciclient_gpioIrqRelease 函数？

如果我们在进入睡眠模式之前释放中断、中断回调函数中的代码不会在唤醒时执行、对吧？

在过去的几天里进行了很多更新。 我会尽力回应一切。

低功耗模式转换上的电源错误

将来、如果您发现错误行为、请提供准确的步骤以及用于复制错误的确切终端输出。 我最初无法复制 沃尔特2天前的观测,因为我使用了不同的命令序列。

下面是一个"工作"顺序：

root@am62xx-lp-evm:~# head /sys/class/remoteproc/remoteproc*/name
==> /sys/class/remoteproc/remoteproc0/name <==
5000000.m4fss

==> /sys/class/remoteproc/remoteproc1/name <==
78000000.r5f
root@am62xx-lp-evm:~# rpmsg_char_simple -r9 -n1
Created endpt device rpmsg-char-9-1092, fd = 4 port = 1025
Exchanging 1 messages with rpmsg device rpmsg-char-9-1092 on rproc id 9 ...

Sending message #0: hello there 0!
Received message #0: round trip delay(usecs) = 173015
hello there 0!

Communicated 1 messages successfully on rpmsg-char-9-1092

TEST STATUS: PASSED
root@am62xx-lp-evm:~# rtcwake -s 5 -m mem
rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:01:21 1970
[   68.929148] PM: suspend entry (deep)
[   68.932955] Filesystems sync: 0.000 seconds
...
[   69.267048] Restarting tasks ... done.
[   69.274828] random: crng reseeded on system resumption
[   69.280976] k3-m4-rproc 5000000.m4fss: Core is off in resume
[   69.289073] remoteproc remoteproc0: powering up 5000000.m4fss
[   69.295976] remoteproc remoteproc0: Booting fw image am62-mcu-m4f0_0-fw, size 55016
[   69.306327] rproc-virtio rproc-virtio.5.auto: assigned reserved memory node m4f-dma-memory@9cb00000
[   69.306937] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@0/ports
[   69.317168] virtio_rpmsg_bus virtio0: rpmsg host is online
[   69.323955] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@1/ports
[   69.329558] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
[   69.331644] rproc-virtio rproc-virtio.5.auto: registered virtio0 (type 7)
[   69.331662] remoteproc remoteproc0: remote processor 5000000.m4fss is now up
[   69.339908] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@0/ports
[   69.345710] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
[   69.352326] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@1/ports
root@am62xx-lp-evm:~# [   69.385679] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@0/ports
[   69.385753] OF: graph: no port node found in /bus@f0000/dss@30200000/oldi-txes/oldi@1/ports
[   69.386433] PM: suspend exit

它继续工作了我尝试的尽可能多的周期。 只有当我在一个低功耗模式转换前禁用了 M4F 时、它才会开始中断：

root@am62xx-lp-evm:~# echo stop > /sys/class/remoteproc/remoteproc0/state
[  103.948111] remoteproc remoteproc0: stopped remote processor 5000000.m4fss

root@am62xx-lp-evm:~# rtcwake -s 5 -m mem
rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:02:26 1970
[  112.381211] PM: suspend entry (deep)
[  112.384930] Filesystems sync: 0.000 seconds
...
[  112.459856] k3-m4-rproc 5000000.m4fss: PM mbox_send_message failed: -22
[  112.459885] k3-m4-rproc 5000000.m4fss: PM: dpm_run_callback(): k3_m4_suspend_late+0x0/0x18c [ti_k3_m4_remoteproc] returns -22
[  112.459916] k3-m4-rproc 5000000.m4fss: PM: failed to suspend late: error -22
[  112.464057] PM: late suspend of devices failed
...
rtcwake: write error

这是不可预料的行为-如果内核当前未在运行、Linux 不应尝试关闭内核。 我正在跟进开发人员。 同时、您可以让 M4F 保持运行状态、直到发生低功耗模式转换、并让 Linux 处理内核的关闭和重新启动。

在 M4F 以正常关机之前、它应该释放所有资源  

这是因为 DM R5F 内核会跟踪哪个内核拥有哪些资源。 如果软件实例请求已声明的资源、则 DM 固件将拒绝所有权请求。

这意味着、如果 M4F 在没有释放资源的情况下关闭、重新启动并重新请求其资源、则请求将被拒绝、因为 DM 固件认为资源仍在使用中。 因此平稳关机非常重要、因为它允许 M4F 在关机之前释放资源。 如需更多信息、请访问 https://dev.ti.com/tirex/explore/node?node=A__AXsPVjrUN0EAU1ezb.8iuQ__AM62-ACADEMY__uiYMDcq__LATEST

此致、

Nick

我们需要您提供有关低功耗模式行为的更多信息  

我已经向开发人员确认、我观察到的行为是低功耗模式转换中的错误。 如果远程内核当前未在运行、Remoteproc 驱动程序不应尝试关闭远程内核。

您能否确认：您是否有具体的原因需要在开始低功耗模式转换之前关闭 M4F 内核？

这是我预计大多数客户代码都会运行的方式：

*如果您不对 M4F 进行编程、请在 Linux devicetre 中禁用
*如果您正在对 M4F 进行编程,请不要在 ECHO > STOP 的低功耗模式转换之前关闭内核。 保持内核运行、直到低功耗模式转换代码向 M4F 发送关断请求
*如果您需要在运行时重新启动 M4F、请执行 echo > stop、然后通过 echo > start 重新启动 M4F、然后再启动低功耗模式转换

如果有具体的原因需要在开始低功耗模式转换之前关闭 M4F、请帮助我理解这个用例。 在使用 SDK 11.0之前、修复此错误的时间不多、因此除非您有特定的近期需求、否则我们将计划解决 SDK 11.1中的错误。

此致、

Nick

您好、Nick

我心里有一个问题。

如果 M4运行程序并且有一些例外、则由该异常(问题)引起的 M4不能将 SCI 消息设置为 R5 DM 来请求释放占用资源。

在此例中、M4失去控制、我们唯一可以做的就是让内核直接复位 M4内核、而不是平稳关机。

有可能吗？

谢谢你。

Gibbs

您好、Nick、

我觉得我们谈论的不是同一个问题。

首先、我们遇到的问题应该是重复应用中断资源的问题。

M4F 内核第一次运行时应用于 GPIO 中断资源、而 A53内核没有应用。

随后、A53内核将 M4F 内核置于休眠模式、而我们没有释放中断资源(我稍后会解释原因)。

触发 GPIO 唤醒。

当 M4F 内核再次运行时、它将应用于相同的 GPIO 中断资源。 最终、Sciclient_rmIrqSetRaw 函数返回错误："[Error] Sciclient 事件配置失败！！\r\n"

  至于我们为何不在 M4F 内核处于休眠状态时释放 GPIO 中断资源、这是因为我们希望该 GPIO 可以在唤醒 AM62时触发此 GPIO 的中断、以便我们可以更改中断回调函数中某些事件的状态。

此致

您好、Gibbs、

"通用"答案(不特定于低功耗模式转换)

M4F 进入不良状态且无法响应无疑是一种可能性。 但是、这种不良状态可能由许多因素造成-例如、如果代码因等待数据来自外部设备而中断、并且外部设备已拔下插头。 在这种情况下、强制 M4F 关闭并重新启动并不能解决系统级问题、即您的数据源仍处于断开状态。 如上所述、如果在关断前未释放外设、M4F 将无法在第二次启动时请求恢复这些外设。

由客户决定对其系统究竟有何意义。 向用户界面发送通知以执行操作？ 是否启动整个系统重新引导以恢复到良好状态？ 编辑 Remoteproc 驱动程序、以便不管内核是否能够响应、它都将强制关闭内核？ 每个用例都不同。

你好、Walter、

让我们讨论一下唤醒源  

从 Linux 方面来看、听起来 TI 已验证从主域 GPIO 和 MCU 域 GPIO 唤醒、而由 Linux 将 GPIO 配置为唤醒源。

当配置 MCU 域 GPIO 的是 M4F 内核时、似乎您正在尝试从 MCU 域 GPIO 唤醒。 我不确定我们是否已经测试过此用例、我不确定 MCU+驱动程序是否支持将 GPIO 配置为低功耗唤醒源。

1) 1)当 M4F 配置 MCU 域 GPIO 时、您是否成功从 MCU 域 GPIO 唤醒？

2) 2) M4F 是否会使用其他 MCU GPIO 信号？ (也就是说、我们是否明确需要 M4F 拥有 MCU GPIO、或者是否可以将此所有权转让给 Linux？)

3) 3)如果您成功地从 MCU 域 GPIO 唤醒、则 M4F 是配置 MCU 域 GPIO 的、如果您在 M4F 代码接收到 Linux 发出的 SHUTDOWN 信号时释放了 M4F 代码中的所有外设、会发生什么情况？ 唤醒是否仍然有效？

此致、

Nick

您好、Nick、

可以成功唤醒一次。

是的、MCU 域中的 GPIO 都将由 MCU 配置和使用。

3.我不认为它会起作用,但我仍然给它一个尝试。

此致

你好、Walter、

在开始低功耗转换之前发送回波"STOP"的问题  

听起来你的用例不需要这个。 我已经提交了一份错误报告来修复我在上面观察到的行为。 同时、请勿在开始低功耗模式转换之前发送 ECHO"STOP"。

您如何将 MCU 域 GPIO 配置为唤醒源？  

我没有看到 MCU+驱动程序中用于配置唤醒源的功能。 您是否正在执行特殊操作以将 MCU GPIO 启用为唤醒源？ 我能让您共享该代码吗？

在进入低功耗模式之前释放外设的测试  

已了解由于使用其他 MCU GPIO 信号、M4F 内核需要控制 MCU GPIO。

如果在确认暂停请求之前需要用于释放外设的参考代码、请参阅
https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/ipc_rpmsg_echo.c

    gRecvTaskExitCounter++;
    if (gRecvTaskExitCounter >= IPC_RPMESSAGE_NUM_RECV_TASKS)
    {
        /* Follow the sequence for graceful shutdown for the last recv task */
        DebugP_log("[IPC RPMSG ECHO] Closing all drivers and going to WFI ... !!!\r\n");

        /* Close the drivers */
        Drivers_close();

        /* deinit system */
        System_deinit();

        if (gbShutdownRemotecoreID)
        {
            /* ACK the shutdown message */
            IpcNotify_sendMsg(gbShutdownRemotecoreID, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_SHUTDOWN_ACK, 1u);
        }
#if (__ARM_ARCH_PROFILE == 'R') ||  (__ARM_ARCH_PROFILE == 'M')
        /* For ARM R and M cores*/
        __asm__ __volatile__ ("wfi"   "\n\t": : : "memory");
#endif
#if defined(BUILD_C7X)
        asm("    IDLE");
#endif
    }
    vTaskDelete(NULL);

我不确定 Drivers_Close 和 System_deinit 测试后 MCU GPIO 模块会发生什么情况、因此我们可以一起学习。

您可以在此处找到有关挂起请求代码确切执行方式的额外分析：
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1420796/sk-am62b-p1-how-to-enable-graceful-shutdown-of-remote-cores-with-multithreading-in-freertos-threads

此致、

Nick