4. SoC 双核系统与核间多任务通信设计

本章详细介绍 AMP 架构下 SoC 核系统的设计和核间任务通信的实现方法。首

先，进行双核系统的搭建并完成设备驱动的移植；然后，进行基于共享内存的通信模

块设计；最后，针对系统不同通信任务的要求，提出多任务通信的实现方案。

4.1 双核系统设计与实现

4.1.1 Linux 实时系统搭建

（1） Xenomai 实时补丁安装

机器人控制系统需要具有强实时性能力，在运行时必须保证运动控制相关的任

务调度和数据通信的实时处理和响应。Linux 系统因支持内核抢占、中断屏蔽和优先

级抢占调度等机制，无法提供严格的强实时性能。Linux 系统的实时性优化有两种方

法，分别为 Linux 内核源码改进和 Linux 双内核扩展。其中，内核改进法方便用户进

行指定方向的性能优化，但存在工作量大，改造难度高等问题。

因此，本文通过 Xenomai 对 Linux 系统进行拓展，实现双内核实时系统，即满足

系统使用要求，同时提高了开发效率。Xenomai 采用 Adeos(Adaptive Domain

Environment for Operating System)技术保证硬实时的拓展，双内核架构如图 4.1 所示。

在采用 Adeos 的双核架构中，Adeos 主要完成域的调度、中断和域的管理等工

作。在 Adeos 架构中设置了域的优先级，Xenomai 域要高于普通的 Linux 域。因此，

当系统接收到中断信号时，

Adeos 将中断分配给 Xenomai 进行处理；只有当 Xenomai

域的任务执行完成后，

Linux 域中的任务才会继续执行。通过上述调度方法，Adeos

保证了 Xenomai 域的优先级，从而保证了任务的实时处理。如图 4.2 所示，本文使用

Linux 4.9.0 版本内核和 Xenoma 3.0.7 实现实时系统的搭建。

为了保证 Xenomai 正确使用，表 4.1 中列出内核配置中重要的 Xenomai 部分功

能项。其中，内核需要开启 Xenomai 相关的服务项，同时关掉与实时性功能相冲突

的内核选型，保证系统的正常运行。

在 Linux+Xenomai 系统搭建完成后，验证 Xenoma 是否安装成功。在 Linux 启动

完成后，通过 dmesg |grep I-pipe 和 dmesg |grep Xenomai 命令查看安装状态。如图 4.3

所示，系统完成 Xenomai 实时补丁的安装。

（2） Linux 设备驱动移植

基于 SoC 关键通信接口设计，在 Linux 系统下完成对外设驱动的移植，保证系

统设备的正确使用，实现平台对外通信。如图 4.4 所示，Linux 4.9.0 内核使用总线架

构的设备模型。

在总线架构的设备模型中，系统的设备和驱动是分离的，使用总线机制对二者进

行匹配。总线设备模型为系统的驱动移植提供了一致性接口，简化了移植流程，提高

了开发效率。

进行 SoC 平台通信接口设备的驱动移植，具体分为两种方法：

（1）当内核提供该设备驱动时，直接使用内核中的驱动。

（2）对于内核中不提供驱动的设备，为其设计驱动程序并进行移植。

首先，通过查看内核 config 配置文件，Linux-4.9.0 内核提供千兆以太网、USB

HUB 和 UART 的设备驱动支持。因此采用方法（1）进行驱动移植，具体如下：使

用 make menuconfig 命令开启内核配置；将设备驱动配置为静态加载，实现系统启

动时驱动自加载功能；使用 arm-linux-gcc 完成 zImage 的编译生成。如图 4.5 所

示，在使用 zImage 完成系统启动后，通过 dmesg 命令查看内核日志，千兆以太

网、USB HUB 和 UART 的驱动程序已完成注册，设备可以正常使用。

Linux-4.9.0 内核中不提供 AX88772B 网卡芯片的驱动程序，USB 扩展的百兆以

太网接口无法直接使用，因此采用方法（

2）进行 AX88772B 网卡驱动程序的移植。

出于减小开发难度和节约开发时间的目的，本文使用AX88772B官方驱动源码，

