[参考译文] AM6442：Remoteproc Linux Debugging Questions

对于未来的读者,杰瑞德回来说,他得到了一切工作与链接在前一个回应。

您好 Jared、

我将您有关 AM263Px SBL 大小优化的问题拆分为一个单独的 e2e 问题、然后发送给 AM263Px 团队：
am263px 的最小 SBL

在 Linux 加载非 Linux 内核的上下文中、您可以 去除调试信息和其他不需要的数据、如 AM64x 多核 Academy 中所述  
如何优化远程内核项目内存
https://dev.ti.com/tirex/explore/node?node=A__AeakdFP2wJ-rLsVTOacY7Q__AM64-ACADEMY__WI1KRXP__LATEST 

但是、我不确定如何从非 Linux 处理器上的 SBL 引导的角度优化二进制大小。

此致、

Nick

嗨、Nick、

感谢您创建新主题、衷心感谢您的帮助！

再次感谢、

- Jared

您好 Jared、

没问题、很高兴我们能够如此快速地取消阻止 R5F 调试！ 如果出现任何其他问题、请随时创建新主题。

此致、

Nick

嗨、Nick、

我以为都很好、但实际上遇到了一些问题。

首先、我之前应该已经提到过这一点、但似乎不再需要您的补丁来启用跟踪、因为 SysConfig 会自动将补丁内容添加到“generated/ti_drivers_config.c"中“中。

我遇到的问题是通过 remoteproc 启动 r5f0-0：

echo start > /sys/class/remoteproc/remoteproc1/state

要重现此问题：

1. 重新启动 Linux。 请注意、Remoteproc 会自动启动 DT 定义的所有远程内核、并且在此阶段尚未看到任何故障
2. 使用`μ s echo stop >/sys/class/remoteproc/remoteproc1/state`停止 r5f0-0
3. 使用`μ s echo start >/sys/class/remoteproc/remoteproc1/state`启动 r5f0-0。 请注意、有时这实际上是成功的；但是、如果我重复步骤 1 和 3、我最终可以重现崩溃。

以下是失败的 Remoteproc 命令的输出：

****** stop r5 core *******
root@aec-am6442:~# echo stop > /sys/class/remoteproc/remoteproc1/state
[  328.830897] remoteproc remoteproc1: stopped remote processor 78000000.r5f

