1. Linux 侧 RPMsg 用户态驱动与数据接口概述
在嵌入式系统开发中,我们经常会遇到需要在不同处理器核心之间高效传输数据的需求。本章我们将深入探讨如何在 Linux 用户空间优雅地访问来自 M33 核心的数据。通过前面章节的铺垫,我们已经建立了 M33 和 A35 之间的底层通信机制,现在是时候把这些数据呈现给应用层开发者了。
为什么要在用户空间处理这些数据?原因很简单:我们希望应用开发者能够专注于业务逻辑,而不是深陷底层寄存器操作的泥潭。Linux 内核提供的 RPMsg 字符设备框架(RPMSG_CHAR)正是为此而生,它将这些复杂的底层通信抽象为简单的文件操作接口。
提示:在实际项目中,这种架构设计可以让算法工程师专注于数据处理,而不必了解底层硬件细节,大大提高了开发效率。
2. RPMsg 字符设备框架详解
2.1 RPMSG_CHAR 驱动工作原理
RPMSG_CHAR 是 Linux 内核提供的一个标准驱动模块,它的核心作用是将 VirtIO 通信抽象为字符设备。当 M33 侧创建了名为 "rpmsg-raw" 的端点后,Linux 内核会自动在 /sys/class/rpmsg/ 目录下生成相应的控制接口。
这个框架的美妙之处在于:
- 完全遵循 Unix 哲学"一切皆文件"
- 提供标准的 open/read/write/ioctl 接口
- 隐藏了复杂的 VirtIO 寄存器操作
- 支持多路复用(通过 poll/select)
2.2 端点创建与管理
默认情况下,Linux 不会自动为每个端点创建 /dev 节点,需要手动激活。这个过程看似简单,但有几个关键点需要注意:
- 控制接口路径:/sys/class/rpmsg/rpmsg_ctrlX(X 可能为 0,1,2...)
- 端点命名必须与 M33 侧完全一致
- 源地址和目标地址的分配需要与固件设计匹配
在终端中执行以下命令序列是标准的激活流程:
bash复制# 定位到正确的控制器目录
cd /sys/class/rpmsg/rpmsg_ctrl0
# 创建端点,关联到 M33 的 "rpmsg-raw" 服务
echo "rpmsg-raw" > create_ept
# 验证设备节点是否创建成功
ls -l
