This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] PROCESSOR-SDK-AM64X:Remoteproc 无法在关闭后为远程处理器(R50-0)供电

Guru**** 2477435 points
Other Parts Discussed in Thread: TMDS64EVM

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1461816/processor-sdk-am64x-remoteproc-not-able-to-power-up-the-remote-processor-r50-0-after-shutdown

器件型号:PROCESSOR-SDK-AM64X
主题中讨论的其他器件:TMDS64EVM

工具与软件:

尊敬的 TI 员工:

我们具有以下设置:

0)  TMDS64EVM 作为硬件

1) Processor SDK 10.00.07.04 + 相应的 Yocto for Linux 内核版本6.6.32-ti-01287

2) R5-0-0和 R5-0-1在拆分模式下运行

3)自定义固件,从 SRAM+TMC 在 R5-0-0上运行,带有 FreeRTOS

4)实现 RPMSG、分别在 Linux 和 R5之间实现 IPC

5)实现(至少高达90 %)平稳关机,即捕获来自 Linux 的"关机"信号,系统未初始化, 确认被发送回 Linux

下面的代码样片:

* IPC 回调

    void m_cb(uint32_t remoteCoreId, uint16_t clientId, uint32_t msgValue, [[maybe_unused]]int32_t crcStatus, [[maybe_unused]] void *args)
    {
        IpcManager* mgr = static_cast<IpcManager*>(args);
        if (clientId == (uint16_t)IPC::CID::IPC_NOTIFY_CLIENT_ID_RP_MBOX)
        {
            if (msgValue == (uint32_t)IPC::MsgType::IPC_NOTIFY_RP_MBOX_SHUTDOWN)
            {
                mgr->Shutdown(remoteCoreId);
            }
        }
    }

*回复

 void doShutdown()
    {
        //ACK the suspend message
        IpcNotify_sendMsg(m_shutdownCoreId, (uint16_t)CID::IPC_NOTIFY_CLIENT_ID_RP_MBOX, (uint32_t)MsgType::IPC_NOTIFY_RP_MBOX_SHUTDOWN_ACK, 1u);

        Board_driversClose();
        Drivers_close();

        //Disable interrupts
        HwiP_disable();

        /* For ARM R and M cores*/
        __asm__ __volatile__ ("wfi"   "\n\t": : : "memory");
    }

我们面临的问题是:

显然,平稳关机运行正常,因为我们在  dmesg 输出中看到,remoteproc 关机不会抱怨超时:

奇怪的是、我们必须先停止 R5-0-1 (78200000.r5f)、然后再停止  R5-0-0 (78000000.r5f)、否则驾驶员会抱怨。 无论如何,这不是(直接)的问题。 问题是、停止 R5-0-0后、我们无法再次启动它。 不仅如此、整个电路板还挂起。 这个问题显然出现在一个很早的阶段、因为 R5-0-0不能脱离复位、在  dmesg 中只有2行:

...然后整个系统挂起。

问题:

  • 这是否正常、R5-0-1必须首先停止?
  • 是否是正确的停止/启动程序?
  • 是否还必须执行其他操作才能启用重复的 rproc FW 加载和引导?  
  • 当然,为什么 remoteproc 驱动程序无法加载相同的固件两次,更不用说能够引导它?

谢谢、我很高兴在接下来的几天内对此主题进行更深入的讨论。

此致、

