支持MIPS 架構的輕量型開源鴻蒙系統移植

王一泠，吳 琦，安軍社

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

0 概述

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

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

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

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

1 相關技術

1.1 OpenHarmony 多內核技術

OpenHarmony 采用多內核設計，利用內核抽象層（Kernel Abstraction Layer，KAL）屏蔽多內核差異，對系統上層提供基礎的內核能力，包括進程/線程管理、內存管理、文件系統、網絡管理和外設管理等。

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

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

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

圖1 LiteOS-M 內核架構Fig.1 LiteOS-M kernel architecture

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

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

3）內核功能增強組件層。配置組件啟用相應功能，LiteOS-M 內核可配置包括文件系統、網絡與調測工具等組件。另外，可依據移植平臺應用場景配置低功耗框架組件來降低功耗，配置Trace 回溯組件與ExcHook 組件輔助開發工作。

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

1.2 MIPS 架構

1.2.1 MIPS 與龍芯

MIPS 作為最早的商業精簡指令集計算機（Reduced Instruction Set Computer，RISC）設計架構芯片之一，其機制是盡量利用軟件避免流水線中的數據相關問題，與復雜指令系統計算結構相比設計周期更短［21］。

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

1.2.2 MIPS 架構寄存器

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

表1 MIPS 架構CP0 協處理器重要寄存器及其功能Table 1 Important registers and their functions of MIPS architecture CP0 coprocessor

1.3 關鍵技術分析

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

2 系統MIPS 架構移植設計方案

下面對加載程序引導、任務管理、上下文切換、任務調度啟動、異常與中斷處理、系統時鐘6 個移植關鍵環節給出設計方案與實現流程。

2.1 加載程序引導

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

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

2.2 任務管理

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

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

圖3 任務優先級就緒隊列與優先級位圖Fig.3 Task priority ready queue and priority bitmap

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

其中：PPRIORITYNUM在系統中默認被設定為31。比特值為0 標識對應優先級下無就緒任務，比特值為1 反之。通過執行CLZ 指令計算位圖最高符號位與第1 個1 之間的0 的個數，當得到位圖比特值標識為30 時，計算得到任務優先級為1。之后，從g_losPriorityQueueList 數組下標為1 的雙向循環隊列位置找到隊頭任務的LosTaskCB，即為時間片到期后發生調度的切入任務的任務描述符。

在MIPS 架構移植過程中，在上下文切換、啟動調度時將切入首任務作為系統調度的關鍵環節，下文展開說明兩者在實時內核MIPS 架構移植過程中的適配設計與重要HAL 接口實現。

2.3 上下文切換

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

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

圖4 MIPS 架構下任務棧初始化設計Fig.4 Design of task stack initialization under MIPS architecture

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

表2 HAL 任務棧上下文初始值設置Table 2 Setting of initial values of HAL task stack context

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

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

圖5 上下文切換時任務棧數據結構關系Fig.5 Data structure relation of task stack during context switching

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

先保存當前任務上下文，再將指針runTask 指向切入任務硬件上下文，使得切入任務得以順利執行。實現與上下文結構體相關的HalTaskContextSwitch匯編函數，通過將runTask 指向的任務描述符切換成newTask 指向的任務描述符完成任務切換。任務切換詳細設計流程如圖6 所示。

圖6 任務切換設計流程Fig.6 Design process of task switching

2.4 任務調度啟動

系統執行LOS_Start 函數開啟調度，獲取當前系統優先級最高的就緒任務作為首任務，對該任務只需恢復其任務上下文。

首任務切入是通過調用HAL 接口HalStartToRun實現。在ARM 架構下，HalTskStackInit 函數使用任務入口地址OsTaskEntry 初始化PC 寄存器，因此執行HalStartToRun 時會恢復任務上下文，即依據初始設定的上下文保存值一一對應恢復至寄存器中，依據PC 直接實現首任務的切入。但在MIPS 架構PC寄存器對程序員透明的情況下，不能通過對PC 賦值進行地址跳轉，因此無法采用這種方式。