并在其基础上根据平台功能需求进行相应设计。通过分析，AX88772B 在使用中，通

过外部存储器保存用户写入的 PHY 芯片 MAC（Media Access Control Address）地址，

进而完成驱动程序注册。为了满足系统快捷化和多样化的配置需求，本文提出一种基

于 AX88772B 芯片的 MAC 地址动态设置方法。具体方法为：将用户自定义 MAC 地

址预先存储在 Flash 设备中；驱动程序在注册中，如果未检测到外部存储器，则从

Flash 中读取用户 MAC 地址，完成注册。如图 4.6 所示，完成 AX88772B 驱动程序

的修改，并在 Linux 环境下生成内核驱动模块，方便用户根据使用情况进行动态加

载。

如图 4.7 所示，系统加载 asix.ko 内核模块，驱动在注册过程中通过 flash 为两个

AX88772B 网卡分配 MAC 地址，网卡驱动移植成功。

4.1.2 伺服裸机系统构建

在 CPU1 上搭载伺服裸机系统需要完成以下三部分工作：Linux 系统在运行时将

CPU 使用数量设置为 1；CPU0 完成 CPU1 伺服应用程序的加载；CPU0 完成 CPU1

的唤醒。

Linux 系统在启动阶段，默认使用 SMP 对称处理模式，同时对两个 CPU 进行管

理，协调 CPU 之间的相关工作。因此，在使用 AMP 架构时，需要限制 Linux 系统

只占用 CPU0，CPU1 预留用于伺服裸机系统。Linux 启动过程中，内核文件根据环

境变量 bootargs 对系统进行相应配置，用户可以通过修改变量 bootargs 实现 CPU 使

用数量的指定。变量 bootargs 的生成分为直接指定法和 Bootloader 生成法两种方式。

其中，直接指定法是在内核配置过程中设置 bootargs，这种方法保证 bootargs 在重新

配置前的唯一性和有效性；Bootloader 生成法是在 Bootloader 文件中设置 bootargs，

并在 Bootloader 执行完毕后将其传递给内核。这种方法提供了用户修改 bootargs 的

可能性和快捷性，有利于软件的开发和维护。本文采用 Bootloader 生成法。在

Bootloader 启动过程中对 bootargs 进行动态配置和保存，将 Linux 系统使用的 CPU

数量设置为 1，从而保证 CPU1 的空闲状态。环境变量 bootargs 值配置如表 4.2 所示。

在保证 CPU1 处于空闲状态后，CPU0 需要完成伺服应用程序 CPU1_APP 的加

载。CPU1_APP 的加载工作是将应用程序写入用户指定的内存空间中。Xilinx 为 SoC

加载裸机程序提供了两种实现方法：第一种是使用 Jtag 烧写器将 CPU1_APP 写入内

存。此方法需要使用到外部烧写器，而且只能实现程序的单次加载，因此适用于系统

开发和调试阶段。第二种方法是使用 Xilinx SDK 工具将 CPU1_APP 集成到 Bootloader

中形成 BOOT.bin 文件；系统启动时执行 BOOT.bin 文件，自动寻找 CPU1_APP 并将

其加载到指定内存中。第二种方法不需要烧写器，加载操作方便；但是，多文件集成

的加载方式破坏了伺服应用程序的独立性，不利于后续软件的单独更新。

本文提出一种基于 Bootcmd 环境变量的应用程序加载方法。Bootcmd 是

Bootloader 的一种环境变量，保存了 Bootloader 在启动后执行的指令操作。通过在

Bootloader 启动阶段，对 Bootcmd 进行动态设置，添加加载 CPU1_APP 程序的指令

操作并保存。如图 4.8 所示，平台在复位操作后，Bootloader 会执行 Bootcmd 中的命

令，将 CPU1_APP 加载到指定内存中。本方法同样适用于 FPGA 烧写文件的动态加

载，有效保证了用户文件的独立性。

Zynq 7020 SoC 在 AMP 架构下，CPU1 在 SoC 上电后首先执行芯片固件程序进

入休眠状态。此时，必须通过 CPU0 才能将 CPU1 唤醒。基于 Xilinx 提供的 CPU1 唤

