描述

嵌入式系统一般分为两大类：需要硬实时性能的；和不需要硬实时性能的。过去，我们不得不做出艰难抉择： 选择实时操作系统的性能还是我们钟爱的 Linux 系统的丰富特性，然后努力弥补不足之处?

如今，嵌入式开发人员再也不需要在二者之间艰难选择。非对称多处理 (AMP) 兼备二者的优点。几款新型片上系统 (SoC) 产品集成了多个 CPU、多种标准 I/O 外设和可编程逻辑。例如，赛灵思 Zynq-7000® All Programmable SoC 系列包含一个双核 ARM® Cortex™-A9、标准外设(例如千兆位以太网 MAC、USB、DMA、SD/MMC、SPI 和 CAN)以及庞大的可编程逻辑阵列。我们可将这些 SoC 产品作为 Linux/RTOS AMP 系统的基础，助其实现高度的灵活性。

典型的 AMP 配置在很多方面类似于基于 PCI 的系统，即 Linux 域起到主机作用，RTOS 域起到适配器作用，并有一个或多个共享存储器域用来实现两个域之间的通信。不过与 PCI 不同，AMP 配置能更方便、动态地为一个或另一个域分配资源(标准外设和自定义逻辑)。此外，Linux/RTOS AMP 系统能根据运行时间要求——例如各种外部设备的有无——动态地重新配置可编程逻辑。灵活程度通常会与建立 AMP 系统所涉及的复杂性和难度息息相关。不过请放心，Linux 开发社区已经将很多功能引入到核心，能大大简化 AMP 配置与使用。

Linux 多处理简介

就多处理而言，Linux 核心分为两种：单处理器 (UP) 核心和对称多处理器 (SMP) 核心。无论有多少个内核，UP 核心只能在单个内核上运行。AMP 系统可包含两个或更多个单处理器内核的实例。

SMP 核心可在一个内核或同时在多个内核上运行(图 1)。

可选的核心命令行参数控制系统初始化之后 SMP 核心所使用的内核数量。核心运行时，各种命令行实用程序会控制分配给核心的内核数量。能够动态地控制内核所使用的内核数量，这是 SMP 核心比 UP 核心更受 AMP 开发人员青睐的主要原因.

远程处理器框架

远程处理器 (remoteproc) 框架是一种 Linux 组件，负责启动和停止各个内核(远程处理器)，以及在 AMP 系统中加载内核的软件。例如，我们可以将图 1 所示的 SMP 系统动态地重新配置为图 2 所示的 AMP 系统，然后再使用 remoteproc 的功能配置回 SMP。

我们可以通过用户空间应用程序或系统初始化脚本完全控制重配置。重配置控制功能使用户应用可以根据系统的动态需求停止、重新加载和运行多种 RTOS 应用程序。

内核的软件(本例中是指 RTOS 和用户应用程序)从标准的可执行和可链接格式 (ELF) 文件中加载，该文件包含一个资源表的特殊段。资源表类似于 PCI 配置空间，用来描述 RTOS 需要的资源。这些资源中包括 RTOS 代码和数据所需的存储器。

追踪缓冲区

追踪缓冲区是自动在 Linux 文件系统中作为文件出现的存储器区域。顾名思义，追踪缓冲区向远程处理器提供基本追踪功能。远程处理器向缓冲区写入追踪、调试和状态消息，以便通过 Linux 命令行或定制应用进行检查。

能够动态地控制核心所使用的内核数量，这是 SMP 核心比 UP 核心更受 AMP 开发人员青睐的主要原因。

在资源表中输入条目，以请求一个或多个追踪缓冲区。尽管一般包含纯文本，但追踪缓冲区也会包含二进制数据，例如应用状态信息或警报指示。

虚拟 I/O 设备

我们还可使用资源表定义虚拟输入/输出设备 (VDEV)，这种设备主要是支持 Linux 核心与远程处理器之间消息传送的几对共享存储器队列。VDEV 定义包括用来设定队列大小的字段，以及用来在处理器之间发信号的中断。

Linux 核心可处理虚拟 I/O 队列的初始化。远程处理器上运行的软件只需要在其资源表中包含一个 VDEV 描述，然后在开始执行时使用队列；剩下的都由核心来处理。

远程处理器消息框架

远程处理器消息 (rpmsg) 框架是基于 Linux 核心的虚拟 I/O 系统的软件消息总线。该消息总线类似于局部区域子网络，单个处理器可在其中通过共享存储器创建可寻址端点和交换信息。

