转自：http://xilinx.eetop.cn/viewnews-2647
作者:Arvind Raghuraman工程师 Mentor Graphics 公司 arvind_raghuraman@mentor.com
Mentor 嵌入式多核框架能消除异构硬件和软件环境的管理复杂性，从而简化SoC系统设计。
异构多处理对于当今的嵌入式应用来说正变得越来越重要。片上系统 (SoC) 架构，例如赛灵思的 Zynq® UltraScale+™ MPSoC 提供包含四个 ARM® Cortex®-A53 内核以及两个 ARM Cortex-R5 内核的强大异构多处理基础架构。除了核心的计算基础架构外，SoC 还包含一系列丰富的硬化外设 IP 和 FPGA 架构，可实现灵活的设计模式，从而帮助系统开发人员创建高性能多处理系统。
各种软件开发模式的出现使开发人员可以充分利用 SoC（例如 Zynq MPSoC）提供的多处理功能优势。对称多处理 (SMP) 操作系统提供了必需的基础架构，能够在多处理系统中的多个同构内核之间以对称或非对称方式平衡应用工作负荷。不过，要想利用系统中异构处理器提供的计算带宽，需要使用非对称多处理 (AMP) 软件架构。
AMP 架构通常需要在 SoC 中不同处理内核上运行的多种软件环境（例如 Linux、实时操作系统 (RTOS) 或裸机软件），协同工作实现最终应用的设计目标。在典型设计中，主内核上的软件环境根据需要驱动一个远程内核上的远程软件环境，用于分担计算任务。主处理器、远程处理器及其相关软件环境(即它们的操作系统环境)可以是同构或者异构的。
Mentor 选用 Linux 3.4.x 内核以及更新版本中的 remoteproc 和 rpmsg API。
为有效管理不同处理器上多个操作系统的生命周期，同时提供处理器间通信 (IPC) 基础架构以分担计算工作负荷，需要采用经过改善的新软件功能和方法。
Mentor Graphics 公司的 Mentor 嵌入式多核框架是一种软件框架，能够为 AMP 系统开发人员提供两大重要功能：用于对远程处理器及其相关软件环境进行生命周期管理的 remoteproc 组件和 API；用于在 AMP 环境中的操作系统之间实现 IPC 的 rpmsg 组件和 API。该框架为用户提供了简化的应用级接口，从而消除了管理异构硬件和软件环境的复杂性。
让我们详细了解一下如何使用这种新的开发框架来管理 AMP 系统中的异构计算。
兼容性和起源
在为 Mentor 嵌入式多核框架选择合适的 API 时，对开放标准的兼容性以及在 Linux 社区中的应用情况是重要的考量指标。Mentor选用了 Linux 3.4.x 内核以及更新版本中的 remoteproc 和 rpmsg API。Linux remoteproc 和 rpmsg 基础架构最初由 Texas Instruments 设计开发，并专门用于 Linux 内核。该基础架构允许主处理器上的 Linux 操作系统管理远程处理器上远程软件环境的生命周期和通信。
然而，Linux 提供的基础架构存在一些限制。 首先，Linux rpmsg 隐式地假设 Linux 总是主操作系统，而且不支持将 Linux 作为 AMP 配置中的远程操作系统。 此外，remoteproc 和 rpmsg API 只能从 Linux 内核空间获得，没有可用于其它操作系统和运行时间的等效 API 或库。
Mentor 嵌入式多核框架是一种用 C 语言编写的独立库。它能干净地实现在 RTOS 或裸机软件环境中使用的 remoteproc 和 rpmsg 功能，并具备与 Linux 中对应的 remoteproc 和 rpmsg 的 API 级兼容性和功能对称性。图 1a 显示了 Mentor 嵌入式多核框架的软件栈图及其在 RTOS 或裸机环境中的使用。如图所示，该框架经过抽象的移植层由硬件接口层和操作系统抽象(环境)层构成，让用户能够方便地将框架移植到其它处理器和操作系统。
图 1b 显示了 Linux 内核中的 remoteproc 和 rpmsg 基础框架。remoteproc 和 rpmsg 内核空间驱动程序为 remoteproc 平台驱动程序和 rpmsg 用户设备驱动程序提供服务。remoteproc 平台驱动程序支持远程生命周期管理；rpmsg 用户设备驱动程序向用户空间应用提供 IPC 服务。
除了能在 AMP 架构中实现 RTOS 和裸机环境与 Linux remoteproc/rpmsg 基础架构的互操作外，Mentor 嵌入式多核框架还提供相应的工作流程和运行时间基础架构，用于将 Linux 进行封装并作为 AMP 配置中的远程操作系统启动。图 2 显示了该框架支持的各种 AMP 配置。
图 1 – RTOS 和裸机环境中的 Mentor 嵌入式多核框架 (a)，以及 Linux 内核中的 remoteproc 和 rpmsg (b)
图 2 – Mentor 多核框架支持的 AMP 配置
用例与应用
Mentor 嵌入式多核框架非常适合无监督和有监督的 AMP 架构。
无监督的 AMP (uAMP) 架构适用于不需要对参与的操作系统环境进行严格分离的应用。在该架构中，参与的操作系统在系统中的处理器上本地运行。如图 3a 所示，Mentor 嵌入式多核框架提供一种简单有效的基础架构，其中，主（引导）处理器上的主软件环境可以管理生命周期，并将计算任务分配给 SoC 中的其它计算资源。
有监督的非对称多处理 (sAMP) 架构最适合需要对软件环境和系统资源虚拟化进行隔离的应用。在 sAMP 中，参与的客户操作系统运行在客户虚拟机中，而客户虚拟机由管理程序（也称为虚拟机监视程序）进行管理和调度。管理程序为虚拟机提供隔离和虚拟化服务。Mentor 嵌入式多核框架使 sAMP 架构能够管理 SoC 中异构计算资源的计算任务。
如图 3b 所示，该框架有两种应用方式：在客户操作系统环境下，进行无监督的异构计算资源管理；在管理程序中，进行有监督的异构计算资源管理，使管理程序能够监督客户操作系统与远程环境之间的交互。
图 3 – Mentor 嵌入式多核框架用例，包括 uAMP (a) 和 sAMP (b) 架构
总之，Mentor 嵌入式多核框架最适合需要将计算功能按照需求分配给多处理芯片中专用内核的应用。对于功率受限的器件，该框架能够根据需要开启和关闭计算资源，实现最佳功率利用率。
该框架还便于将传统的单核嵌入式系统整合到功能更强大的多处理 SoC 上。此外，该框架能够轻松地移植针对单核芯片而开发的传统软件，以便与更新、更强大的多处理芯片上的增强系统功能进行互操作。
最后，该框架还有助于实现容错型系统架构。例如，该框架能支持处理关键系统功能的 RTOS 环境(主机)来管理负责非关键系统功能的 Linux 环境。当 Linux 子系统出故障时，RTOS 可重启故障子系统，而且不会对关键系统功能产生任何不利影响。
系统级考虑因素
Mentor 嵌入式多核框架 API 提供所需的软件基础架构，以管理 AMP 系统中的计算。然而在使用上述 API 开发应用软件之前，设计 AMP 系统必须考虑特定的系统级考虑因素。
在初始设计阶段，您需要确定 AMP 拓扑结构。该框架可在星形拓扑（单个主机管理多个远程机）或链式拓扑（主机和远程节点链接在一起）中使用。当您选择合适的拓扑结构后，下一步是确定存储器布局。应为每个参与的操作系统运行时间分配存储区域，并为操作系统实例之间的 IPC 分配共享存储区域。在存储器布局最终确定后，您需要更新框架提供的、用于反映所选存储器架构的特定平台配置数据。
现成的操作系统通常假定其拥有整个 SoC，因此无法直接在无监督的 AMP 环境中运行，因为该环境要求合作使用共享资源，并且互斥地使用非共享资源。AMP 系统中每个参与的操作系统都要进行修改，以便通过合作方式使用共享资源。例如，远程操作系统不应复位和重新初始化已经在主机环境中使用的共享全局中断控制器；也不能修改共享时钟树或外设，以免导致冲突。这些变更通常包括对参与的操作系统内核或 BSP 源文件（或二者皆有）进行修改。
下一步是执行系统分区。必须在参与的操作系统之间对系统资源（例如存储器和非共享 I/O 器件）进行分区，这样，每个操作系统都只能显示和访问所分配的资源。为实现上述任务，您可以对提供给操作系统的平台数据(器件和存储器定义) 进行修改。例如，修改 Linux OS 的 Linux器件树源文件 (DTS) 中的存储器和器件定义；Nucleus RTOS 的平台定义文件中的存储器和器件定义；裸机环境中平台专用报头文件的存储器和器件定义。
该框架提供相应的工作流程，用来封装 Linux、RTOS 或裸机软件映像以及所需的引导程序固件，从而生成 ELF 格式的远程固件映像。
使用 REMOTEPROC 进行生命周期管理
在完成系统级设计决策以及针对参与操作系统的修改后，就可使用应用软件的 Mentor 嵌入式多核框架。该框架提供相应的工作流程，用来封装 Linux、RTOS 或裸机软件映像以及所需的引导程序固件，从而生成 ELF 格式的远程固件映像。
远程固件 ELF 映像包含一个名为资源表的特殊区域。资源表是一个预先定义捆绑的静态数据结构，用户可在这里指定远程固件所需的资源。资源表提供的一些重要定义内容包括远程固件所需的存储器以及远程固件所支持的 IPC 功能。主软件环境中的 remoteproc 组件使用资源表定义来分配资源并建立与远程环境的通信。
框架主机使用 remoteproc_init API 初始化远程处理器环境。在调用时，remoteproc 主机取出远程固件映像、解码、获得资源表、并对其解析，以确定远程固件的资源要求。remoteproc 根据资源表定义建立远程固件所需的物理存储器，并执行 rpmsg/VirtIO IPC 的特定初始化功能。
在 remoteproc 完成初始化后，可使用 remoteproc_boot API 启动相关软件环境中的远程处理器。在调用时，找到固件映像以便在存储器中适当执行，同时，远程处理器解除复位状态以执行该映像。remoteproc_shutdown 和 remote- proc_deinit API 允许应用关闭远程处理器，并分别解除各类资源的初始化。(图 5 中的伪代码模块给出了 remoteproc API 在主机环境中的使用实例。)
在远程环境中，启动和关闭 API 不适用。为了对 remoteproc 组件进行初始化和解除初始化，必须使用 remoteproc_resource_init API 和 remoteproc_resource_deinit API。如欲了解在 Linux 环境中如何使用 remoteproc，敬请参见 Linux 内核文档。
RPMSG 和处理器间通信
一旦远程固件启动并在远程处理器上运行，就可使用 rpmsg API 在主机与远程软件环境之间实现处理器间通信。当使用 rpmsg 时需要理解的关键抽象和概念如下：
• 从主机角度看，rpmsg 器件代表一个远程处理器。
• rpmsg 通道是主机与远程处理器(也称为 rpmsg 设备)之间的双向通信通道。
• rpmsg 端点是可出现在 rpmsg 通道任意一侧的逻辑抽象。
• 端点提供用于在主机与远程环境之间发送目标消息的基础架构。
• 当创建端点时，用户提供唯一的端点索引或允许 rpmsg 组件为端点分配一个索引。此外，用户提供应用定义的回调，并将其与正在创建的端点关联。
• 当收到针对给定端点索引的消息时，rpmsg 会参考所收到的数据负荷调用相关的接收回调。
• 用户可在 rpmsg 通道的任意一侧创建任意数量的端点。
• 没有明确指向目标端点索引的消息会到达与 rpmsg 通道相关联的默认端点。
• rpmsg 组件利用在初始化过程中注册的、用户提供的回调为用户应用通知通道创建和删除等事件。
图 4 所示为 rpmsg 通道和端点抽象及其使用情况。rpmsg 组件与 remoteproc 协同建立并管理主机与远程环境之间的 rpmsg 通信通道。一旦主机上的 remoteproc 启动远程环境，远程环境上的 rpmsg 就会发送名称服务公告。收到名称服务公告后，主机会注册已宣布的 rpmsg 器件，并建立 rpmsg 通道。通道建立后，在两侧调用由 rpmsg 通道创建的回调，通知主机和远程应用通道已建立。
图 4 – rpmsg 通道和端点抽象
图 5 – 伪代码给出了主机环境下关键 remoteproc 和 rpmsg API 的使用情况
此时，主机和远程环境可利用分别针对分块和不分块传输请求的 rpmsg_sendxx API 和 rpmsg_trysendxx API 相互传输数据。当远程环境调用 remoteproc_resource_deinit 时，由 rpmsg 通道删除的回调向主机应用通知该事件，以平稳终止基于 rpmsg 的通信链路。在远程环境无法响应的情况下，主机可选择使用 remoteproc_shutdown API 异步地关闭远程处理器。图 5 中的伪代码段给出了在主机环境中 rpmsg API 与 remoteproc API 的协同使用情况。
rpmsg 组件将 VirtIO 作为共享存储器传输抽象层。VirtIO 有自己的根，可用作 lguest、KVM 和 Mentor 嵌入式管理程序中客机到主机通信的 I/O 虚拟化标准。rpmsg 驱动程序使用 VirtIO 层提供的服务与对方实现共享存储器通信。rpmsg 驱动程序实例化一个 rpmsg VirtIO 器件，并使用 VirtQueue 接口推送和消耗其通信另一方的数据。
用于开发 AMP 系统的工具
AMP 应用软件的开发会产生一些独特的挑战。系统开发人员通常不得不同时调试异构 SoC 上部署在不同处理器的不同操作系统环境。采用可感知操作系统的统一调试环境不仅能改善调试体验，还能提高生产力。Mentor Embedded Sourcery CodeBench 工具提供可感知所有受支持操作系统环境（包括Mentor Embedded Linux 和 Nucleus RTOS)的统一 IDE。此外，Sourcery CodeBench 还支持多种调试选项，包括用于调试 Linux 内核空间、Nucleus RTOS 和裸机环境的 JTAG 调试；以及针对 Linux 用户空间和 Nucleus RTOS 应用的 GDB 调试。
在开发 AMP 系统时，软件特性分析工具很有用，可用来了解异构操作系统上部署的各种应用在运行时间的相互交互情况。每个操作系统实例通常使用一个独立时钟参考，而且给定操作系统环境中收集的任何特性分析数据都以操作系统本地的时基为基础。Mentor Embedded Sourcery Analyzer主机工具和 Mentor 的操作系统包含内置算法，使用户能够以图形方式查看和分析从统一时间参考的不同操作系统资源中收集到的跟踪数据。该功能使用户能够深入了解复杂交互情况以及开发 AMP 软件时难以发现的时序问题。
开源运行时间组件
Mentor 嵌入式多核框架与 Mentor 的开发工具和操作系统紧密集成。它支持各种不同的基于 ARM 的 SoC 和平台。通过使用具有 Mentor 工具和操作系统的框架，用户不必从头设计 AMP 系统，而是只需执行“系统级考虑因素”一节中所讨论的任务。用户可利用其中一种参考配置开始 AMP 应用的开发工作，然后对系统配置进行定制化处理，以满足不同需求。
对于 AMP 系统设计而言，亟需一种标准化的软件框架，使开发出的 RTOS 或裸机软件能够与开源 Linux 社区所采用的接口进行互操作。为满足该需求并促进在行业中的应用，Mentor Graphics 与赛灵思共同通过 OpenAMP 开源项目开放了 Mentor 嵌入式多核框架的运行时间组件源代码，并提供针对 Zynq-7000 All Programmable SoC 的平台支持。该项目目前由 Mentor Graphics 和赛灵思共同维护。