引言

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 通信過程中出現死鎖，導致通信中斷，系統(tǒng)重啟。

No more buffer in queue

該問題表現為在 RPMSG 正常通信一段時間后，CA7 linux 內核不停打印日志 No more bufferin queue，通信過程中斷，此時即使重新加載 CM4 仍然不能恢復，只能重啟系統(tǒng)，該問題僅在OPENSTLINUX_V1.0 版本，即對應的內核 v4.19 版本中出現，在后續(xù)版本中已修復。