支持MIPS 架構(gòu)的輕量型開源鴻蒙系統(tǒng)移植

王一泠，吳 琦，安軍社

（1.中國科學院國家空間科學中心 復雜航天系統(tǒng)電子信息技術(shù)重點實驗室，北京 100190；2.中國科學院大學 計算機科學與技術(shù)學院，北京 100049）

0 概述

航天型號嵌入式軟件固化在航天星載計算機中，與硬件關(guān)系密切，協(xié)同完成特定功能［1］?？臻g環(huán)境的復雜性導致航天器軟硬件故障發(fā)生的可能性隨著系統(tǒng)的復雜程度激增［2］，同時航天載荷需要不間斷地采集處理空間實時數(shù)據(jù)并對海量歷史數(shù)據(jù)進行查詢［3］，當軟件任務(wù)啟動后，就不能直接對航天器嵌入式設(shè)備進行維護［4］。

為了提高系統(tǒng)可靠性，除了常規(guī)應(yīng)用星載系統(tǒng)備份冗余等機制［2］外，空間數(shù)據(jù)系統(tǒng)咨詢委員會（the Consultative Committee for Space Data Systems，CCSDS）高級在軌系統(tǒng)標準定義的分布式架構(gòu)也具有一定參考意義［5］。將這種分布式架構(gòu)應(yīng)用在星載計算機系統(tǒng)上，使得星載地球敏感器、磁強計、太陽敏感器、星敏感器、熱控傳感器等通過導線與接插件連接低成本且具備OS 的輕型航天計算終端，再通過終端與具有處理海量數(shù)據(jù)和復雜任務(wù)能力的高性能中心計算機通信。當終端設(shè)備出現(xiàn)不可恢復的故障時，因其無需對數(shù)據(jù)進行保存，所以不會對星載數(shù)據(jù)中心計算機產(chǎn)生影響，在有效降低成本的同時也提高了系統(tǒng)整體可靠性。作為系統(tǒng)典型節(jié)點之一的航天器控制終端［5］是一種類瘦終端［6-8］的宇航級終端，具有小體積、低功耗、輕量型的特點，并具備OS、CPU 及運算處理能力，能夠提供I/O 設(shè)備接口以及與服務(wù)器端的網(wǎng)絡(luò)通信等功能，適用于以數(shù)據(jù)、服務(wù)器為中心的分布式計算模式，且因終端具備OS，能夠通過統(tǒng)一的接口實現(xiàn)軟硬件解耦，從固化在硬件的定制化嵌入式軟件轉(zhuǎn)向針對航天應(yīng)用需求、快速迭代升級的軟件［9］，并具有多任務(wù)處理能力和通過配置適應(yīng)多協(xié)議環(huán)境的能力。鑒于這些優(yōu)勢，航空航天領(lǐng)域的類瘦終端分布式架構(gòu)應(yīng)用具有廣闊前景，但目前宇航級終端處理器上輕量且自主可控的操作系統(tǒng)缺失成為這種分布式架構(gòu)在國內(nèi)航天領(lǐng)域部署應(yīng)用的瓶頸。

對國外的軟硬件平臺長期依賴，致使系統(tǒng)和數(shù)據(jù)不自主可控的問題日益顯現(xiàn)［10］，發(fā)展自主CPU 與操作系統(tǒng)，構(gòu)建自主可控的信息技術(shù)體系，成為航天裝備發(fā)展的目標［11］。美國風河公司推出的VxWorks嵌入式實時操作系統(tǒng)（Real-Time Operation System，RTOS）具有高實時性、低功耗、高性能、可裁剪等特點［12-14］，被廣泛應(yīng)用于國內(nèi)航天型號任務(wù)。OpenHarmony 作為國產(chǎn)操作系統(tǒng)支持多內(nèi)核，可在小型資源受限的設(shè)備上選擇以LiteOS-M 為內(nèi)核的輕量型實時子系統(tǒng)，具有實時性高、可靠性高、裁剪體積小的特點［15-17］，且具有豐富的功能組件，相較于VxWorks 可被裁剪得更小以適配資源更為受限的控制終端。2022 年，深圳軟通動力信息技術(shù)股份有限公司［18］實現(xiàn)了龍芯自研指令集LoongArch 架構(gòu)的龍芯2K1000LA 處理器與開源鴻蒙系統(tǒng)的兼容適配，但其適配的是基于OpenHarmony 多內(nèi)核之一的Linux 內(nèi)核，而非輕量型實時內(nèi)核LiteOS-M。在目前OpenHarmony LiteOS-M 內(nèi)核實時系統(tǒng)僅支持ARM、RISC-V 等架構(gòu)的情況下，對于該公司專為航天空間應(yīng)用研制的LS1J 與LS1C 等高可靠性、低功耗、輕量型熱控處理器芯片，因采用的是龍芯CPU 原指令系統(tǒng)MIPS 架構(gòu)［19］，尚未被開源鴻蒙系統(tǒng)支持。

本文對開源鴻蒙輕量型LiteOS-M 內(nèi)核與MIPS體系結(jié)構(gòu)進行介紹與分析，針對我國航空航天領(lǐng)域類瘦終端的輕量型實時操作系統(tǒng)的缺失與信息技術(shù)體系不完全自主可控的問題，提出支持MIPS 架構(gòu)的OpenHarmony 輕量實時系統(tǒng)移植方案，并在MIPS 架構(gòu)宇航級控制終端龍芯LS1J 與LS1C 硬件平臺上驗證系統(tǒng)適配的可行性。