鑒于上述情況，需結合MIPS 架構設計一種首任務切入方式。EPC 作為能夠實現地址跳轉的協處理器寄存器，通常用來保存MIPS 架構中發生精確異常的地址。EPC 寄存器常見的應用情形是：在中斷或異常處理函數執行后，MIPS 架構通常應用ERET 指令從協處理器EPC 寄存器中取出重新執行指令地址，從該地址處繼續取指執行。另外，在用戶程序需要使用內核提供的服務時會發生系統調用，也由ERET 指令實現從內核態到用戶態的切換。因此在設計任務切入時，將任務入口OsTaskEntry 在任務棧初始化時賦值給上下文中的EPC 寄存器域，在調用HAL 接口HalStartToRun 恢復上下文時采用ERET指令實現地址跳轉與處理器狀態切換，從而起到類似于ARM 架構下的跳轉至PC 執行一樣的作用，使得設定的任務函數能夠執行。

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

2.5 異常與中斷處理

異常處理是CPU 根據內部或外部的異常事件從正常執行的程序轉入處理特定的異常服務程序。MIPS 架構將中斷歸為異常的一種。

結合MIPS 架構與LiteOS-M 內核，設計一種異常與中斷處理方法。當異常發生時，首先跳轉至固定地址的異常入口general_excption 函數，該函數取出協處理器Cause寄存器中的ExcCode域判斷異常類型，并計算偏移量從而跳轉入異常向量表中對應的異常處理函數。MIPS 架構下異常向量表Exception_handler 如圖7 所示。

圖7 MIPS 架構下異常向量表設計Fig.7 Design of exception vector table under MIPS architecture

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

異常與中斷的移植工作主要包括異常向量表與中斷向量表初始化、異常入口處理函數實現、異常與中斷服務函數實現，并針對上文提到的系統異常與中斷HAL 接口函數進行MIPS 架構下的設計與實現。

2.6 系統時鐘

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

3 系統編譯與部署

3.1 硬件平臺

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

圖8 LS1J 實驗環境Fig.8 LS1J experimental environment

圖9 LS1C 實驗環境Fig.9 LS1C experimental environment

3.2 移植操作

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

表3 關鍵移植操作Table 3 Key porting operations

3.3 編譯環節

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

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

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

LS1C 因存儲資源較大，為便于調試可選擇支持棧回溯組件，其編譯情況如圖10 所示。

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

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

4 驗證與測試

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

4.1 系統運行

LOS_KernelInit 函數實現系統啟動后內核基礎模塊的初始化，其中包括內存、中斷、時鐘、任務、IPC和IDLE 任務創建等，還可通過配置組件實現棧回溯、任務監控等模塊的初始化。為了驗證系統的基礎功能運行的正確性，自定義main 函數設計測試用例如下：

1）創建任務優先級為6 的任務Task 1，任務體循環執行打印輸出TaskSampleEntry1，并調用LOS_TaskDelay 主動阻塞延時0.5 s。

2）創建任務優先級為7 的任務Task 2，任務循環執行打印輸出TaskSampleEntry2，并調用LOS_TaskDelay 主動阻塞延時2 s。

測試用例運行結果如圖11 所示，驗證系統的基礎功能運行符合預期。由于OpenHarmony LiteOS-M內核優先級數值越低代表優先級越高，Task 1 優先級為6，小于Task 2 的任務優先級7，因此Task 1 會比Task 2 更先搶占CPU。測試用例設計Task 1 時延為0.5 s，Task 2 時延為2 s，因此在Task 2 長時延 中，Task 2 會放棄搶占CPU，發生任務調度執行Task 1，因此Task 1 執行次數較Task 2 更多。

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

4.2 實時性能

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

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

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

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

1）創建5 個相等的優先級任務，標記其中任意2 個任務為Task 1 和Task 2。

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

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

圖13 任務切換時間Fig.13 Task switching time

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

1）創建一個任務。任務起始時間戳記錄為T1，計時器中斷設置在1 ms 之后。

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

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

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

圖14 中斷響應時延Fig.14 Interrupt response delay

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

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

由上述實驗結果可得，兩者實時性能指標的均值相近，OpenHarmony 以LiteOS-M 為內核的輕量型系統實現MIPS 架構移植后能夠滿足航天實時性應用需求。

5 結束語

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