1 概要

本章节将介绍如何A7和M4进行联合调试，我们在分析 STM32CubeMP1 固件包的时候，固件包下有一个 OpenAMP文件夹，AMP 是指非对称多处理（Asymmetric Multiprocessing），非对称多处理是指各核的结构并非对称，例如 STM32MP1 是两个 Cortex-A7 内核加一个 Cortex-M4 内核的组合，各个核结构并非对称。OpenAMP 常用于处理器间通信，OpenAMP 软件框架的组件主要包括 RPMsg（远程处理器消息传递）、VirtIO（虚拟化模块）和 Remoteproc，为开发 AMP 系统提供了必要的 API函数，可以实现核间通信。

OpenAMP 下的 Remoteproc 允许本地处理器与系统上可用的远程处理器进行通信，对于STM32MP157，本地处理器就是指 Cortex-A7，远程处理器指 Cortex-M4，本节我们就利用Remoteproc 来让 Cortex-A7 远程控制 Cortex-M4 的生命周期，即加载、启动和停止 Cortex-M4上的固件（.elf 或者.axf 文件）。

前面的 Cortex-M4 开发实验部分我们是在线仿真的，即通过 ST-Link 将程序下载到 SRAM中运行，开发板掉电后程序就会丢失，这种方式适合在 Cortex-M4 开发调试阶段，也叫工程模式（Engineering Mode）。如果在核间通信的时候，我们就需要使用量产模式（Production Mode）来进行联合调试，下面我们讲解如何实现 Cortex-A7 和 Cortex-M4 联合调试。

关于 Cortex-A7 和 Cortex-M4 双核通信的相关实验，正点原子会有独立的文档章节进行讲解。本节我们只是讲解如何在 Linux 操作系统中使用 Cortex-A7 去加载、启动和停止运行 Cortex-M4 的固件。

本章将分为如下几个小节：

1. Remoteproc 框架简介；
2. 使用 STM32CubeIDE 进行调试；
3. 拷贝文件后手动调试；

2 Remoteproc 框架简介

2.1 Remoteproc 框架

对于具有非对称多处理的 SOC，不同的核心可能跑不同的操作系统，例如 STM32MP157的 Cortex-A7 运行 Linux 操作系统，Cortex-M4 可以运行 RTOS 操作系统。为了使运行 Linux 的主处理器与协处理器之间能够轻松通信，Linux 引入了 Remoteproc 框架，该框架允许不同的平台/体系结构在抽象硬件差异的同时控制那些远程协处理器，如主处理器加载协处理器固件，打开、关闭或配置协处理器等。此外，Remoteproc 框架还添加了 RPMsg 和 Virtio，所以 Remoteproc驱动只需要提供一些低级处理程序，其它 RPMsg 驱动程序就可以正常工作。

Remoteproc 驱动提供可直接调用的 API，方便用户层去调用，在 Linux 操作系统下已经有remoteproc 的相关驱动和 API，这里我们就不需要过多地去关注 remoteproc 了，我们直接使用它来控制 M4 内核即可（Remoteproc、RPMsg 和 Virtio 是 OpenAMP 下重要的框架，在后面的章节我们会对它们进行讲解）。STM32MP157 的 Linux 下 Remoteproc 框架如下：

在 Remoteproc 框架框图中，我们查看两个重要的组成部分：
remoteproc 是通用远程处理框架部分，其作用是：
1）将.axf 文件加载到 Cortex-M4 内核中（在 STM32CubeIDE 下是.elf 文件）；
2）解释.axf 文件资源表以设置关联的资源（例如 IPC 和内存分割等）；
3）控制 Cortex-M4 内核启动、关闭；
4）提供监视和调试远程服务；

stm32_rproc 是远程处理器平台（即 M4）驱动程序，其作用是：
1）向 Remoteproc 框架注册供应商特定的功能（如回调部分）；
2）处理 Cortex-A7 和 Cortex-M4 关联的平台资源（例如寄存器，看门狗，复位，时钟和存储器）；
3）通过邮箱框架将通知转发到 M4；

以上 Cortex-A7 称为主处理器，Cortex-M4 称为协处理器，主处理器先启动，然后引导协处理器启动，主处理器再加载协处理器固件。总之，Remoteproc 框架实现了对远程协处理器生命周期的控制，它允许 Cortex-A7 主处理器将.axf 固件加载到 Cortex-M4 内核中，然后解析固件资源列表后再启动/关闭/配置 Cortex-M4 内核。而 RPMsg（远程处理器消息传递，英文：Remote Processor Messaging）通过共享内存向远程 CPU 发送消息或从远程 CPU 接收消息。