1 相關(guān)技術(shù)

1.1 OpenHarmony 多內(nèi)核技術(shù)

OpenHarmony 采用多內(nèi)核設(shè)計，利用內(nèi)核抽象層（Kernel Abstraction Layer，KAL）屏蔽多內(nèi)核差異，對系統(tǒng)上層提供基礎(chǔ)的內(nèi)核能力，包括進程/線程管理、內(nèi)存管理、文件系統(tǒng)、網(wǎng)絡(luò)管理和外設(shè)管理等。

OpenHarmony 支持輕量實時系統(tǒng)、小型系統(tǒng)和標準系統(tǒng)3 種系統(tǒng)類型，可針對不同應(yīng)用場景與硬件資源選用合適的系統(tǒng)內(nèi)核。輕量實時子系統(tǒng)LiteOS-M 內(nèi)核面向MCU 類處理器，適用于ARM Cortex-M 平臺，是開源鴻蒙面向IoT 領(lǐng)域資源極小設(shè)備的實時系統(tǒng)，應(yīng)用在傳感器終端及穿戴類設(shè)備上。小型系統(tǒng)LiteOS-A 內(nèi)核適用于ARM Cortext-A平臺，是支持MMU 的非實時系統(tǒng)，要求應(yīng)用設(shè)備最小內(nèi)存達到1 MB 以上，應(yīng)用于智能家居領(lǐng)域的IP Camera、路由器等終端。標準系統(tǒng)Linux 內(nèi)核是基于安卓開放源代碼項目（Android Open Source Project，AOSP）進行改良的分時操作系統(tǒng)，要求應(yīng)用設(shè)備最小內(nèi)存達到128 MB 以上，可以提供增強的交互能力及硬件資源合成能力，應(yīng)用于高端冰箱顯示屏、平板等智能終端。

由于星載小型化控制終端資源十分受限且對實時性要求較高，因此選用開源鴻蒙以LiteOS-M 為內(nèi)核的輕量實時子系統(tǒng)完成MIPS 架構(gòu)適配。

LiteOS-M 是開源鴻蒙輕量型操作系統(tǒng)內(nèi)核，自下而上由硬件抽象層（Hardware Abstraction Layer，HAL）、內(nèi)核功能層、增強組件層和標準應(yīng)用接口層組成。LiteOS-M 內(nèi)核架構(gòu)［15］如圖1 所示。

圖1 LiteOS-M 內(nèi)核架構(gòu)Fig.1 LiteOS-M kernel architecture

1）HAL。HAL 屏蔽了硬件平臺的差異，給上層提供硬件無關(guān)的統(tǒng)一操控接口，實現(xiàn)系統(tǒng)與芯片的解耦，具有可移植性。系統(tǒng)移植主要是HAL 移植，包括體系結(jié)構(gòu)抽象層、變體抽象層與平臺抽象層。體系結(jié)構(gòu)抽象層即針對不同處理器的不同體系結(jié)構(gòu)，如ARM、MIPS 系列等，對中斷異常及上下文切換進行差異屏蔽；變體抽象層指該類處理器所具有的特殊性，包括Cache、MMU、FPU 等；平臺抽象層指對當前系統(tǒng)的硬件平臺進行抽象，包括平臺啟動、芯片配置、外設(shè)I/O 寄存器訪問以及中斷控制等［20］。實現(xiàn)該層的函數(shù)可根據(jù)實際的功能需求調(diào)用板級支持包（Board Support Package，BSP）中的函數(shù)。

2）基礎(chǔ)內(nèi)核。基礎(chǔ)內(nèi)核提供任務(wù)管理、內(nèi)存管理、時間管理、中斷控制、進程間通信（Inter-Process Communication，IPC）等功能。移植工作的基本任務(wù)是適配系統(tǒng)內(nèi)核與硬件相關(guān)部分的功能，保障系統(tǒng)內(nèi)核基礎(chǔ)功能的完整性。

3）內(nèi)核功能增強組件層。配置組件啟用相應(yīng)功能，LiteOS-M 內(nèi)核可配置包括文件系統(tǒng)、網(wǎng)絡(luò)與調(diào)測工具等組件。另外，可依據(jù)移植平臺應(yīng)用場景配置低功耗框架組件來降低功耗，配置Trace 回溯組件與ExcHook 組件輔助開發(fā)工作。

4）KAL。內(nèi)核抽象層向上層應(yīng)用層提供CMSIS、POSIX 標準接口支持，對內(nèi)核提供功能抽象封裝，屏蔽多內(nèi)核差異。

1.2 MIPS 架構(gòu)

1.2.1 MIPS 與龍芯

MIPS 作為最早的商業(yè)精簡指令集計算機（Reduced Instruction Set Computer，RISC）設(shè)計架構(gòu)芯片之一，其機制是盡量利用軟件避免流水線中的數(shù)據(jù)相關(guān)問題，與復雜指令系統(tǒng)計算結(jié)構(gòu)相比設(shè)計周期更短［21］。

