针对非对称多处理系统实现更简单的软件开发
时间:01-20
来源:互联网
点击:
系统级考虑因素
Mentor 嵌入式多核框架 API 提供所需的软件基础架构,以管理 AMP 系统中的计算。然而在使用上述 API 开发应用软件之前,设计 AMP 系统必须考虑特定的系统级考虑因素。
在初始设计阶段,您需要确定 AMP 拓扑结构。该框架可在星形拓扑(单个主机管理多个远程机)或链式拓扑(主机和远程节点链接在一起)中使用。当您选择合适的拓扑结构后,下一步是确定存储器布局。应为每个参与的操作系统运行时间分配存储区域,并为操作系统实例之间的 IPC 分配共享存储区域。在存储器布局最终确定后,您需要更新框架提供的、用于反映所选存储器架构的特定平台配置数据。
现成的操作系统通常假定其拥有整个 SoC,因此无法直接在无监督的 AMP 环境中运行,因为该环境要求合作使用共享资源,并且互斥地使用非共享资源。AMP 系统中每个参与的操作系统都要进行修改,以便通过合作方式使用共享资源。例如,远程操作系统不应复位和重新初始化已经在主机环境中使用的共享全局中断控制器;也不能修改共享时钟树或外设,以免导致冲突。这些变更通常包括对参与的操作系统内核或 BSP 源文件(或二者皆有)进行修改。
下一步是执行系统分区。必须在参与的操作系统之间对系统资源(例如存储器和非共享 I/O 器件)进行分区,这样,每个操作系统都只能显示和访问所分配的资源。为实现上述任务,您可以对提供给操作系统的平台数据(器件和存储器定义) 进行修改。例如,修改 Linux OS 的 Linux器件树源文件 (DTS) 中的存储器和器件定义;Nucleus RTOS 的平台定义文件中的存储器和器件定义;裸机环境中平台专用报头文件的存储器和器件定义。
使用 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 通道和端点抽象
图 4 所示为 rpmsg 通道和端点抽象及其使用情况。rpmsg 组件与 remoteproc 协同建立并管理主机与远程环境之间的 rpmsg 通信通道。一旦主机上的 remoteproc 启动远程环境,远程环境上的 rpmsg 就会发送名称服务公告。收到名称服务公告后,主机会注册已宣布的 rpmsg 器件,并建立 rpmsg 通道。通道建立后,在两侧调用由 rpmsg 通道创建的回调,通知主机和远程应用通道已建立。
此时,主机和远程环境可利用分别针对分块和不分块传输请求的 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 接口推送和消耗其通信另一方的数据。
Mentor 嵌入式多核框架 API 提供所需的软件基础架构,以管理 AMP 系统中的计算。然而在使用上述 API 开发应用软件之前,设计 AMP 系统必须考虑特定的系统级考虑因素。
在初始设计阶段,您需要确定 AMP 拓扑结构。该框架可在星形拓扑(单个主机管理多个远程机)或链式拓扑(主机和远程节点链接在一起)中使用。当您选择合适的拓扑结构后,下一步是确定存储器布局。应为每个参与的操作系统运行时间分配存储区域,并为操作系统实例之间的 IPC 分配共享存储区域。在存储器布局最终确定后,您需要更新框架提供的、用于反映所选存储器架构的特定平台配置数据。
现成的操作系统通常假定其拥有整个 SoC,因此无法直接在无监督的 AMP 环境中运行,因为该环境要求合作使用共享资源,并且互斥地使用非共享资源。AMP 系统中每个参与的操作系统都要进行修改,以便通过合作方式使用共享资源。例如,远程操作系统不应复位和重新初始化已经在主机环境中使用的共享全局中断控制器;也不能修改共享时钟树或外设,以免导致冲突。这些变更通常包括对参与的操作系统内核或 BSP 源文件(或二者皆有)进行修改。
下一步是执行系统分区。必须在参与的操作系统之间对系统资源(例如存储器和非共享 I/O 器件)进行分区,这样,每个操作系统都只能显示和访问所分配的资源。为实现上述任务,您可以对提供给操作系统的平台数据(器件和存储器定义) 进行修改。例如,修改 Linux OS 的 Linux器件树源文件 (DTS) 中的存储器和器件定义;Nucleus RTOS 的平台定义文件中的存储器和器件定义;裸机环境中平台专用报头文件的存储器和器件定义。
使用 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 通道和端点抽象
图 4 所示为 rpmsg 通道和端点抽象及其使用情况。rpmsg 组件与 remoteproc 协同建立并管理主机与远程环境之间的 rpmsg 通信通道。一旦主机上的 remoteproc 启动远程环境,远程环境上的 rpmsg 就会发送名称服务公告。收到名称服务公告后,主机会注册已宣布的 rpmsg 器件,并建立 rpmsg 通道。通道建立后,在两侧调用由 rpmsg 通道创建的回调,通知主机和远程应用通道已建立。
此时,主机和远程环境可利用分别针对分块和不分块传输请求的 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 接口推送和消耗其通信另一方的数据。
Mentor 嵌入式 SoC 赛灵思 PSoC ARM Cortex FPGA Linux 相关文章:
- 针对异构多核的嵌入式软件解决方案(08-03)
- 热仿真加速新产品上市(06-04)
- 基于SystemC 的系统验证研究和应用(08-10)
- 模块化/KSK 线束自动化设计(06-22)
- 几分钟内核算出线束成本?(01-14)
- 从传统电路检查到先进可靠性验证的最佳实践(07-03)