天使

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Angel、

    已知错误

    遗憾的是、这是 SDK 10.0中引入的 Linux 驱动程序错误(但针对 SDK 10.1进行了修复)。 AM64x R5F 内核正常关断在 SDK 10.0中中断、因此您需要重启处理器、以将新固件加载到 R5F 内核中。 有关引导内核的更多详细信息、请访问 https://dev.ti.com/tirex/explore/node?node=A__AdAyuKWUWVV5j4wBc7C6XA__AM64-ACADEMY__WI1KRXP__LATEST

    更多信息

    R5F 内核的启动/停止顺序在 AM64x 上无关紧要 因为当我们关闭 R5F 内核时、我们实际上并不是关闭 R5F 子系统本身的电源。 这意味着、如果在运行时关闭 R5F 内核的电源、您可能不会看到太大的功率差异-整个 R5F 子系统仍在计时并消耗功率。 顺序问题的唯一解决方法是在内核关闭后将子系统本身断电。

    该错误是由为具有 R5F 子系统的不同处理器添加的某些代码引起的、其中 R5F 内核的初始化方式不同-不确定这是否与您的观察结果相关。

    您可以在此处看到驱动程序提交:
    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/log/drivers/remoteproc/ti_k3_r5_remoteproc.c?h=ti-linux-6.6.y-cicd

    我不确定是哪个提交导致了不良行为,但我认为这是提交修复了 SDK 10.1的行为:
    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/remoteproc/ti_k3_r5_remoteproc.c?h=ti-linux-6.6.y-cicd&id=a04282dfaa0ae1917d43cc3f0bbdd8787a4688e6 

    此致、

    Nick

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Nick。

    感谢快速响应。  

    我们已经有了2 9x SDK 版本,我们计划很快升级到 10.01.10.04,但因为它总是发生在生活中,我显然正在测试完全与 SDK,正是在那里引入了这个错误:)。

    您的建议是什么 ?当我们升级并看到一切正常运行时、我应该将票证打开并关闭、还是如果 SDK 10.01.10.04仍有问题、我应该将其标记为已解决并打开一个新的票证?

    谢谢。此致、

    天使

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Angel、

    我喜欢按主题将 e2e 主题拆分。 因此、让我们将此 e2e 线程保留在"SDK10.0上平稳关机"上、如果需要针对该主题进行更多讨论、我们可以在此处执行该操作。 如果您升级到 SDK 10.1、但平稳关机仍无法按预期正常工作、请创建新的 e2e 主题供我们讨论。

    此致、

    Nick

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Nick。

    好的、谢谢您的建议、我们将在接下来的几周内保持此主题的开启状态、并在成功升级后关闭该主题。

    只是几个相关问题:

    1)正如您在上面的代码中看到的、在取消板和驱动程序初始化之前、我们将 Shutdown ACK 发送到 Remoteproc 驱动程序。 这样做的原因是、如果我们恰好相反、由于 deinit 的原因、IPC 所需的 IPC 和/或某些基础设施可能不再起作用。 您知道 Remoteproc 驱动程序在接收到 Shutdown ACK 之后以及真正拉复位之前是否给我们一段时间吗? 如果没有这种延迟、可能会出现这样的情况、 即某些 deinit 程序未正确完成(被 A53端的重置所杀死)、这将是一个非常随机的基础。 我注意到、关断和关断之间的超时 ACK 最大值 5000ms、但无法找到有关上述延迟的任何信息(如果有)。

    2)如果我从您的解释中正确理解、R50-0启动/停止不应该依赖于群集中的另一个内核是否正在运行、而我们观察到的行为是一个错误?

    谢谢。此致、

    天使   

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Angel、

    1) 1)不需要按任何特定顺序关闭 R5F core0和 core1、因为我们不会从整个 R5F 子系统中移除电源

    我在上面强调的提交操作也删除了上面所说的代码

    dev_err(dev, "%s: can not stop core 0 before core 1

    2)向远程核心发送正常关机消息时会发生什么情况?  

    正常关机请求作为邮箱消息发送。 这样、您的代码应该接收邮箱消息、解除所有驱动程序初始化、然后发送 ACK 消息。

    请参阅此 e2e 主题、以深入讨论收到关断请求时 IPC Echo 示例中会发生什么。 我计划在未来将该信息添加到多核学院、但我还没有时间坐下来写一页新的内容。  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

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我已将此报告转换为常见问题解答、部分基于您的反馈:
    https://e2e.ti.com/support/processors-group/processors/f/791/t/1463153