醒方法，在进行 CPU1 伺服软件的重运行操作时，需要将双系统进行复位，不满足

运动控制系统的使用要求。

因此，本文提出一种针对 SoC AMP 架构下的 CPU1 可单独重运行的方法。方法

的实现流程如下：（1）系统启动阶段，CPU0 完成 CPU1_APP 的加载；

（2）系统启动完成后，CPU0 将一段可实现 CPU1 程序跳转的指令写入地址 0x0 的内存中；

（3） CPU0 中执行 CPU1 的复位操作；

（4）CPU1 重启后，执行地址 0x0 处的跳转指令，

跳转到 CPU1_APP 加载地址

（5）CPU1 执行 CPU1_APP，伺服系统重运行完成。

基于图 4.9 所示方法，完成 CPU1 程序的加载和运行，实现伺服系统的搭建。

4.2 核间通信模块设计

基于双核间多任务通信需求，本文采用共享内存 OCM 作为通信媒介，并进行如

下通信模块设计：共享内存的管理方法、核间信号量设计和消息邮箱设计。

4.2.1 共享内存的管理方法

共享内存是双核间任务通信的物理介质，用于保存通信数据。本文采用 SoC 芯

片内部的 256K 片上内存作为共享内存，其在 4G 寻址空间的地址范围为

0xFFFC0000~0xFFFFFFFF。片上共享内存 OCM 在 SoC 芯片启动过程中，会被用于

系统启动文件的加载和运行；系统启动完成后，OCM 内部数据并不为空。因此，在

使用 OCM 进行任务通信时，为了保证 OCM 中数据的安全性和一致性，需要进行如

下操作：

（1）机器人控制程序开始运行时，Linux 系统完成 OCM 访问申请并对 OCM 进

行初始化；

（

2）每次完成伺服系统重运行后，Linux 系统需要对 OCM 进行初始化；

（

3）机器人控制程序运行结束时，Linux 系统关闭内存映射，释放共享内存。

针对以上操作，设计并实现了用于 Linux 系统访问 OCM 的三个接口函数，分别

为：System_Ocm_Req()、System_Ocm_Init()和 System_Ocm_Free()，函数功能依次为

OCM 申请、OCM 初始化和 OCM 释放。

在 Linux 系统中，用户进程无法同裸机程序一样直接对物理内存进行访问。为了

保证用户进程对共享内存的快速访问，System_Ocm_Req()函数通过内存映射方法

（Memory Map，简称 MMAP），完成共享内存的申请操作。MMAP 是 Linux 系统下

的一种系统调用，其功能是将一个文件或者其他对象映射到进程的地址空间。如图

4.10 所示，System_Ocm_Req()中使用 MMAP 完成 256KB 大小的 OCM 物理内存空

间的访问申请。申请成功后，System_Ocm_Req()函数返回一个基地址指针，用户进

程通过指针方式对 OCM 进行读写操作。

System_Ocm_Init()函数主要完成对 OCM 的状态检查，读写校验和擦除。状态检

查中，Linux 访问 OCM 状态寄存器并判断 OCM 是否存在通信错误，如果存在错误

则对其进行复位操作；如果状态正常，则进行读写校验。读写校验中，通过向 OCM

写入用户测试数据，写入完成后将 OCM 中数据读出，比较写读前后数据的一致性。

如果读写校验成功，对 OCM 进行擦除操作，保证双核系统通信的安全性；否则，表

明 OCM 校验失败，Linux 系统进行相应的出错处理。

在机器人控制软件运行结束时，为了保证系统的安全性，需要关闭 OCM 在进程

空间中的映射，此时通过 System_Ocm_ Free ()函数实现。System_Ocm_ Free ()中通过

使用 munmap()系统调用，实现映射关系的解除，完成 OCM 的释放。如图 4.11 所示，

Linux 在任务执行阶段，对 OCM 的进行有序访问。

4.2.2 核间信号量设计

为了保证双核对 OCM 数据访问的互斥性和一致性，引入信号量设计思想，并根