中國科學院計算技術(shù)研究所購買了MIPS 指令授權(quán)，自主研發(fā)了低功耗、低成本和完全自主知識產(chǎn)權(quán)的龍芯系列CPU，主要應(yīng)用于嵌入式防火墻、嵌入式網(wǎng)關(guān)等低端嵌入式領(lǐng)域以及航空航天等特殊應(yīng)用環(huán) 境。2020 年，龍芯團 隊［22-23］獨立研 制LoongArch龍架構(gòu)。MIPS 與LoongArch 架構(gòu)都是基于RISC 設(shè)計的處理器架構(gòu)，但在指令集、寄存器約定、存儲器地址映射、中斷及異常、指令集擴展與執(zhí)行效率等方面存在較大差異。目前，支持LoongArch 的龍芯3A500 處理器芯片已經(jīng)成功量產(chǎn)，但在航空航天領(lǐng)域，仍舊大量使用龍芯處理器原兼容指令系統(tǒng)MIPS架構(gòu)的成熟產(chǎn)品。

1.2.2 MIPS 架構(gòu)寄存器

MIPS 架構(gòu)處理器通常具有通用寄存器、特殊寄存器、CP0 協(xié)處理器3 種寄存器類型。在通用寄存器中，a0～a3 一般用來保存函數(shù)形參，s0～s7 保存靜態(tài)數(shù)據(jù)，t0～t9 保存臨時數(shù)據(jù)。R28（GP）保存全局指針用于MIPS 小數(shù)據(jù)區(qū)變量的訪問［24］。R29（SP）作為堆棧指針寄存器，指向系統(tǒng)主堆?；蛉蝿?wù)棧。R31（RA）保存函數(shù)返回地址。特殊寄存器HI/LO 用于存儲整數(shù)乘除和累加計算操作的中間結(jié)果。PC 寄存器對程序員透明不可用，當發(fā)生精確異常時將當前地址記錄在實際的寄存器EPC 中。MIPS 架構(gòu)CP0 協(xié)處理器提供的重要系統(tǒng)控制寄存器名稱與功能如表1 所示。

表1 MIPS 架構(gòu)CP0 協(xié)處理器重要寄存器及其功能Table 1 Important registers and their functions of MIPS architecture CP0 coprocessor

1.3 關(guān)鍵技術(shù)分析

系統(tǒng)移植適配工作主要是針對HAL、基礎(chǔ)內(nèi)核硬件相關(guān)部分的移植。開源鴻蒙不支持龍芯處理器的MIPS 架構(gòu)，而MIPS 架構(gòu)與LiteOS-M 內(nèi)核支持的ARM、RISC-V 架構(gòu)之間又具有較大差異，因此對于新的體系結(jié)構(gòu)，硬件抽象層的建立具有一定難度。架構(gòu)移植工作需要根據(jù)LiteOS-M 內(nèi)核功能、工程構(gòu)建、MIPS 架構(gòu)與龍芯硬件平臺的特點，設(shè)計包括引導程序啟動加載、系統(tǒng)任務(wù)管理、上下文切換、啟動任務(wù)調(diào)度、異常與中斷處理、系統(tǒng)時鐘6 個關(guān)鍵執(zhí)行環(huán)節(jié)。除此之外，移植工作還需完成和硬件處理器存儲資源適配的內(nèi)核裁剪、架構(gòu)工具鏈搭建與BSP開發(fā)等工作。

2 系統(tǒng)MIPS 架構(gòu)移植設(shè)計方案

下面對加載程序引導、任務(wù)管理、上下文切換、任務(wù)調(diào)度啟動、異常與中斷處理、系統(tǒng)時鐘6 個移植關(guān)鍵環(huán)節(jié)給出設(shè)計方案與實現(xiàn)流程。

2.1 加載程序引導

BootLoader 引導代碼是操作系統(tǒng)運行前執(zhí)行的一段匯編啟動程序，幫助系統(tǒng)完成啟動前的軟硬件初始化，為最終引導操作系統(tǒng)提供合適的環(huán)境。移植引導代碼首先需要指定硬件FLASH 偏移位置的異常入口并初始化啟動時異常處理向量，確保在啟動出錯時正確調(diào)用異常處理程序，同時設(shè)置主堆棧（SP）、全局指針寄存器（GP）保證能夠訪問到主堆棧與MIPS 架構(gòu)特有的.sdata 小數(shù)據(jù)區(qū)。接著初始化通用寄存器與CP0 協(xié)處理器，完成必要的硬件初始化后，再將.data 段從FLASH 中搬運到SRAM 并清空未初始化的全局變量.bss 段。最后跳轉(zhuǎn)至系統(tǒng)初始化入口。引導程序設(shè)計流程如圖2 所示。

圖2 引導程序設(shè)計流程Fig.2 Design process of guided program

2.2 任務(wù)管理

