|
作者：Mentor Graphics 公司工程師Arvind Raghuraman arvind_raghuraman@mentor.com Mentor 嵌入式多核框架能消除異構(gòu)硬件和軟件環(huán)境的管理復(fù)雜性，從而簡化SoC系統(tǒng)設(shè)計 異構(gòu)多處理對于當(dāng)今的嵌入式應(yīng)用來說正變得越來越重要。片上系統(tǒng) (SoC) 架構(gòu)，例如賽靈思的 Zynq UltraScale+ MPSoC 提供包含四個 ARM Cortex-A53 內(nèi)核以及兩個 ARM Cortex-R5 內(nèi)核的強大異構(gòu)多處理基礎(chǔ)架構(gòu)。除了核心的計算基礎(chǔ)架構(gòu)外，SoC 還包含一系列豐富的硬化外設(shè) IP 和 FPGA 架構(gòu)，可實現(xiàn)靈活的設(shè)計模式，從而幫助系統(tǒng)開發(fā)人員創(chuàng)建高性能多處理系統(tǒng)。 各種軟件開發(fā)模式的出現(xiàn)使開發(fā)人員可以充分利用 SoC（例如 Zynq MPSoC）提供的多處理功能優(yōu)勢。對稱多處理 (SMP) 操作系統(tǒng)提供了必需的基礎(chǔ)架構(gòu)，能夠在多處理系統(tǒng)中的多個同構(gòu)內(nèi)核之間以對稱或非對稱方式平衡應(yīng)用工作負(fù)荷。不過，要想利用系統(tǒng)中異構(gòu)處理器提供的計算帶寬，需要使用非對稱多處理 (AMP) 軟件架構(gòu)。 AMP 架構(gòu)通常需要在 SoC 中不同處理內(nèi)核上運行的多種軟件環(huán)境（例如 Linux、實時操作系統(tǒng) (RTOS) 或裸機軟件），協(xié)同工作實現(xiàn)最終應(yīng)用的設(shè)計目標(biāo)。在典型設(shè)計中，主內(nèi)核上的軟件環(huán)境根據(jù)需要驅(qū)動一個遠(yuǎn)程內(nèi)核上的遠(yuǎn)程軟件環(huán)境，用于分擔(dān)計算任務(wù)。主處理器、遠(yuǎn)程處理器及其相關(guān)軟件環(huán)境(即它們的操作系統(tǒng)環(huán)境)可以是同構(gòu)或者異構(gòu)的。 為有效管理不同處理器上多個操作系統(tǒng)的生命周期，同時提供處理器間通信 (IPC) 基礎(chǔ)架構(gòu)以分擔(dān)計算工作負(fù)荷，需要采用經(jīng)過改善的新軟件功能和方法。 Mentor Graphics 公司的 Mentor 嵌入式多核框架是一種軟件框架，能夠為 AMP 系統(tǒng)開發(fā)人員提供兩大重要功能：用于對遠(yuǎn)程處理器及其相關(guān)軟件環(huán)境進行生命周期管理的 remoteproc 組件和 API；用于在 AMP 環(huán)境中的操作系統(tǒng)之間實現(xiàn) IPC 的 rpmsg 組件和 API。該框架為用戶提供了簡化的應(yīng)用級接口，從而消除了管理異構(gòu)硬件和軟件環(huán)境的復(fù)雜性。 讓我們詳細(xì)了解一下如何使用這種新的開發(fā)框架來管理 AMP 系統(tǒng)中的異構(gòu)計算。 兼容性和起源 在為 Mentor 嵌入式多核框架選擇合適的 API 時，對開放標(biāo)準(zhǔn)的兼容性以及在 Linux 社區(qū)中的應(yīng)用情況是重要的考量指標(biāo)。Mentor選用了 Linux 3.4.x 內(nèi)核以及更新版本中的 remoteproc 和 rpmsg API。Linux remoteproc 和 rpmsg 基礎(chǔ)架構(gòu)最初由 Texas Instruments 設(shè)計開發(fā)，并專門用于 Linux 內(nèi)核。該基礎(chǔ)架構(gòu)允許主處理器上的 Linux 操作系統(tǒng)管理遠(yuǎn)程處理器上遠(yuǎn)程軟件環(huán)境的生命周期和通信。 然而，Linux 提供的基礎(chǔ)架構(gòu)存在一些限制。 首先，Linux rpmsg 隱式地假設(shè) Linux 總是主操作系統(tǒng)，而且不支持將 Linux 作為 AMP 配置中的遠(yuǎn)程操作系統(tǒng)。 此外，remoteproc 和 rpmsg API 只能從 Linux 內(nèi)核空間獲得，沒有可用于其它操作系統(tǒng)和運行時間的等效 API 或庫。 Mentor 嵌入式多核框架是一種用 C 語言編寫的獨立庫。它能干凈地實現(xiàn)在 RTOS 或裸機軟件環(huán)境中使用的 remoteproc 和 rpmsg 功能，并具備與 Linux 中對應(yīng)的 remoteproc 和 rpmsg 的 API 級兼容性和功能對稱性。圖 1a 顯示了 Mentor 嵌入式多核框架的軟件棧圖及其在 RTOS 或裸機環(huán)境中的使用。如圖所示，該框架經(jīng)過抽象的移植層由硬件接口層和操作系統(tǒng)抽象(環(huán)境)層構(gòu)成，讓用戶能夠方便地將框架移植到其它處理器和操作系統(tǒng)。 
圖 1 – RTOS 和裸機環(huán)境中的 Mentor 嵌入式多核框架 (a)，以及 Linux 內(nèi)核中的 remoteproc 和 rpmsg (b)
圖 2 – Mentor 多核框架支持的 AMP 配置 圖 1b 顯示了 Linux 內(nèi)核中的 remoteproc 和 rpmsg 基礎(chǔ)框架。remoteproc 和 rpmsg 內(nèi)核空間驅(qū)動程序為 remoteproc 平臺驅(qū)動程序和 rpmsg 用戶設(shè)備驅(qū)動程序提供服務(wù)。remoteproc 平臺驅(qū)動程序支持遠(yuǎn)程生命周期管理；rpmsg 用戶設(shè)備驅(qū)動程序向用戶空間應(yīng)用提供 IPC 服務(wù)。 除了能在 AMP 架構(gòu)中實現(xiàn) RTOS 和裸機環(huán)境與 Linux remoteproc/rpmsg 基礎(chǔ)架構(gòu)的互操作外，Mentor 嵌入式多核框架還提供相應(yīng)的工作流程和運行時間基礎(chǔ)架構(gòu)，用于將 Linux 進行封裝并作為 AMP 配置中的遠(yuǎn)程操作系統(tǒng)啟動。圖 2 顯示了該框架支持的各種 AMP 配置。 用例與應(yīng)用 Mentor 嵌入式多核框架非常適合無監(jiān)督和有監(jiān)督的 AMP 架構(gòu)。 無監(jiān)督的 AMP (uAMP) 架構(gòu)適用于不需要對參與的操作系統(tǒng)環(huán)境進行嚴(yán)格分離的應(yīng)用。在該架構(gòu)中，參與的操作系統(tǒng)在系統(tǒng)中的處理器上本地運行。如圖 3a 所示，Mentor 嵌入式多核框架提供一種簡單有效的基礎(chǔ)架構(gòu)，其中，主（引導(dǎo)）處理器上的主軟件環(huán)境可以管理生命周期，并將計算任務(wù)分配給 SoC 中的其它計算資源。 有監(jiān)督的非對稱多處理 (sAMP) 架構(gòu)最適合需要對軟件環(huán)境和系統(tǒng)資源虛擬化進行隔離的應(yīng)用。在 sAMP 中，參與的客戶操作系統(tǒng)運行在客戶虛擬機中，而客戶虛擬機由管理程序（也稱為虛擬機監(jiān)視程序）進行管理和調(diào)度。管理程序為虛擬機提供隔離和虛擬化服務(wù)。Mentor 嵌入式多核框架使 sAMP 架構(gòu)能夠管理 SoC 中異構(gòu)計算資源的計算任務(wù)。 如圖 3b 所示，該框架有兩種應(yīng)用方式：在客戶操作系統(tǒng)環(huán)境下，進行無監(jiān)督的異構(gòu)計算資源管理；在管理程序中，進行有監(jiān)督的異構(gòu)計算資源管理，使管理程序能夠監(jiān)督客戶操作系統(tǒng)與遠(yuǎn)程環(huán)境之間的交互。 總之，Mentor 嵌入式多核框架最適合需要將計算功能按照需求分配給多處理芯片中專用內(nèi)核的應(yīng)用。對于功率受限的器件，該框架能夠根據(jù)需要開啟和關(guān)閉計算資源，實現(xiàn)最佳功率利用率。 該框架還便于將傳統(tǒng)的單核嵌入式系統(tǒng)整合到功能更強大的多處理 SoC 上。此外，該框架能夠輕松地移植針對單核芯片而開發(fā)的傳統(tǒng)軟件，以便與更新、更強大的多處理芯片上的增強系統(tǒng)功能進行互操作。 最后，該框架還有助于實現(xiàn)容錯型系統(tǒng)架構(gòu)。例如，該框架能支持處理關(guān)鍵系統(tǒng)功能的 RTOS 環(huán)境(主機)來管理負(fù)責(zé)非關(guān)鍵系統(tǒng)功能的 Linux 環(huán)境。當(dāng) Linux 子系統(tǒng)出故障時，RTOS 可重啟故障子系統(tǒng)，而且不會對關(guān)鍵系統(tǒng)功能產(chǎn)生任何不利影響。
圖 3 – Mentor 嵌入式多核框架用例，包括 uAMP (a) 和 sAMP (b) 架構(gòu) 系統(tǒng)級考慮因素 Mentor 嵌入式多核框架 API 提供所需的軟件基礎(chǔ)架構(gòu)，以管理 AMP 系統(tǒng)中的計算。然而在使用上述 API 開發(fā)應(yīng)用軟件之前，設(shè)計 AMP 系統(tǒng)必須考慮特定的系統(tǒng)級考慮因素。 在初始設(shè)計階段，您需要確定 AMP 拓?fù)浣Y(jié)構(gòu)。該框架可在星形拓?fù)洌▎蝹�主機管理多個遠(yuǎn)程機）或鏈?zhǔn)酵負(fù)洌ㄖ鳈C和遠(yuǎn)程節(jié)點鏈接在一起）中使用。當(dāng)您選擇合適的拓?fù)浣Y(jié)構(gòu)后，下一步是確定存儲器布局。應(yīng)為每個參與的操作系統(tǒng)運行時間分配存儲區(qū)域，并為操作系統(tǒng)實例之間的 IPC 分配共享存儲區(qū)域。在存儲器布局最終確定后，您需要更新框架提供的、用于反映所選存儲器架構(gòu)的特定平臺配置數(shù)據(jù)。 現(xiàn)成的操作系統(tǒng)通常假定其擁有整個 SoC，因此無法直接在無監(jiān)督的 AMP 環(huán)境中運行，因為該環(huán)境要求合作使用共享資源，并且互斥地使用非共享資源。AMP 系統(tǒng)中每個參與的操作系統(tǒng)都要進行修改，以便通過合作方式使用共享資源。例如，遠(yuǎn)程操作系統(tǒng)不應(yīng)復(fù)位和重新初始化已經(jīng)在主機環(huán)境中使用的共享全局中斷控制器；也不能修改共享時鐘樹或外設(shè)，以免導(dǎo)致沖突。這些變更通常包括對參與的操作系統(tǒng)內(nèi)核或 BSP 源文件（或二者皆有）進行修改。 下一步是執(zhí)行系統(tǒng)分區(qū)。必須在參與的操作系統(tǒng)之間對系統(tǒng)資源（例如存儲器和非共享 I/O 器件）進行分區(qū)，這樣，每個操作系統(tǒng)都只能顯示和訪問所分配的資源。為實現(xiàn)上述任務(wù)，您可以對提供給操作系統(tǒng)的平臺數(shù)據(jù)(器件和存儲器定義) 進行修改。例如，修改 Linux OS 的 Linux器件樹源文件 (DTS) 中的存儲器和器件定義；Nucleus RTOS 的平臺定義文件中的存儲器和器件定義；裸機環(huán)境中平臺專用報頭文件的存儲器和器件定義。 使用 REMOTEPROC 進行生命周期管理 在完成系統(tǒng)級設(shè)計決策以及針對參與操作系統(tǒng)的修改后，就可使用應(yīng)用軟件的 Mentor 嵌入式多核框架。該框架提供相應(yīng)的工作流程，用來封裝 Linux、RTOS 或裸機軟件映像以及所需的引導(dǎo)程序固件，從而生成 ELF 格式的遠(yuǎn)程固件映像。 遠(yuǎn)程固件 ELF 映像包含一個名為資源表的特殊區(qū)域。資源表是一個預(yù)先定義捆綁的靜態(tài)數(shù)據(jù)結(jié)構(gòu)，用戶可在這里指定遠(yuǎn)程固件所需的資源。資源表提供的一些重要定義內(nèi)容包括遠(yuǎn)程固件所需的存儲器以及遠(yuǎn)程固件所支持的 IPC 功能。主軟件環(huán)境中的 remoteproc 組件使用資源表定義來分配資源并建立與遠(yuǎn)程環(huán)境的通信。 框架主機使用 remoteproc_init API 初始化遠(yuǎn)程處理器環(huán)境。在調(diào)用時，remoteproc 主機取出遠(yuǎn)程固件映像、解碼、獲得資源表、并對其解析，以確定遠(yuǎn)程固件的資源要求。remoteproc 根據(jù)資源表定義建立遠(yuǎn)程固件所需的物理存儲器，并執(zhí)行 rpmsg/VirtIO IPC 的特定初始化功能。 在 remoteproc 完成初始化后，可使用 remoteproc_boot API 啟動相關(guān)軟件環(huán)境中的遠(yuǎn)程處理器。在調(diào)用時，找到固件映像以便在存儲器中適當(dāng)執(zhí)行，同時，遠(yuǎn)程處理器解除復(fù)位狀態(tài)以執(zhí)行該映像。remoteproc_shutdown 和 remote- proc_deinit API 允許應(yīng)用關(guān)閉遠(yuǎn)程處理器，并分別解除各類資源的初始化。(圖 5 中的偽代碼模塊給出了 remoteproc API 在主機環(huán)境中的使用實例。) 在遠(yuǎn)程環(huán)境中，啟動和關(guān)閉 API 不適用。為了對 remoteproc 組件進行初始化和解除初始化，必須使用 remoteproc_resource_init API 和 remoteproc_resource_deinit API。如欲了解在 Linux 環(huán)境中如何使用 remoteproc，敬請參見 Linux 內(nèi)核文檔。 RPMSG 和處理器間通信 一旦遠(yuǎn)程固件啟動并在遠(yuǎn)程處理器上運行，就可使用 rpmsg API 在主機與遠(yuǎn)程軟件環(huán)境之間實現(xiàn)處理器間通信。當(dāng)使用 rpmsg 時需要理解的關(guān)鍵抽象和概念如下： • 從主機角度看，rpmsg 器件代表一個遠(yuǎn)程處理器。 • rpmsg 通道是主機與遠(yuǎn)程處理器(也稱為 rpmsg 設(shè)備)之間的雙向通信通道。 • rpmsg 端點是可出現(xiàn)在 rpmsg 通道任意一側(cè)的邏輯抽象。 • 端點提供用于在主機與遠(yuǎn)程環(huán)境之間發(fā)送目標(biāo)消息的基礎(chǔ)架構(gòu)。 • 當(dāng)創(chuàng)建端點時，用戶提供唯一的端點索引或允許 rpmsg 組件為端點分配一個索引。此外，用戶提供應(yīng)用定義的回調(diào)，并將其與正在創(chuàng)建的端點關(guān)聯(lián)。 • 當(dāng)收到針對給定端點索引的消息時，rpmsg 會參考所收到的數(shù)據(jù)負(fù)荷調(diào)用相關(guān)的接收回調(diào)。 • 用戶可在 rpmsg 通道的任意一側(cè)創(chuàng)建任意數(shù)量的端點。 • 沒有明確指向目標(biāo)端點索引的消息會到達與 rpmsg 通道相關(guān)聯(lián)的默認(rèn)端點。 • rpmsg 組件利用在初始化過程中注冊的、用戶提供的回調(diào)為用戶應(yīng)用通知通道創(chuàng)建和刪除等事件。
圖 4 – rpmsg 通道和端點抽象 圖 4 所示為 rpmsg 通道和端點抽象及其使用情況。rpmsg 組件與 remoteproc 協(xié)同建立并管理主機與遠(yuǎn)程環(huán)境之間的 rpmsg 通信通道。一旦主機上的 remoteproc 啟動遠(yuǎn)程環(huán)境，遠(yuǎn)程環(huán)境上的 rpmsg 就會發(fā)送名稱服務(wù)公告。收到名稱服務(wù)公告后，主機會注冊已宣布的 rpmsg 器件，并建立 rpmsg 通道。通道建立后，在兩側(cè)調(diào)用由 rpmsg 通道創(chuàng)建的回調(diào)，通知主機和遠(yuǎn)程應(yīng)用通道已建立。 此時，主機和遠(yuǎn)程環(huán)境可利用分別針對分塊和不分塊傳輸請求的 rpmsg_sendxx API 和 rpmsg_trysendxx API 相互傳輸數(shù)據(jù)。當(dāng)遠(yuǎn)程環(huán)境調(diào)用 remoteproc_resource_deinit 時，由 rpmsg 通道刪除的回調(diào)向主機應(yīng)用通知該事件，以平穩(wěn)終止基于 rpmsg 的通信鏈路。在遠(yuǎn)程環(huán)境無法響應(yīng)的情況下，主機可選擇使用 remoteproc_shutdown API 異步地關(guān)閉遠(yuǎn)程處理器。圖 5 中的偽代碼段給出了在主機環(huán)境中 rpmsg API 與 remoteproc API 的協(xié)同使用情況。 rpmsg 組件將 VirtIO 作為共享存儲器傳輸抽象層。VirtIO 有自己的根，可用作 lguest、KVM 和 Mentor 嵌入式管理程序中客機到主機通信的 I/O 虛擬化標(biāo)準(zhǔn)。rpmsg 驅(qū)動程序使用 VirtIO 層提供的服務(wù)與對方實現(xiàn)共享存儲器通信。rpmsg 驅(qū)動程序?qū)嵗粋� rpmsg VirtIO 器件，并使用 VirtQueue 接口推送和消耗其通信另一方的數(shù)據(jù)。 用于開發(fā) AMP 系統(tǒng)的工具 AMP 應(yīng)用軟件的開發(fā)會產(chǎn)生一些獨特的挑戰(zhàn)。系統(tǒng)開發(fā)人員通常不得不同時調(diào)試異構(gòu) SoC 上部署在不同處理器的不同操作系統(tǒng)環(huán)境。采用可感知操作系統(tǒng)的統(tǒng)一調(diào)試環(huán)境不僅能改善調(diào)試體驗，還能提高生產(chǎn)力。Mentor Embedded Sourcery CodeBench 工具提供可感知所有受支持操作系統(tǒng)環(huán)境（包括Mentor Embedded Linux 和 Nucleus RTOS)的統(tǒng)一 IDE。此外，Sourcery CodeBench 還支持多種調(diào)試選項，包括用于調(diào)試 Linux 內(nèi)核空間、Nucleus RTOS 和裸機環(huán)境的 JTAG 調(diào)試；以及針對 Linux 用戶空間和 Nucleus RTOS 應(yīng)用的 GDB 調(diào)試。
在開發(fā) AMP 系統(tǒng)時，軟件特性分析工具很有用，可用來了解異構(gòu)操作系統(tǒng)上部署的各種應(yīng)用在運行時間的相互交互情況。每個操作系統(tǒng)實例通常使用一個獨立時鐘參考，而且給定操作系統(tǒng)環(huán)境中收集的任何特性分析數(shù)據(jù)都以操作系統(tǒng)本地的時基為基礎(chǔ)。Mentor Embedded Sourcery Analyzer 主機工具和 Mentor 的操作系統(tǒng)包含內(nèi)置算法，使用戶能夠以圖形方式查看和分析從統(tǒng)一時間參考的不同操作系統(tǒng)資源中收集到的跟蹤數(shù)據(jù)。該功能使用戶能夠深入了解復(fù)雜交互情況以及開發(fā) AMP 軟件時難以發(fā)現(xiàn)的時序問題。 圖 5 – 偽代碼給出了主機環(huán)境下關(guān)鍵 remoteproc 和 rpmsg API 的使用情況 開源運行時間組件 Mentor 嵌入式多核框架與 Mentor 的開發(fā)工具和操作系統(tǒng)緊密集成。它支持各種不同的基于 ARM 的 SoC 和平臺。通過使用具有 Mentor 工具和操作系統(tǒng)的框架，用戶不必從頭設(shè)計 AMP 系統(tǒng)，而是只需執(zhí)行“系統(tǒng)級考慮因素”一節(jié)中所討論的任務(wù)。用戶可利用其中一種參考配置開始 AMP 應(yīng)用的開發(fā)工作，然后對系統(tǒng)配置進行定制化處理，以滿足不同需求。 對于 AMP 系統(tǒng)設(shè)計而言，亟需一種標(biāo)準(zhǔn)化的軟件框架，使開發(fā)出的 RTOS 或裸機軟件能夠與開源 Linux 社區(qū)所采用的接口進行互操作。為滿足該需求并促進在行業(yè)中的應(yīng)用，Mentor Graphics 與賽靈思共同通過 OpenAMP 開源項目開放了 Mentor 嵌入式多核框架的運行時間組件源代碼，并提供針對 Zynq-7000 All Programmable SoC 的平臺支持。該項目目前由 Mentor Graphics 和賽靈思共同維護。 |