下面，我们利用 Remoteproc 来实现 Cortex-A7 加载并运行 Cortex-M4 固件（.axf 文件）。

2.2 实验准备

实验前，我们需要以下硬件资源：
1）正点原子 STM32MP157 开发板（配套电源线）；
2）2 根 Type-C 线；
3）ST-Link 下载器（加转接板和 T 口 USB 线）；
4）一张 TF 卡或 U 盘；
5）一根网线；

以上的第 3 和第 4 项根据选择的环境不同而需求不同，例如：如果使用 STM32CubeIDE 将固件通过 Remoteproc 下载到开发板的 Linux 操作系统中的话，那么 ST-Link 下载器就必须要用到；如果选择通过将 TF 卡或者 U 盘拷贝固件到开发板的话，则不需要 ST-Link 下载器；如果使用网络（如 FTP 或 SSH）的方式传输固件的话，则第 3 和第 4 项都不需要，但是要一根网线。

注意事项：
一开始 ST 推出了 STM32CubeIDE1.4.0 版本，本教程一直使用的也是 STM32CubeIDE1.4.0版本 ， 使 用 正 常 ， 没 发 现 什 么 问 题 。 后 来 ST 又推 出 了 STM32CubeIDE1.5 以及STM32CubeIDE1.6.1，测试发现 STM32CubeIDE1.6.1 无法识别 MPU Serial（详情请见第 28.2小节），可能是新版本软件的 Bug 或者其它原因，目前遇见这种情况的小伙伴，他们将STM32CubeIDE1.6.1 卸载，再安装 STM32CubeIDE1.4.0，然后再安装 STM32CubeIDE1.6.1 就可以了，这也是奇怪，笔者还未发现具体是什么原因，如果找到原因的朋友可以在正点原子论坛http://www.openedv.com/forum.php 发表你的解决办法，大家一起学习，共同进步！

2.2.1 硬件连接

1）使用 STM32CubeIDE 进行调试
下面，我们采用 STM32CubeIDE 将固件通过 Remoteproc 下载到开发板的 Linux 操作系统中，我们先进行连线操作。首先，需要使用一根 Type-C 线将开发板的 USB_OTG 接口接到 PC的 USB 接口，用于模拟出一个 USB 网卡，然后再用一根 Type-C 线将开发板的 USB_TTL 接口接到 PC 的 USB 接口，用于模拟通过串口获取 USB 网卡的 IP，以实现开发板和电脑通信，如下图：

2）网络传输文件
如果不是使用 STM32CubeIDE 进行调试，而是使用网络的方式传输固件的话，硬件连接方式如下，只需要接电源线以及在 USB_TTL 口接 Type-C 线，外加网口接一根网线（网线另一端可以接路由器或者和电脑直连，根据个人情况来选择）：

3） 采用 TF 或者 U 盘卡拷贝固件
如果使用 TF 卡或者 U 盘等存储设备来拷贝的话，开发板只需要接电源线以及在 USB_TTL接口接 Type-C 线即可。

2.2.2 启动 Linux 操作系统

先接好线，开发板拨码开关拨到 010，即 eMMC 启动方式，因为开发板出厂 Linux 系统已经烧录在 eMMC 里了，接好电源线启动开发板，等待 A7 启动完成。判断 A7 是否启动完成，可以通过观察底板的 LED0 是否在闪烁（出厂的 Linux 系统在设备树里已经默认配置 LED0 为心跳灯，启动进入 Linux 系统后，LED0 会闪烁），或者在串口终端查看串口的打印信息，如果开发板底板的 LED0 在闪烁或者串口终端已经打印―root@ATK-stm32mp1‖，则说明 Linux 系统已经完全启动。

此时，查看设备管理器，网络适配器下多出了―Remote NDIS Compatible Device #2，该设备是 USB_OTG 模拟的 USB 网卡；端口下多出了一个 CH340 设备口，是 USB_TTL 的 COM 口（这里显示 COM65），如下图所示

如下，在网络连接处也可以看到模拟的 USB 网卡―Remote NDIS Compatible Device #2：

如果没有看到模拟的 USB 网卡，可以检查开发板 Linux 系统是否正常运行、连接在USB_OTG 口的 Type-C 线是否接好以及线是否有问题等，可以尝试重启开发板或者重新接好Type-C 线。下面，我们利用此 USB 网卡并借助 Remoteproc 将固件（.elf 文件）传输到 Linux操作系统中。

