芯耀
612
引言
STM32 STM32MP15X 是基于 CM4+CA7 的异构 SOC，CM4 侧用于实时任务的处理，CA7 侧运行 Linux，负责更加复杂的计算和任务处理，CM4 侧采集到的数据通常会给到 CA7 去做处理，因此必然需要核间通信的机制，核间通信需要硬件和软件的支持
硬件：
1）IPCC: 负责产生中断信号
2）共享内存：负责数据交互
软件：
1）CM4 侧 OPenAMP
2）CA7 Linux 侧 RPMsg framework(Mailbox,Remoteproc,RPMsg,VirtIO)
对于核间通信的基本原理请阅读相关 wiki 站点文档。
https://wiki.stmicroelectronics.cn/stm32mpu/wiki/Exchanging_buffers_with_the_coprocessor
https://wiki.stmicroelectronics.cn/stm32mpu/wiki/Linux_RPMsg_framework_overview
本文将结合几个实际案例讨论核间通信可能遇到的问题
- 如何增加 RPMsg buffer size
- 如何增加 RPMsg 通道数
- RPMsg 通信过程出现死锁
- 双核通信过程出现 No more buffer in queue，通信终止
如何增加 RPMsg buffer size
如何将通道数增加为 64,且通道 size 改为 256byte
通过前文的理解，我们已经知道如何计算 vdev0buffer 和 vdev0vring 的 size 了, 根据通道vdev size 的计算公式 vdev0buffer_size = buffer_size * number _of buffer * 2可计算所需的 vdev0buffer_size=256 * 64*2=32768byte=0x8000Vring size：16 通道，vring size 为 438byte， 那么可得 64 通道时的 vring_size 约为1752byte=0x6db,由于 reserve memory 按照 4K page size（0x1000）对齐，且 64 通道数的情况下所需要的vring_size 0x6db 仍然小于 0x1000，vring size 的大小可保持不变。
RPMSG 通信死锁案例解析
问题现象是 RPMSG 通信过程中出现死锁，导致通信中断，系统重启。
No more buffer in queue
该问题表现为在 RPMSG 正常通信一段时间后，CA7 linux 内核不停打印日志 No more bufferin queue，通信过程中断，此时即使重新加载 CM4 仍然不能恢复，只能重启系统，该问题仅在OPENSTLINUX_V1.0 版本，即对应的内核 v4.19 版本中出现，在后续版本中已修复。
