T153核心板A7+RISC-V异构双系统开发实战：从固件部署到RPMsg通信
01
概述
V-CORE-T153-S 采用 Cortex-A7 与 RISC-V E907 异构处理架构。Cortex-A7 运行 Linux，承担图形界面、网络通信、文件管理和应用处理；E907 运行 FreeRTOS，承担实时任务和核间通信。
两个处理系统通过 OpenAMP、RPMsg、共享内存和硬件消息盒协同工作。本文主要介绍开发环境、固件编译与部署、启动检查、RPMsg 通信测试及应用开发方法。
1.1芯片框图
本文中的命令分为三个执行环境：
代码块不包含终端提示符，可直接复制执行。开发主机路径采用/data/tina5.0-t153，SDK 放在其他目录时替换相应前缀。板端示例以 root 身份执行。
1.2快速验证
使用配套完整固件启动开发板，在板端 Linux 执行：
状态为 running、测试完成数为 100 且失败数为 0，表示 E907 已启动并完成 RPMsg 请求应答验证。首次使用可按第 4～6 章完成编译、更新及启动检查，再进入外设开发与实时性评估。
02
软件资源
以下路径以 SDK 根目录 /data/tina5.0-t153 为基准。
bga_demo 是保留的 SDK 工程名称，该目录已包含 V-CORE-T153-S 的核间通信适配。
两个 Linux 项目的E907 固件均位于 bin/amp_rv0.bin。根文件系统生成流程优先安装对应板型目录中的固件。
03
AMP 启动流程
本项目采用 Linux 启动 E907 的方式：
1. Linux 初始化预留内存、消息盒和 remoteproc 驱动。
2. /etc/init.d/S62e907 在后台启动 E907。
3. remoteproc 加载 amp_rv0.bin，解析 ELF 和资源表，启动 E907。
4. E907 初始化 FreeRTOS 和 OpenAMP，发布 RPMsg 服务。
5. Linux 匹配 sunxi,rpmsg_test 服务，创建 /dev/rpmsg_test。
remoteproc 显示 running 仅表示处理核已经启动；测试设备节点出现，才表示对应 RPMsg 服务已完成发布及驱动匹配。
3.1预留内存
两个板型的 AMP 主要共享区域如下：
修改内存布局时，必须同步 Linux 设备树、E907 链接脚本、资源表及相关内存保护配置。不得将这些区域作为 Linux 普通应用缓冲区使用。
04
开发环境与编译
4.1编译环境
V-EVB-T153-S 评估板进行，以配合产品标准驱动，减少二次开发
使用 SDK 配套的 Linux 开发环境和工具链。E907 工具链目录为：
检查版本：
工具名称中的 riscv64 不代表本工程运行在 64 位核上，实际 ELF 应为 32 位 RISC-V。
主机需具备 Bash、GNU Make、GCC/G++、Python 3 和 ncurses 开发库。Ubuntu/Debian 环境可安装以下基础构建依赖：
SDK 应放在 Linux 本地文件系统中，保留执行权限和符号链接。编译使用普通开发用户，不使用 sudo ./build.sh。E907 裸机工具链与 Cortex-A7 Linux 应用工具链分别使用，不互相替代。
过程。
为了保证产品设计具有良好的兼容性和稳定性，用户没有使用到的引脚资源请务必悬空处理。
V-CORE-T153-S 核心板共160脚，引脚通过1.0mm间距的邮票孔引出；其实物引脚图如下图所示。
4.2编译 E907
方式一：Linux SDK 统一入口
在开发主机选择板型后执行：
NAND 板型将 hd_t153_emmc 替换为 hd_t153_nand。两个项目均配置 LICHEE_RTOS_PROJECT_NAME=t153_e907_bga_demo；统一入口自动编译 E907，并将 ELF 复制、strip 到所选板型的 bin/amp_rv0.bin，不需要再执行第 4.3 节的手动复制。更新一个项目不会自动同步另一个项目的固件。
方式二：独立 RTOS 入口
适合日常修改、增量编译和配置调试。在独立终端执行，避免与 Linux SDK 构建环境变量混用：
需要修改功能选项时，在选择工程后执行：
菜单中按 / 搜索配置符号，选择功能后保存退出。mrtos menuconfig 会将配置同步到工程 defconfig；仅运行 mrtos_menuconfig 修改工作 .config，后续 mrtos 可能重新载入工程默认配置，不能据此认定功能已保存。
需要清理当前 RTOS 工程输出时执行 mrtos clean，再执行 mrtos。这不是修改配置后的必需步骤。重新执行 lunch_rtos 会加载工程 defconfig，因此应先保存配置。
编译输出目录：
部署前检查 ELF：
确认 Class: ELF32、Machine: RISC-V，并保留本次对应的调试 ELF、源代码版本与构建日志。
4.2.1 AMP 关键配置
V-CORE-T153-S 的基础 AMP 配置已纳入配套工程。扩展外设时保留下列配置关系：
E907 defconfig 路径：
Linux defconfig 路径：
Linux 设备树将 firmware-name 设置为 amp_rv0.bin，通过 memory-region 指定运行区和 vring，通过 mboxes 指定消息盒。只启用 Kconfig 而未配置这些资源，不能完成核间通信。
4.3 置入固件
将 E907 ELF 制作成固件文件。以下命令在 Linux 开发主机执行：
修改前应归档原固件。此处的 .bin 文件仍是 ELF 格式，仅文件名沿用 SDK 约定。
4.4 生成完整固件
eMMC 项目：
本流程使用已完成第 4.2 或 4.3 节更新的 E907 固件。需要在此处重新编译 E907 时，在生成 rootfs 前执行 ./build.sh rtos。
NAND 项目将选择命令中的板型替换为 hd_t153_nand，再执行相同的编译、打包命令。每一步成功后再执行下一步。
完整固件输出：
必须按照实际存储器件选择镜像，不能将 eMMC 镜像用于 NAND 板卡，反之亦然。
05
固件部署与在线更新
5.1 完整固件烧写
设备接入烧写 USB 后，可在 Linux 执行：
设备进入烧写模式后，通过配套上位机选择对应板型的完整 .img，执行下载并确认全部分区、校验及启动组件更新成功。分区写完但校验失败，不视为烧写完成。
新版 U-Boot 在 EFEX USB 循环、NAND/UBI 长循环和校验分块之间调度 PE0 外部看门狗翻转。首次从旧固件升级时，reboot-efex 仍运行设备内的旧 U-Boot；选择新版镜像不会立即替换正在执行的烧写程序。若旧版本会在烧写中复位，应按硬件调试流程临时停用外部看门狗完成首次升级，随后恢复并验证正常烧写。
5.2 判断 E907 固件加载来源
板端执行：
本项目加载器会尝试固件分区 riscv0、riscv0-r，在分区加载失败后回退到文件系统。出现以下日志说明使用了文件系统：
如果分区中存在可用固件，仅替换 /lib/firmware/amp_rv0.bin 可能不生效；修改 sysfs 的 firmware 名称也不等同于禁用分区加载。此时应更新完整固件，不要盲目对 MTD、UBI 或 eMMC 原始分区写入 ELF。
5.3 文件系统固件在线更新
本节仅适用于已确认采用文件系统加载的设备。PC 上传文件：
也可通过已挂载的 TF 卡或 U 盘传入。先用 mount 确认实际挂载点，再将对应介质中的 amp_rv0.bin 复制到 /tmp/amp_rv0.bin。TF 卡、USB 介质和 eMMC 的 UDISK 是不同设备，不使用固定 mmcblk 序号判断固件所在介质。
板端备份、替换：
替换文件不影响当前已加载的 E907 程序，重启后才生效。重启后检查构建时间、加载来源、设备节点及功能；需要回退时，用备份文件按相同步骤恢复。不要在生产任务运行期间直接停止远端处理核。
5.4 eMMC 与 NAND 的更新方式
两种存储器的文件系统更新步骤相同，但 riscv0 分区更新接口不同。UBI 卷编号由实际分区布局决定，不能使用参考板的 /dev/ubi0_5 作为 HD-T153 固定地址。完整固件打包会同时携带对应 E907 固件和根文件系统中的固件副本。
06
启动检查与调试
6.1 基础检查
正常状态为 running，RPMsg 设备目录存在服务，/dev/rpmsg_test 为字符设备。
S62e907 start 为后台启动，status 可查询状态；该脚本的 stop 分支不停止 E907，不应作为远端处理核关闭命令使用。
6.2 读取 E907 日志
正常启动记录包含 FreeRTOS 欢迎信息、OpenAMP 初始化和 sunxi,rpmsg_test 服务发布信息。日志位于共享环形缓冲区，读取可能消费内容，长时间不读取可能发生覆盖。运行自动化测试时由测试脚本保存日志，不要在其他终端同时读取。
V-CORE-T153-S E907 评估固件关闭了物理 UART 控制台，以避免与 Linux 调试串口争用。优先使用共享日志，不要直接套用演示工程的 UART5 引脚作为本产品的调试串口。
6.3 地址定位
日志中出现程序地址时，使用同一次构建的调试 ELF 定位：
将示例地址替换为实际异常地址。不能用另一版本的 ELF 解读地址。
6.4 手动启动、停止与重新加载
这些操作用于开发调试。先停止正在使用 RPMsg、RPBuf 和远端外设的业务程序，并确认 /etc/init.d/S62e907 的后台启动过程已经结束。
板端 Linux 在状态为 offline 时执行：
停止正在运行的 E907：
预期停止后显示 offline。重新执行启动命令可再次加载固件。停止或启动返回错误时先检查 dmesg，不连续重复写入命令。远端重启会销毁原有通信端点，Linux 应用应关闭旧文件描述符，等待节点重新创建后再打开。
本 BSP 的停止流程也可能读取固件资源表。因此需要在线更换程序时，应先停止 E907，再替换固件文件，最后启动；不要在远端运行期间换成资源表不兼容的镜像后直接执行 stop。第 5.3 节的文件替换加整机重启方式用于常规升级。
6.5 可选 RPMsg 控制台
物理 UART 日志关闭不影响通过 RPMsg 调用 E907 CLI。E907 工程已配置 CONFIG_MULTI_CONSOLE、CONFIG_RPMSG_MULTI_CONSOLE 和 CONFIG_RPMSG_CLIENT。Linux 侧使用 SDK 的 amp_shell 客户端。
amp_shell 不在基础评估镜像的默认安装列表中。需要交互执行外设例程时，在开发主机为对应项目启用下列 Buildroot 选项：
配置与生成固件：
菜单中按 / 搜索 BR2_PACKAGE_AMP_SHELL，同时启用其 RPMSG 依赖；保存的配置应纳入对应项目的 Buildroot defconfig。为另一存储版本启用时，先切换板型，再执行上述配置流程。
更新对应完整固件并启动 E907 后，在板端 Linux 执行：
根据客户端列出的控制器选择 E907 对应项，再在远端控制台执行 help。也可先用 amp_shell -h 查看参数，通过 -d 指定实际存在的控制设备；控制设备名以板端枚举结果为准。
不要将 E907 命令直接输入 Linux Shell，也不要将 hd-rpmsg-test 当作 E907 命令。共享日志用于观察运行信息，不是命令输入接口。性能测量时退出控制台，避免命令输出和测试线程额外影响时延。
07
RPMsg 通信与实时性测试
7.1 单轮测试
参数依次为请求数、测试报文长度、相邻请求间隔：
间隔为 0 表示收到上一条响应后立即发送下一条，仍属于单请求往返测试，不是多消息并发吞吐测试。440 字节是本测试协议限制，不代表 RPMsg 所有应用的最大有效载荷。
7.2 指标说明
完整诊断输出还包含发送排队、FIFO 写入及回复路径分段。A7 本地统计使用 ktime，跨核路径使用共享 24 MHz 计数器；不得直接相减两个不同时间源的值。
min、avg、p95、p99、max 均以微秒输出。检查收发错误、超时、失败数为 0，诊断覆盖率完整，尾探针为 OK。需要定位异常时结合最慢报文的分段数据，不应把 RTT 除以二作为实测单向接收时延。
7.3 连续与业务负载测试
先完成第 6.2 节的 debugfs 挂载。空载与 CPU 压力对照：
业务组合负载包含网络双向收发、介质同步读写校验和显示刷新。PC 先启动：
板端确认网络可达，TF 卡已挂载、可写且剩余空间至少 32 MiB，再执行：
短测成功后，将末尾参数改为 20 10000 0。IP 地址、存储目录必须按实际环境设置，不能把 /tmp 当作真实存储负载。显示测试会临时绘制画面，存储测试产生实际闪存写入。
输出目录为 /tmp/hd-rpmsg-test.XXXXXX，保留 summary.tsv、summary.txt、各轮日志、E907 trace 及业务负载日志。汇总中的 P99 为逐轮 P99 的最大值，不是合并全部样本重新计算的分位数。
测试工具支持通过 HD_RPMSG_CPU_MASK 和 HD_RPMSG_FIFO_PRIORITY 设置发送进程的绑核及调度策略。例如掩码 4 表示 CPU2，FIFO 优先级 20。此设置不等同于修改内核消息接收线程，也不构成实时性能保证。调度对照应使用配套测试脚本，并保留原配置。