3 使用 STM32CubeIDE 进行调试

3.1 操作步骤

如果使用 STM32CubeIDE 来开发 M4，最终生成.elf 文件，可通过 STM32CubeIDE 将.elf文件上传到开发板的―/lib/firmware‖目录下并自动运行。

我们本小节实验以第十一章的实验来进行测试，首先，按照 28.1.2 小节讲解的步骤接好线，再将 ST-Link 接在开发板 JTAG 口，然后开发板从 eMMC 启动，等待进入 Linux 操作系统，注意观察是否有 USB 网卡：

然后打开 STM32CubeIDE，我们需要设置串行过滤器，因为默认情况下，STM32CubelDE是只将 STMicroelectronics 和 FTDI 设备作为首选的串行设备，其它设备无法识别，所以我们要关闭默认选项而选择我们需要的设备，点击―Windows PreferencesSTM32CubeMPU Serial, 设置如下：

可能会出现多个 COM 口，根据设备管理器显示的设备来选中对应的 COM 口：

点击 Debug 配置选项，进入 Debug Configurations 配置界面：

如下，选中默认已有的 BEEP_CM4 Debug 配置项，如果没有此配置项，可以双击―STM32Cortex-M C/C++ Applications‖来新建一个配置项，关于这些操作，相信大家都已经很熟悉了，如果不清除的，可以看前面第四章的实验部分。

进入调试器配置部分，按照如下来配置，在 Load Mode配置项选中―thru JTAG/SWD link(Production mode)，Serial Port‖处根据设备管理器显示部分选择COM口，这里选择―MPU Serial (COM65)‖，―Inet Address‖处会自动显示192.168.7.1，此IP地址就是USB网卡的IP地址：

如果此时在 Linux 操作系统下输入 ifconfig，可以看到 USB 网卡的 IP 为 192.168.7.1，STM32CubeIDE 就是通过此 IP 地址将.elf 文件传输到 Linux 操作系统的。

点击 Debug 后，STM32CubeIDE 开始将 BEEP_CM4.elf 文件下载到 Linux 文件系统的/lib/firmware‖下，下载好后，系统会自动解析 BEEP_CM4.elf 文件资源，然后设置相关的资源，并运行程序：

此时，开发板的蜂鸣器开始嘀嗒嘀嗒发出声响，在串口终端的―/lib/firmware‖下也可以找到BEEP_CM4.elf 文件，同时串口终端打印一些调试信息：

1remoteproc remoteproc0:powering up m42remoteproc remoteproc0:Booting fw image BEEP_CM4.elf,size19202763remoteproc remoteproc0:header-less resource table4remoteproc remoteproc0:no resource table foundforthis firmware5remoteproc remoteproc0:header-less resource table6remoteproc remoteproc0:remote processor m4 is now up

以上的打印信息中：
第 1 行：启动 M4；

第 2 行，启动固件 BEEP_CM4.elf，并提示该固件文件大小为 1920276（指文件大小，不是程序大小）；

第 3 和第 5 行，A7 打印―header-less resource table‖表示资源表大小为 0，资源表是描述固件资源的一个条目（或者说数据结构），在加载 M4 固件的时候，A7 会去解析固件，并检查资源表的信息，如果资源表大小为 0，就会打印“header-less resource table‖；

第 4 行，打印提示没有这个固件的资源表；

第 6 行，远程处理器 M4 已经启动，这里主处理器是 A7。
可以点击 STM32CubeIDE 的暂停键暂停调试，蜂鸣器就停止发声，或者点击停止键退出调试：

3.2 fw_cortex_m4.sh 脚本分析

前面操作完成后，跑 Linux 操作系统的 A7 成功运行了跑裸机的 M4 的固件，这个过程其实是由一个 fw_cortex_m4.sh 脚本参与完成的，该脚本我们在前面的 8.3 小节里有简单提到过，因为还没有实验用到该脚本，所以我们前面未对该脚本进行解释。下面我们来看看这个脚本。

在 STM32CubeIDE 的 RemoteProc 目录下可以看到该脚本：

不能直接在 STM32CubeIDE 上双击查看此脚本，可以使用代码查看软件来查看此脚本的内容，内容如下：


如果学过 shell 的基本语法，这段脚本很容易可以看懂，我们简单了解一下改脚本做了什么：