任務(wù)管理功能是航天嵌入式實時操作系統(tǒng)的關(guān)鍵組成部分，是整個系統(tǒng)安全、可靠、高效運行的基礎(chǔ)。任務(wù)管理包括任務(wù)的創(chuàng)建、刪除、延時、狀態(tài)控制與轉(zhuǎn)換、優(yōu)先級配置等功能。OpenHarmony 輕量實時系統(tǒng)中每個任務(wù)都是執(zhí)行程序的一個實例，都有唯一的TaskID 與LosTaskCB 任務(wù)控制塊描述符與之對應(yīng)。LosTaskCB 結(jié)構(gòu)體標識了任務(wù)在生命周期內(nèi)的運行情況。由于航天任務(wù)通常具有嚴格的實時性要求，在多任務(wù)并發(fā)且單核的情況下，內(nèi)核采用優(yōu)先級搶占式調(diào)度機制引起任務(wù)上下文發(fā)生切換，避免任務(wù)因為等待或者競爭資源而出現(xiàn)延遲或丟失的情況。

在OpenHarmony 實時系統(tǒng)LiteOS-M 內(nèi)核中，任務(wù)共有32 個優(yōu)先級（0～31），優(yōu)先級數(shù)值越低對應(yīng)優(yōu)先級別越高，高優(yōu)先級的任務(wù)可以搶占低優(yōu)先級任務(wù)當前占有的CPU。在發(fā)生任務(wù)調(diào)度時，優(yōu)先執(zhí)行任務(wù)就緒隊列中最高優(yōu)先級的任務(wù)。任務(wù)就緒隊列可以方便地支持任務(wù)基于優(yōu)先級進行調(diào)度。如圖3所示，LiteOS-M 內(nèi)核就緒隊列由一個雙向循環(huán)鏈表數(shù)組管理，每個數(shù)組元素都是一個LOS_DL_LIST 雙向循環(huán)鏈表，通過任務(wù)描述符LosTaskCB 中的pendList 成員相互掛接，從而能夠快速定位同一優(yōu)先級的任務(wù)。g_losPriorityQueueList 任務(wù)就緒隊列數(shù)組長度對應(yīng)了系統(tǒng)優(yōu)先級個數(shù)。

圖3 任務(wù)優(yōu)先級就緒隊列與優(yōu)先級位圖Fig.3 Task priority ready queue and priority bitmap

g_priQueueBitmap 優(yōu)先級位圖標識了任務(wù)就緒隊列中已掛載的就緒任務(wù)所在的優(yōu)先級。當時間片到期發(fā)生任務(wù)調(diào)度時，遍歷位圖的32 位能快速找到就緒隊列中最高優(yōu)先級所在的雙向循環(huán)鏈表，從而高效地定位就緒隊列中最高優(yōu)先級的任務(wù)。優(yōu)先級位圖比特位與任務(wù)優(yōu)先級的關(guān)系如式（1）所示：

其中：PPRIORITYNUM在系統(tǒng)中默認被設(shè)定為31。比特值為0 標識對應(yīng)優(yōu)先級下無就緒任務(wù)，比特值為1 反之。通過執(zhí)行CLZ 指令計算位圖最高符號位與第1 個1 之間的0 的個數(shù)，當?shù)玫轿粓D比特值標識為30 時，計算得到任務(wù)優(yōu)先級為1。之后，從g_losPriorityQueueList 數(shù)組下標為1 的雙向循環(huán)隊列位置找到隊頭任務(wù)的LosTaskCB，即為時間片到期后發(fā)生調(diào)度的切入任務(wù)的任務(wù)描述符。

在MIPS 架構(gòu)移植過程中，在上下文切換、啟動調(diào)度時將切入首任務(wù)作為系統(tǒng)調(diào)度的關(guān)鍵環(huán)節(jié)，下文展開說明兩者在實時內(nèi)核MIPS 架構(gòu)移植過程中的適配設(shè)計與重要HAL 接口實現(xiàn)。

2.3 上下文切換

任務(wù)切換過程主要包括獲取就緒隊列中最高優(yōu)先級任務(wù)、保存切出任務(wù)上下文、恢復切入任務(wù)上下文等動作。任務(wù)上下文是任務(wù)在運行過程中使用的寄存器等資源，在任務(wù)切換時需要保存與恢復任務(wù)對應(yīng)的上下文來保障系統(tǒng)的正常運行。依據(jù)MIPS架構(gòu)并對照任務(wù)現(xiàn)場的保存與恢復過程，嚴格遵守O32 ABI 規(guī)范并兼顧硬件上下文保存與恢復效率，設(shè)計如下代碼駐存在任務(wù)棧棧底的上下文TaskContext結(jié)構(gòu)體中：

在任務(wù)運行中發(fā)生函數(shù)調(diào)用時的局部變量、形參、任務(wù)上下文等重要信息都需要存放在任務(wù)棧中。LiteOS-M 任務(wù)棧為滿遞減棧，分為主堆棧和任務(wù)棧兩種類型［25］。主堆棧在引導程序文件中設(shè)置，在內(nèi)存中預(yù)留出主堆棧占用空間，并將主堆棧起始地址stack 加載至SP 寄存器中。任務(wù)棧大小是在用戶創(chuàng)建任務(wù)時配置并在運行過程中由動態(tài)內(nèi)存分配函數(shù)LOS_MemAllocAlign 分配，之后調(diào)用HAL 提供的接口HalTskStackInit 函數(shù)實現(xiàn)初始化。該函數(shù)接口需結(jié)合MIPS 架構(gòu)設(shè)計與實現(xiàn)，MIPS 架構(gòu)下HAL 任務(wù)棧初始化設(shè)計示意圖如圖4 所示。初始化任務(wù)棧，首先需要將棧大小空間內(nèi)存中的內(nèi)容初始化為OS_TASK_STACK_INIT（即0xCACACACA）、棧頂初始化為溢出標識OS_TASK_MAGIC_WORD（即0xCCCCCCCC）。之后在任務(wù)棧底分配任務(wù)上下文的內(nèi)存空間，用于當前任務(wù)上下文的保存。