核心的 rpmsg 框架起到开关的作用，根据消息中包含的目的地址将消息传送到相应端点。由于消息报头包含源地址，因此可在不同处理器之间建立专用连接。

命名服务

处理器可通过向 rpmsg 框架的命名服务发送消息，以动态宣布特定服务。命名服务功能本身用途不是很大。不过，rpmsg 框架允许将服务名称关联到设备驱动程序，以支持驱动程序的自动加载和初始化。

例如，如果远程处理器宣布 dlinx-h323-v1.0 服务，那么核心可以搜索、加载和初始化与该名称关联的驱动程序。如果系统中服务被动态安装在远程处理器上，那么这样可大大简化驱动程序管理。

管理中断

中断管理有些棘手，尤其在启动和停止内核时更是如此。最终，系统需要在远程处理器启动时动态地将特定中断重定向至远程处理器域，然后当远程处理器停止时收回中断。此外，系统必须保护中断，防止其被错误配置的驱动程序误分配。简言之，必须在系统层面管理中断。

对于 Linux SMP 核心而言，这是一个常规事件，而且是 SMP 核心在 AMP 配置中更受青睐的另一个原因。远程处理器框架能方便地管理中断，只需来自设备驱动程序的最小支持。

设备驱动程序

设备驱动开发是个始终需要关注的问题，因为所需的技能组合可能无法立刻提供。幸运的是，Linux 核心的 remoteproc 和 rpmsg 框架完成大部分重活；驱动程序只需要实现几个标准驱动程序例程。功能完整的驱动程序可能只需要几百行代码。核心源代码树包含嵌入式开发人员可根据自身要求进行调整的驱动程序范例。

厂商还提供通用的开源设备驱动程序。DesignLinx Hardware Solutions 提供针对 Linux 和 FreeRTOS 的通用 rpmsg 驱动程序。由于通用驱动程序没有假定所交换消息的格式，因此嵌入式开发人员可将其用于多种 AMP 应用，无需做任何修改。

引脚内移动

核心的多处理支持并不局限于同构多处理系统(使用同一类型处理器的系统)。以上介绍的所有特性也可以用在异构系统中(具有不同类型处理器的系统)。当“在引脚内”移植已有设计时，这些多处理功能尤其有用。

新型 SoC 产品使设计人员能够方便地将各种硬件设计从印刷电路板移植到片上系统(图 3)。过去在 PCB 上作为分立处理器和组件的部分可以完全在 SoC 的引脚内实现。

例如，我们可以使用赛灵思 Zynq-7000 系列 SoC 实现图 3 中的初始 PCB 硬件架构，将其中一个 ARM 处理器作为可编程逻辑中的控制 CPU 和软处理器(例如赛灵思 MicroBlaze™ 处理器)，以替代分立处理器。我们可以使用剩余的 ARM 处理器运行 Linux SMP 核心(图 4)。

将 Linux 添加到初始设计中能够为 ARM 内核和软核处理器提供以上描述的所有标准多处理功能(例如启动、停止、重载、追踪缓冲区和远程消息)。而且，还带来丰富的 Linux 功能集，可支持多种网络接口(以太网、Wi-Fi、蓝牙)、网络服务(Web 服务器、FTP、SSH、SNMP)、文件系统

新型 SoC 产品使设计人员能够方便地将各种硬件设计从印刷电路板移植到片上系统

(DOS、NFS、cramfs、闪存存储器)以及其他接口(PCIe、SPI、USB、MMC、视频)等。这些特性能方便地实现新功能，无需对经过检验的架构做太大改动。

内核不断涌现

过去几年中，针对嵌入式市场的多核 SoC 产品不断增加，而且很适合用于 AMP 配置。例如，赛灵思 UltraScale+™ MPSoC 架构包含一个 64 位四核 ARM Cortex-A53、一个 32 位双核 ARM Cortex-R5、一个图形处理单元 (GPU) 以及多种其他外设，当然还包括有用的可编程逻辑。这为那些清楚如何驾驭实时操作系统的性能以及 Linux 核心的丰富特性集的设计人员提供了沃土。

如需了解如何设计 Linux/RTOS AMP 系统的更多详情，敬请联系DesignLinx Hardware Solutions。 赛灵思联盟计划的高级成员 DesignLinx 专门从事 FPGA 设计与支持业务，包括系统设计、原理图捕捉和电气封装/机械工程设计，以及信号完整性设计。

打开APP精彩内容

点击阅读全文