据双核间任务通信的使用要求完成核间信号量的设计。信号量是一种用于多进程（或

线程）情况下，避免共享资源被不同对象同时访问的保护机制[44]。采用信号量同步

机制时，进程（或线程）会获取一个非负整数的信号量，表示共享资源的访问状态。

信号量非零时，表示有空闲共享资源，允许进程（或线程）访问；信号量为零时，表

示共享资源为空，此时进程（或线程）将处于等待状态。如果共享资源数量大于 1，

称为计数信号量（Counting semaphore）；如果共享资源数量为 1，信号量只有 0 或 1

两种状态，称为二进制信号量（binary semaphore）。

本文设计了二进制的核间信号量，并根据双核间任务通信时序，对核间信号量的

访问进行约束。核间信号量表示 OCM 数据区的访问状态，具体定义如表 4.3 所示。

其中，核间信号量为 1 时，表示 OCM 数据区处于空闲，可以发起任务通信；核间信

号量为 0 时，表示 OCM 数据处于忙状态，任务通信正在进行。如果信号量出现为其

他状态，表明双核系统在任务通信过程中发生通信错误。

在双核间任务通信开始前，Linux 系统对信号量进行初始化，将其设置为 1。在

双核间任务通信阶段，对信号量进行以下操作：

（1）双核系统对信号量均有可读/可写权限，若读写操作同时发生时，读操作优

先权高于写操作优先权。

（2）双核系统任务通信阶段，进行“CPU0 读-CPU0 修改-CPU1 读-CPU1 修改”

顺序的信号量访问。

其中，（1）保证了在任务通信过程中，双核系统可以根据通信状态对信号量进行

设置；在访问优先级设置上，读操作高于写操作，当双核系统同时对信号量进行读写

操作时，保证信号量先被读取，避免通信状态的丢失。（

2）设置了通信过程中双核系

统对信号量的访问顺序。在双核间任务通信时，通信由 Linux 系统先发起，此时系统

读取信号量并判断其状态，当信号量为 1 时开始访问 OCM；当信号量为 0 时，表示

任务通信已处于进行状态。图 4.12 表示双核系统任务通信阶段的信号量状态切换。

在 linux 系统完成 OCM 访问后，将信号量设置为 0。伺服系统持续读取信号量，当

信号量为 1 时，表示未发生通信；当信号量为 0 时，表示通信正在进行，伺服系统开

始访问 OCM。当伺服系统完成 OCM 访问后，将信号量重新设置为 1，表示 OCM 处

于空闲状态。

4.2.3 数据消息邮箱设计

双核系统任务通信阶段，需要支持多种类型数据通信，因此采用消息邮箱实现数

据传输。消息邮箱是一种任务间的数据通信方法，设计简单且系统开销少[45]。系统

任务将通信数据打包处理后发送给邮箱，邮箱接收到数据邮件后，根据邮箱状态将邮

件转发至其他任务。针对多轴运动控制的使用要求和邮箱通信的特点，本文设计两种

邮箱通信方式，分别为固定长度邮箱通信和可变长度邮箱通信。

固定长度邮箱通信中，邮件数据长度固定，系统可根据通信数据的使用要求设置

为 8/16/32/64 位。采用固定长度邮箱进行任务通信时，在双核系统初始化阶段，需要

对邮箱地址进行设置，保证双核系统对同一邮箱的访问。

可变长度邮箱通信时，邮件内容为通信数据帧，数据帧长度不定。为了保证邮件

的正确解析，双核系统需要对数据帧进行统一设置。因此，设计一种支持读写命令和

可变数据长度的数据帧格式，帧结构如表 4.4 所示。邮件数据帧的数据采用 32 位对

齐方式，方便双核系统进行数据帧的保存和解析。同时，在双核系统初始化阶段，需

要对邮箱地址进行设置，保证双核系统对同一邮箱的访问。

为固定长度和可变长度两种邮箱通信方式设计不同的接口函数，分别为

DRV_Control()和 DRV_ASYControl()，函数的具体功能定义如表 4.5 和表 4.6 所示。

信迈提供ZYNQ+LINUX+Xenomai+运动控制系统实时系统移植方案。