圖4 MIPS 架構(gòu)下任務(wù)棧初始化設(shè)計Fig.4 Design of task stack initialization under MIPS architecture

HAL 任務(wù)棧初始化還需指定初始值賦給任務(wù)棧中上下文保存的寄存器域。依據(jù)MIPS 架構(gòu)寄存器功能約定，HAL 任務(wù)棧各個寄存器域的初始值設(shè)置如表2 所示。

表2 HAL 任務(wù)棧上下文初始值設(shè)置Table 2 Setting of initial values of HAL task stack context

在MIPS 架構(gòu)下：任務(wù)棧初始化SP 域值為任務(wù)棧上下文的地址context，指向駐存在當前棧底的任務(wù)上下文結(jié)構(gòu)體TaskContext；函數(shù)調(diào)用參數(shù)寄存器a0 域保存初始值為任務(wù)唯一標識號taskID；GP 初始值設(shè)定直接讀取鏈接時設(shè)置好的GP 寄存器值；RA域初始值設(shè)置為HAL 任務(wù)退出函數(shù)HalSysExit；FP域保存棧幀指針偏移為0x0。除上述寄存器外，其他通用寄存器初始值不重要，因此統(tǒng)一設(shè)置為?？臻g默認值。初始化CP0 協(xié)處理器狀態(tài)寄存器status 值為ST0_IE|ST0_CU0|ST0_IM，意圖在初始時使能中斷、協(xié)處理器，并允許任何中斷源活動時產(chǎn)生異常。任務(wù)棧上下文中cause 寄存器域通過讀取當下真實的cause 寄存器值完成初始化。初始化EPC 寄存器域為任務(wù)入口函數(shù)OsTaskEntry，是實現(xiàn)首任務(wù)切入的前提。

LosTaskCB 中stackPointer 指針成員變量指向其任務(wù)棧的任務(wù)上下文，stackTop 成員變量標識任務(wù)棧棧頂。g_losTask 是任務(wù)調(diào)度中關(guān)鍵的全局變量，標識內(nèi)核相關(guān)進程信息，其中runTask 指針成員和newTask 指針成員分別指向當前運行任務(wù)的任務(wù)描述符和即將發(fā)生調(diào)度切入任務(wù)的任務(wù)描述符。通過各自任務(wù)描述符找到任務(wù)棧指針和棧頂。這些數(shù)據(jù)結(jié)構(gòu)與任務(wù)棧之間的關(guān)系如圖5 所示，因此內(nèi)核可以方便地進行任務(wù)切換。

圖5 上下文切換時任務(wù)棧數(shù)據(jù)結(jié)構(gòu)關(guān)系Fig.5 Data structure relation of task stack during context switching

在任務(wù)運行過程中，不論是處于事件讀寫、互斥鎖、信號量等資源阻塞的情況下主動發(fā)生調(diào)度，還是時間片到期觸發(fā)被動調(diào)度或是中斷處理結(jié)束檢查全局調(diào)度標識為真值時，都會引發(fā)上下文切換。

先保存當前任務(wù)上下文，再將指針runTask 指向切入任務(wù)硬件上下文，使得切入任務(wù)得以順利執(zhí)行。實現(xiàn)與上下文結(jié)構(gòu)體相關(guān)的HalTaskContextSwitch匯編函數(shù)，通過將runTask 指向的任務(wù)描述符切換成newTask 指向的任務(wù)描述符完成任務(wù)切換。任務(wù)切換詳細設(shè)計流程如圖6 所示。

圖6 任務(wù)切換設(shè)計流程Fig.6 Design process of task switching

2.4 任務(wù)調(diào)度啟動

系統(tǒng)執(zhí)行LOS_Start 函數(shù)開啟調(diào)度，獲取當前系統(tǒng)優(yōu)先級最高的就緒任務(wù)作為首任務(wù)，對該任務(wù)只需恢復其任務(wù)上下文。

首任務(wù)切入是通過調(diào)用HAL 接口HalStartToRun實現(xiàn)。在ARM 架構(gòu)下，HalTskStackInit 函數(shù)使用任務(wù)入口地址OsTaskEntry 初始化PC 寄存器，因此執(zhí)行HalStartToRun 時會恢復任務(wù)上下文，即依據(jù)初始設(shè)定的上下文保存值一一對應(yīng)恢復至寄存器中，依據(jù)PC 直接實現(xiàn)首任務(wù)的切入。但在MIPS 架構(gòu)PC寄存器對程序員透明的情況下，不能通過對PC 賦值進行地址跳轉(zhuǎn)，因此無法采用這種方式。

