AMP 为您的下一个 SoC 项目助力

　　嵌入式系统一般分为两大类：需要硬实时性能的;和不需要硬实时性能的。过去，我们不得不做出艰 抉择，即选择实时操作系统的性能还是我们钟爱的 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 开发人员青睐的主要原因。

　　图 1 — 对称多处理。SMP 核心可在多个内核上同时运行。

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

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

　　图 2 — 具有 Linux SMP 核心的 AMP

　　内核的软件(本例中是指 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 应用，无需做任何修改。