****** attempt to restart r5 core *****
root@aec-am6442:~# strace echo start > /sys/class/remoteproc/remoteproc1/state
execve("/usr/bin/echo", ["echo", "start"], 0xffffc25862e8 /* 17 vars */) = 0
brk(NULL)                               = 0xaaaaed[  332.550696] remoteproc remoteproc1: powering up 78000000.r5f
fc8000
faccessat(AT_FDCWD, "/etc/ld.so.preload", R_OK) = -1 ENO[  332.560443] remoteproc remoteproc1: Booting fw image am64-main-r5f0_0-fw, size 403572
ENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=6699, ...}) = 0
mmap(NULL, 6699, PROT_READ, MAP_PRIVATE, 3, 0) = 0xffff8cf06000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\0\207\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1650968, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffff8cf04000
mmap(NULL, 1826688, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_DENYWRITE, -1, 0) = 0xffff8cd10000
mmap(0xffff8cd10000, 1761152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xffff8cd10000
munmap(0xffff8cebe000, 65408)           = 0
mprotect(0xffff8ce9b000, 73728, PROT_NONE) = 0
mmap(0xffff8cead000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18d000) = 0xffff8cead000
mmap(0xffff8ceb2000, 49024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffff8ceb2000
close(3)                                = 0
set_tid_address(0xffff8cf04e50)         = 399
set_robust_list(0xffff8cf04e60, 24)     = 0
rseq(0xffff8cf054a0, 0x20, 0, 0xd428bc00) = 0
mprotect(0xffff8cead000, 12288, PROT_READ) = 0
mprotect(0xaaaac570f000, 4096, PROT_READ) = 0
mprotect(0xffff8cf0c000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0xffff8cf06000, 6699)            = 0
getrandom("\xfc\xdc\x8d\x33\x89\x05\xb6\x84", 8, GRND_NONBLOCK) = 8
brk(NULL)                               = 0xaaaaedfc8000
brk(0xaaaaedfe9000)                     = 0xaaaaedfe9000
fstat(1, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
write(1, "start\n", 6

***** SOC reset occured, rebooting now *****
U-Boot SPL 2025.01-00054-g6980061fa875-dirty (Feb 12 2025 - 05:47:04 +0000)

我没有按照 本 文档中所述实现正常关机、我最好的猜测是、这会导致 R5 在关机后处于坏状态、从而在我尝试重新启动内核时导致崩溃；但是、我不确定如何验证。

给您的问题：

1. 对于如何调试此问题、您有何建议？
2. 您是否同意这可能是由关断后 R5 处于不良状态所导致的？
3. 你对什么可能导致这一点还有其他的智慧的话吗?
   
   

感谢您的帮助、

- Jared

更新：

我刚看到 这篇 关于类似问题的文章。

我运行的内核版本是 6.12.8、但我要通过 Yocto 构建内核、并使用基于 TI 端口的 Phytec 内核端口。 我使用的是 SDK 版本 11.01.00.17。 您是否知道使用这些版本是否支持正常关机？

谢谢、

- Jared

您好 Jared、

我不记得以前看到过这种具体的行为。

如果您未在 R5F 固件中启用正常关闭、我很惊讶 Linux Remoteproc 驱动程序会关闭远程内核。 如果您使用 TI 版本的 Remoteproc 驱动程序、我希望 Linux 驱动程序应该向 R5F 发送关闭通知、等待 5 秒、然后超时并中止关闭、因为 R5F 不响应。

您是否修改了驱动程序以便不再出现超时？

我不确定是否有正常运行的关闭代码、所以检查 Phytec 是否具有您在 ti-linux-6.12.y 分支 k3_r5_suspend 函数中看到的相同驱动程序代码：
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/remoteproc/ti_k3_r5_remoteproc.c?h=ti-linux-6.12.y-cicd#n507 

此致、

Nick

嗨、Nick、

我把这个放在了幕后、因为我认为它只会影响开发；但是、我意识到我们需要在生产中更改 R5 固件的能力。

对于这里的一些背景、当 am6442 首次启动时、我想将一些固件加载到 r5fss0-0 上、该固件将通过 FSI 流式传输 MCELF 来帮助引导连接的 am263p。 该过程完成后、我想将新固件加载到 r5fss0-0 内核上。

我的问题是、我仍然看到上述问题、即通过 rproc 启动固件有时会导致 SOC 复位。 我尚未在固件中实现平稳关断、Phytec 的 Remoteproc 源与 TI 的 (diff attached) 几乎相同。

am6442 多核 Academy 文档指出：

如果远程内核在 Linux 运行期间断电而没有向 DM 内核发出警告、则远程内核无法指示 DM 内核释放其外设。 当远程内核在重新启动后请求其外设时、DM 内核将拒绝请求、因为 DM 内核认为外设仍在使用。 此时、远程内核通常会停止运行、并且需要重新启动整个处理器。

我猜是由于文档中所述的原因、R5 内核挂起、然后由于内核挂起而发生看门狗重新启动。 我不确定哪种最佳方法可用于确认实际上正在发生什么情况、但在发出启动命令和 SOC 重新启动之间似乎存在明显的延迟（几秒钟）。  

问题：

1. 您提到、SHUTDOWN 的预期行为是 Linux 将通过 rproc 发送关闭消息、R5 内核不会响应、因此 SHUTDOWN 请求将中止。 这不是我看到的行为。 当我`Δ I echo stop >/sys/class/remoteproc/remoteproc 发出关机命令时 /state`我得到以下信息：
   
           [2732.443757] remoteproc remoteproc1:已停止远程处理器 78000000.r5f
   
   没有明显的延迟、并且似乎内核已成功关闭、至少在/sys/class/remoteproc/remoteproc 上是如此 /state 表示这一点。  这种预期行为是否存在？
   
   
2. 对于如何验证 SOC 复位是否由看门狗复位引起、是否有任何建议？ 您是否有其他想法导致此行为？

感谢您的帮助、

- Jared

e2e.ti.com/.../4377.diff.txt

e2e.ti.com/.../4377.diff.txt

2025 年 12 月 23 日编辑

您好 Jared、

从 Linux 端正常关机：

此时、TI 的正常关机代码尚未向上流式传输。 如果您要在运行期间关闭并重新启动 R5F、从长远来看、我建议添加对 Linux 驱动程序正常关断的支持。

实际上、bootlin 中的某个人看起来正在向上流式传输平稳关机。 您或许能够从该草案中获得想法：
https://lkml.org/lkml/2025/11/27/27

Beleswar 是我们的 TI 开发人员之一。

短期：确保第一个 R5F 固件在 Linux 将其关闭之前释放所有资源  

如果您知道第一个 R5F 固件将始终关闭、短期内您不必确定 Linux 正常关闭补丁。 我将设置与 Linux 的握手以表明您已完成（例如，如果您已在 R5F 和 Linux 之间配置了 RPMsg）、然后立即将 R5F 置于“已知良好状态“。

如果问题消失、则说明这是由于 R5F 在关闭之前未处于良好状态而导致的。

对于 RPMsg /平稳关断示例、AM64x 存储库滞后于 AM62x 存储库、因此请参阅示例的 AM62x 版本、了解释放所有资源并进入 WFI 的过程。

AM64x 存储库工程位于以下位置： https://github.com/TexasInstruments/mcupsdk-core/blob/next/examples/drivers/ipc/ipc_rpmsg_echo_linux/ipc_rpmsg_echo.c 

AM62x 存储库工程在此处： https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/ipc_rpmsg_echo.c 

以下是另一个客户刚刚通过其 AM64x R5F 工程实现正常关断的示例：
AM64X-ADVANCE-SW：在 R 内核中使用中断平稳关断实现 

我们可以查看重置原因吗？

是的、您可以查看 RST_SRC 寄存器以查看热复位或主域上电复位的原因。 在 TRM 中搜索 CTRLMMR_RST_SRC、如果您的文件系统中已启用 devmem2、则可以使用 devmem2 进行读取。

此致、

Nick

嗨、Nick、

感谢您的答复。

我正在尝试实施平稳关机、到目前为止没有运气。 我查看了“ipc_rpmsg_echo.c"，“，这、这对于仅实现正常关断而言似乎是夸大其词。 我最终得出了以下结论：

void ipc_rp_mbox_callback(uint32_t remoteCoreId, uint16_t clientId, uint32_t msgValue, int32_t crcStatus, void *args)
{
    if (clientId == IPC_NOTIFY_CLIENT_ID_RP_MBOX && msgValue == IPC_NOTIFY_RP_MBOX_SHUTDOWN)
    {
        IpcNotify_sendMsg(gShutdownRemotecoreID, IPC_NOTIFY_CLIENT_ID_RP_MBOX, IPC_NOTIFY_RP_MBOX_SHUTDOWN_ACK, 1u);
        FSI_txDeinit(CONFIG_FSI_TX0_BASE_ADDR);
        FSI_rxDeinit(CONFIG_FSI_RX0_BASE_ADDR);
        Board_driversClose();
        Drivers_close();
        Board_deinit();
        System_deinit();
        HwiP_disable();
        __asm__ __volatile__ ("wfi"   "\n\t": : : "memory");
    }
}

void *fsi_transfer_mcelf_main(void *args)
{
    Float32 transferTime;
    uint64_t startTime;
    uint64_t endTime;
    uint32_t retries = 0U;
    int32_t status;
    volatile uint8_t loop = 1U;

    /* Initialize drivers */
    Drivers_open();
    Board_driversOpen();

    while(loop);

    /* Initialize RPMessage and register shutdown callback for graceful shutdown */
    RPMessage_waitForLinuxReady(SystemP_WAIT_FOREVER);
    IpcNotify_registerClient(IPC_NOTIFY_CLIENT_ID_RP_MBOX, &ipc_rp_mbox_callback, NULL);

另外、调试时、我似乎没有从 rproc 收到关断消息、至少我没有命中回调函数中设置的断点。 对我在这里出了什么问题有什么想法吗？ 我可能有错误的 SysConfig 或某些内容（附加了 SysConfig 脚本）。

感谢您的帮助、

Jared

e2e.ti.com/.../6371.syscfg.txt

您好 Jared、

今天没时间了。 尝试对星期五做出响应。 如果我没有在星期五上回复、请 ping 通该线程、以便我可以在度假前尝试给出回复。

此致、

Nick