鑒于上述情況，需結(jié)合MIPS 架構(gòu)設(shè)計一種首任務(wù)切入方式。EPC 作為能夠?qū)崿F(xiàn)地址跳轉(zhuǎn)的協(xié)處理器寄存器，通常用來保存MIPS 架構(gòu)中發(fā)生精確異常的地址。EPC 寄存器常見的應(yīng)用情形是：在中斷或異常處理函數(shù)執(zhí)行后，MIPS 架構(gòu)通常應(yīng)用ERET 指令從協(xié)處理器EPC 寄存器中取出重新執(zhí)行指令地址，從該地址處繼續(xù)取指執(zhí)行。另外，在用戶程序需要使用內(nèi)核提供的服務(wù)時會發(fā)生系統(tǒng)調(diào)用，也由ERET 指令實現(xiàn)從內(nèi)核態(tài)到用戶態(tài)的切換。因此在設(shè)計任務(wù)切入時，將任務(wù)入口OsTaskEntry 在任務(wù)棧初始化時賦值給上下文中的EPC 寄存器域，在調(diào)用HAL 接口HalStartToRun 恢復上下文時采用ERET指令實現(xiàn)地址跳轉(zhuǎn)與處理器狀態(tài)切換，從而起到類似于ARM 架構(gòu)下的跳轉(zhuǎn)至PC 執(zhí)行一樣的作用，使得設(shè)定的任務(wù)函數(shù)能夠執(zhí)行。

HalStartToRun 函數(shù)將切入任務(wù)描述符LosTaskCB中的棧指針成員變量stackPointer 加載到SP 寄存器中并恢復任務(wù)上下文。最后通過MIPS 的eret 指令實現(xiàn)將EPC 中保存值作為當前程序執(zhí)行地址，即可通過硬件切入首任務(wù)執(zhí)行入口。另外，還需將任務(wù)描述符LosTaskCB 中描述任務(wù)狀態(tài)信息的成員變量taskStatus 修改為運行狀態(tài)。MIPS 架構(gòu)下HAL 開啟調(diào)度并切入首任務(wù)的HalStartToRun 核心匯編代碼具體如下：

2.5 異常與中斷處理

異常處理是CPU 根據(jù)內(nèi)部或外部的異常事件從正常執(zhí)行的程序轉(zhuǎn)入處理特定的異常服務(wù)程序。MIPS 架構(gòu)將中斷歸為異常的一種。

結(jié)合MIPS 架構(gòu)與LiteOS-M 內(nèi)核，設(shè)計一種異常與中斷處理方法。當異常發(fā)生時，首先跳轉(zhuǎn)至固定地址的異常入口general_excption 函數(shù)，該函數(shù)取出協(xié)處理器Cause寄存器中的ExcCode域判斷異常類型，并計算偏移量從而跳轉(zhuǎn)入異常向量表中對應(yīng)的異常處理函數(shù)。MIPS 架構(gòu)下異常向量表Exception_handler 如圖7 所示。

圖7 MIPS 架構(gòu)下異常向量表設(shè)計Fig.7 Design of exception vector table under MIPS architecture

ExCode 域值為0 標識中斷發(fā)生。對于中斷的處理，內(nèi)核提供了g_hwiForm 與g_hwiHandlerForm兩個函數(shù)指針數(shù)組來管理。首先，經(jīng)過上述異常處理步驟后執(zhí)行中斷處理程序HalInterrupt 函數(shù)，保存被打斷任務(wù)的上下文到堆棧中。接著，根據(jù)MIPS 架構(gòu)CP0 協(xié)處理器status 寄存器與cause 寄存器掩碼CR.IPMASK 與SR.IPMASK 對中斷類型進行判定獲得中斷號，依據(jù)中斷號從g_hwiForm 中取出對處理例程前后附加定制化處理操作的函數(shù)。然后，通過hwiHandlerForm 函數(shù)跳轉(zhuǎn)至用戶通過LOS_HwiCreate函數(shù)注冊的中斷服務(wù)。最后，完成中斷處理后恢復現(xiàn)場并返回。

異常與中斷的移植工作主要包括異常向量表與中斷向量表初始化、異常入口處理函數(shù)實現(xiàn)、異常與中斷服務(wù)函數(shù)實現(xiàn)，并針對上文提到的系統(tǒng)異常與中斷HAL 接口函數(shù)進行MIPS 架構(gòu)下的設(shè)計與實現(xiàn)。

2.6 系統(tǒng)時鐘

系統(tǒng)systick 時鐘在target_config.h 文件中配置為1 ms。通過實現(xiàn)內(nèi)核抽象層HalTickStart 函數(shù)完成時鐘的初始化，包括時鐘配置、時鐘中斷掛接等。由表1 可知，協(xié)處理器的Count 與Compare 寄存器配合使用，實現(xiàn)一個處理器內(nèi)部高精度定時器及定時中斷。Compare 寄存器存放的值在寫入后保持不變，與自增的Count 寄存器進行比較，兩者相等則觸發(fā)計時器中斷。在時鐘中斷處理函數(shù)中，執(zhí)行系統(tǒng)全局時鐘計數(shù)的自增、清中斷以及判斷定時任務(wù)是否到期主動發(fā)生調(diào)度的操作。通過軟件寫Compare寄存器實現(xiàn)清除CPU 定時器中斷的操作。除此之外，系統(tǒng)時鐘部分的移植工作還需實現(xiàn)Cycle 與Tick之間的轉(zhuǎn)換、微秒與毫秒之間的轉(zhuǎn)換等輔助函數(shù)。

3 系統(tǒng)編譯與部署

3.1 硬件平臺