第 3 行，/sys/class/remoteproc/remoteproc0 是加载、启动和停止固件的文件操作路径，Linux下一切皆文件，我们实际上是通过操作文件来实现对应的功能。我们查看此路径下有什么：

可以看到/sys/class/remoteproc/remoteproc0/firmware 文件的内容是 BEEP_CM4.elf，这个就是本实验 M4 固件的名字，默认情况下该文件的内容是 rproc-m4-fw，在 A7 加载 M4 固件后，此文件内容就会被修改。

第 4 行，/lib/firmware 是固件（或者固件的软链接文件）所在的路径，我们看看该路径下有什么：

可以看到，/lib/firmware 下的 BEEP_CM4.elf 文件指了/usr/local/projects/BEEP_CM4/lib/firmware/BEEP_CM4.elf，也就是/lib/firmware/BEEP_CM4.elf 文件是软连接文件，实际的文件是"
/usr/local/projects/BEEP_CM4/lib/firmware/BEEP_CM4.elf，也就是运行固件时，实际上是运行/usr/local/projects/BEEP_CM4/lib/firmware/下的固件，如下图，可以看到 BEEP_CM4.elf 文件大小是 1.9MB，同时我们注意到，在/usr/local/projects/BEEP_CM4 下有一个 fw_cortex_m4.sh 文件，此文件的内容和 STM32CubeIDE 上的 fw_cortex_m4.sh 文件内容一样：

第 5 行，固件的名字是 BEEP_CM4.elf；
第 7 行，熟悉 shell 基本指令的话，就知道/usr/bin/dirname 表示获取当前脚本的路径，(/usr/bin/readlink -f 0)表示找出软连接所指向的位置，也就是 fw_cortex_m4.sh 文件的位置，整个语句$(/usr/bin/dirname $(/usr/bin/readlink -f $0))就是指获取当前脚本文件 fw_cortex_m4.sh 所在的目录。

上图中我们已经知道脚本位与/usr/local/projects/BEEP_CM4 下了，cd $(/usr/bin/dirname $(/usr/bin/readlink -f $0))就表示进入了/usr/local/projects/BEEP_CM4 目录，该目录就是当前脚本所在的位置，如果执行 pwd 指令的话，就显示当前目录为：

/usr/local/projects/BEEP_CM4

第 9 行，如果指令的第二个字符是"start"，则执行第 10~16 行的 shell 语句。shell 的基本语法中，如果执行如下指令：

./test.sh start BEEP_CM4.elf

$0 就是./test.sh，$1 就是 start，$2 就是 BEEP_CM4.elf，大家理解器操作含义即可。我们看看 10~16 行做了什么：

2. fw_cortex_m4.sh 的使用
经过前面分析，我们大体知道 STM32CubeIDE 做了如下工作：
1）STM32CubeIDE 将 fw_cortex_m4.sh 文件传输到 Linux 文件系统的/usr/local/projects/BEEP_CM4 目录下，将 BEEP_CM4.elf 文件传输到/usr/local/projects/BEEP_CM4/lib/firmware 目录下；
2)执行 fw_cortex_m4.sh 脚本文件，将/lib/firmware/BEEP_CM4.elf 链接到/usr/local/projects/BEEP_CM4/lib/firmware/BEEP_CM4.elf，然后再将字符串 BEEP_CM4.elf 写入到文件/sys/class/remoteproc/remoteproc0 /firmware 中，再去运行或者停止 BEEP_CM4.elf 固件。

我们可以模仿 fw_cortex_m4.sh 脚本，自己去编写一个类似的脚本来实现加载、启动、停止固件。如下，我们在/lib/firmware 目录下新建一个 test.sh 脚本，脚本内容如下：

#!/bin/sh rproc_class_dir="/sys/class/remoteproc/remoteproc0"fmw_dir="/lib/firmware"cd/sys/class/remoteproc/remoteproc0if[$1=="start"]then/bin/echo-n $2>$rproc_class_dir/firmware/bin/echo-n start>$rproc_class_dir/state fiif[$1=="stop"]then/bin/echo-n stop>$rproc_class_dir/state fi

编写好脚本文件后，执行如下指令给脚本文件可读可写可执行权限：

chmod777test.sh

因为/lib/firmware 目录下已经有了 BEEP_CM4.elf，我们可以执行如下指令来加载、运行以及停止 BEEP_CM4.elf 固件：

/* 加载、运行固件 */./test.sh start BEEP_CM4.elf/* 停止运行固件 */./test.sh stop BEEP_CM4.elf