在阅读了与我的问题有关的大部分主题后，没有找到解决我们问题的答案，这里是我的描述：
我们目前正在将 OpenAMP 集成到我们的应用程序中。目前，我们正在使用 OpenAMP_TTY_echo 示例项目中的配置，启用跟踪日志，并在 M4 和 A7 之间使用单个虚拟 UART。
在启动的 Linux 系统中使用“rproc start”启动应用程序时，它按预期工作。跟踪日志可用，并且 /dev/ttyRPMSG0 虚拟 UART 已加载：
- cat /sys/class/remoteproc/remoteproc0/state 输出“正在运行”
- cat /sys/kernel/debug/remoteproc/remoteproc0/trace0 显示我们来自 M4 的调试输出
我们可以将虚拟数据发送到 /dev/ttyRPMSG0 并获得回显响应
在我们的用例中，我们需要尽可能早地启动 M4 应用程序，因此我们配置了 u-boot SSBL 以加载 ELF 文件并启动 M4 执行。然后我们就面临软件启动了，但是linux内核没有加载/dev/ttyRPMSG0设备的问题：
- cat /sys/class/remoteproc/remoteproc0/state 输出“正在运行”
- /sys/kernel/debug/remoteproc/remoteproc0/trace0 未加载
- cat /sys/kernel/debug/remoteproc/remoteproc0/resource_table 为空
- /dev/ttyRPMSG0 未加载
我们检查了以下几点：
在启动序列完成后附加到正在运行的 M4 执行时，我们看到函数 rproc_vir
tio_wait_remote_ready(vdev) 没有返回。好像linux rproc 没有加载资源表。
resource_table 存在于 ELF 文件中（使用 readelf 检查）
u-boot rproc 确实将资源表的正确地址加载到 TAMPER 备份寄存器中
在我们的调查中，我们发现问题似乎与 M4 代码 + 内存大小有关。当代码大小超过 ~130KB（代码 + RAM，其中代码放置在 MCU SRAM 1 中）时，我们可以重现该问题。
低于该大小，M4 应用程序将从 u-boot 正确启动，并且在 Linux 下跟踪可用并创建 RPMSG 设备。
我们尝试在引导期间为相关内核模块（
STM32_rproc 和 remoteproc*）输出详细日志消息，并将 dyndbg 参数添加到 u-boot 内核命令行（dyndbg="file ec.c +p"），但我们只得到了内核尝试使用此参数启动时出现恐慌错误。内核配置中启用了动态调试。我们怎样才能打开以获得这些额外的调试信息？
举报