實驗選取MIPS 架構(gòu)星載控制終端LS1J 與LS1C 作為硬件平臺。LS1J 主頻10 MHz，具有32 KB NOR FLASH，8 KB SRAM，集成了中斷控制器、定時器、串口控制器、SPI 控制器、AD/DA 等功能模塊。LS1C 相較LS1J 資源豐富，能夠?qū)崿F(xiàn)較為復雜的數(shù)據(jù)處理，主頻最高可達240 MHz，具有128 MB FLASH，64 MB SDRAM，包含硬件浮點處理單元，提供豐富的外設(shè)接口及片上模塊。LS1J 與LS1C 硬件環(huán)境搭建分別如圖8 與圖9 所示。

圖8 LS1J 實驗環(huán)境Fig.8 LS1J experimental environment

圖9 LS1C 實驗環(huán)境Fig.9 LS1C experimental environment

3.2 移植操作

如表3 所示，架構(gòu)移植工作增加的源碼主要在arch 和device 目錄下，其 中MIPS 架構(gòu)的HAL 實現(xiàn)代碼位于arch 目錄。硬件平臺相關(guān)BSP 部署在device 目錄下，且在device 目錄下創(chuàng)建IPC 模塊、時鐘模塊、硬中斷模塊等系統(tǒng)模塊的資源配置文件target_config.h，并創(chuàng)建Makefile 文件定義編譯鏈接規(guī)則。最后新增APP 工程目錄，調(diào)用內(nèi)核API 接口實現(xiàn)測試用例的設(shè)計。

表3 關(guān)鍵移植操作Table 3 Key porting operations

3.3 編譯環(huán)節(jié)

編譯工作在Ubuntu 20.04 下進行，使用龍芯提供的mips-mti-elf-gcc 交叉編譯平臺。

受限于LS1J 片上極小的存儲資源，對系統(tǒng)進行函數(shù)級裁剪并且在編譯過程中調(diào)整編譯選項實現(xiàn)空間優(yōu)化。在編譯時，使用-ffunction-sections 選項將每個函數(shù)放在單獨的section 中，并使用-mno-abicalls選項避免輸出.abicalls、.cpload 等偽指令。鏈接ld 選項使用--gc-section 不鏈接未使用函數(shù)生成的section，從而滿足硬件空間對映像大小的約束。編譯出的LS1J 系統(tǒng)映像各段占用的FLASH 空間情況如表4 所示，滿足硬件空間約束。

表4 LS1J 系統(tǒng)映像各段占用的FLASH 空間Table 4 FLASH space occupied by each section of the LS1J system image 單位：Byte

LS1C 因存儲資源較大，為便于調(diào)試可選擇支持?；厮萁M件，其編譯情況如圖10 所示。

圖10 LS1C 編譯情況Fig.10 LS1C compilation status

將生成的可執(zhí)行鏡像通過龍芯提供的GDB 與EJTAG 等工具分別對應(yīng)下載到兩種開發(fā)板中進行調(diào)試，在系統(tǒng)啟動后，通過串口在上位機putty 工具中輸出系統(tǒng)打印信息。

4 驗證與測試

經(jīng)過實際應(yīng)用后發(fā)現(xiàn)LS1J 硬件較為特殊，不支持異常與中斷入口動態(tài)跳轉(zhuǎn)，致使中斷發(fā)生后不能跳轉(zhuǎn)至系統(tǒng)用戶通過內(nèi)核系統(tǒng)函數(shù)注冊的中斷服務(wù)，只能將處理代碼在引導程序中使用匯編指令固化在FLASH 中硬件指定的偏移位置。下面針對龍芯MIPS 架構(gòu)更具普適性的LS1C 處理器的移植結(jié)果進行測試與驗證，對系統(tǒng)運行功能、實時性能進行分析與說明。

4.1 系統(tǒng)運行

LOS_KernelInit 函數(shù)實現(xiàn)系統(tǒng)啟動后內(nèi)核基礎(chǔ)模塊的初始化，其中包括內(nèi)存、中斷、時鐘、任務(wù)、IPC和IDLE 任務(wù)創(chuàng)建等，還可通過配置組件實現(xiàn)?；厮?、任務(wù)監(jiān)控等模塊的初始化。為了驗證系統(tǒng)的基礎(chǔ)功能運行的正確性，自定義main 函數(shù)設(shè)計測試用例如下：

1）創(chuàng)建任務(wù)優(yōu)先級為6 的任務(wù)Task 1，任務(wù)體循環(huán)執(zhí)行打印輸出TaskSampleEntry1，并調(diào)用LOS_TaskDelay 主動阻塞延時0.5 s。

2）創(chuàng)建任務(wù)優(yōu)先級為7 的任務(wù)Task 2，任務(wù)循環(huán)執(zhí)行打印輸出TaskSampleEntry2，并調(diào)用LOS_TaskDelay 主動阻塞延時2 s。

測試用例運行結(jié)果如圖11 所示，驗證系統(tǒng)的基礎(chǔ)功能運行符合預(yù)期。由于OpenHarmony LiteOS-M內(nèi)核優(yōu)先級數(shù)值越低代表優(yōu)先級越高，Task 1 優(yōu)先級為6，小于Task 2 的任務(wù)優(yōu)先級7，因此Task 1 會比Task 2 更先搶占CPU。測試用例設(shè)計Task 1 時延為0.5 s，Task 2 時延為2 s，因此在Task 2 長時延 中，Task 2 會放棄搶占CPU，發(fā)生任務(wù)調(diào)度執(zhí)行Task 1，因此Task 1 執(zhí)行次數(shù)較Task 2 更多。

圖11 測試用例運行結(jié)果Fig.11 Test case running result

4.2 實時性能

任務(wù)切換時間和中斷響應(yīng)時間是影響操作系統(tǒng)性能的最重要因素，也是RTOS 實時性能的重要指標。利用高精度系統(tǒng)時鐘，分別在測量指標相關(guān)執(zhí)行節(jié)點的入口和出口處標記時間戳，時間戳之差即被測操作所需時間［2627］。

上下文切換時間被定義為系統(tǒng)在兩個相互獨立且相同優(yōu)先級的就緒任務(wù)之間切換所需要的時間［28］，反映了任務(wù)切換的速度。這段時間主要包括保存當前被切出任務(wù)上下文所需的時間、OS 調(diào)度選擇新任務(wù)的時間以及恢復即將切入新任務(wù)上下文所需時間3 個部分，故任務(wù)的切換時間取決于系統(tǒng)任務(wù)調(diào)度策略和上下文結(jié)構(gòu)體大小。

航天輕量型實時終端的具體配置和運行任務(wù)數(shù)目依據(jù)不同的任務(wù)需求存在差異，輕量型星載龍芯1系列終端執(zhí)行的任務(wù)通常包括接收和處理遙測數(shù)據(jù)、向航天器發(fā)送指令、數(shù)據(jù)壓縮與加密傳輸、姿態(tài)控制以及異常監(jiān)控等任務(wù)。如圖12 所示，任務(wù)切換時延檢驗采用交替懸置與恢復任務(wù)的測試方法［29］，主要測試步驟如下：

圖12 任務(wù)上下文切換時間示意圖Fig.12 Schematic diagram of task context switching time

1）創(chuàng)建5 個相等的優(yōu)先級任務(wù)，標記其中任意2 個任務(wù)為Task 1 和Task 2。

2）任務(wù)在無限循環(huán)中執(zhí)行，記錄執(zhí)行Task 1 最后一條指令的時間T1，Task 2 第一條指令的時間T2，時間戳的差值T2-T1即為上下文切換的時間。

重復100 次實驗的測試數(shù)據(jù)如圖13 所示，計算得到系統(tǒng)任務(wù)切換時間的均值為0.229 μs、標準差為0.003 5 μs、最大值為0.234 μs。

圖13 任務(wù)切換時間Fig.13 Task switching time

中斷響應(yīng)時間是從系統(tǒng)收到中斷信號到進入中斷處理程序的時間。中斷響應(yīng)實時性能檢驗采用PWM 硬件定時器作為外部時鐘源定時產(chǎn)生1 000 μs中斷信號，并且屏蔽系統(tǒng)其他中斷。主要測試步驟如下：

1）創(chuàng)建一個任務(wù)。任務(wù)起始時間戳記錄為T1，計時器中斷設(shè)置在1 ms 之后。

2）計時器中斷開始執(zhí)行中斷服務(wù)例程第一條指令的時間戳記錄為T2。

3）重復上述步驟，中斷響應(yīng)時延為T2-T1-1 ms。

重復100 次獨立測試，計算得到系統(tǒng)中斷響應(yīng)時延均值為4.73 μs、標準差 為0.61 μs、最大值 為6.01 μs。實驗結(jié)果如圖14 所示。

圖14 中斷響應(yīng)時延Fig.14 Interrupt response delay

在同等實驗條件下，在VxWorks 實時操作系統(tǒng)中重復上述實時性能測試，對比兩者任務(wù)切換與中斷響應(yīng)時延的均值，結(jié)果如表5 所示。

表5 實時性能測試結(jié)果對比Table 5 Comparison of real-time performance test results 單位：μs

由上述實驗結(jié)果可得，兩者實時性能指標的均值相近，OpenHarmony 以LiteOS-M 為內(nèi)核的輕量型系統(tǒng)實現(xiàn)MIPS 架構(gòu)移植后能夠滿足航天實時性應(yīng)用需求。

5 結(jié)束語

本文對輕量型開源鴻蒙操作系統(tǒng)的LiteOS-M內(nèi)核與MIPS 架構(gòu)進行介紹與分析，詳細闡述了MIPS 架構(gòu)相關(guān)的寄存器、上下文切換、啟動引導、中斷異常及時鐘的核心部分移植方法，并選擇作為航天控制終端的MIPS 架構(gòu)龍芯處理器硬件平臺完成了系統(tǒng)功能與性能測試，為國內(nèi)航空航天領(lǐng)域類瘦終端的星載計算機分布式架構(gòu)的部署與應(yīng)用提供了解決方案，對構(gòu)建星載計算機可靠與安全且自主可控的信息技術(shù)體系具有一定參考意義。后續(xù)將針對更多型號的MIPS 架構(gòu)航天控制終端進行系統(tǒng)移植，并對具體硬件平臺集成的外設(shè)接口進行符合架構(gòu)的驅(qū)動開發(fā)，以支持更多的外部設(shè)備。