一種嵌入式雙操作系統架構中外設資源動態遷移的研究與實現*

崔振禮，羅 宇

(國防科技大學計算機學院,湖南 長沙 410073)

1 引言

隨著大規模集成電路的發展，嵌入式設備的性能越來越強，功能越來越豐富，應用場景也越來越復雜，在以智能制造和物聯網為主題的“工業4.0”概念被提出后，各應用領域對嵌入式操作系統的要求也越來越高。復雜的應用場景要求嵌入式操作系統在具有豐富功能性的同時支持實時性，但是在單操作系統中，豐富的功能性會不可避免地導致較多的運行任務和復雜的調度算法，難以達到實時性要求，而為了保證實時性，系統通常會最小化任務數量，盡量減少一些不必要的功能，所以單操作系統難以同時兼具兩者[1]。雙操作系統架構正好可以滿足這一要求。在雙操作系統架構中，通用操作系統GPOS(General-Purpose Operating System)和實時操作系統RTOS(Real-Time Operating System)部署在同一嵌入式平臺，其中GPOS 提供復雜任務開發功能，滿足系統的功能需求，RTOS 提供精確的實時控制功能，滿足系統的實時性需求[2]。

由于雙操作系統運行于同一硬件平臺，如何合理地配置有限的外設資源是雙操作系統架構面臨的重要問題。通過虛擬化技術，雙操作系統可以實現外設資源共享，但是虛擬化軟件層會帶來額外的性能開銷，對于嵌入式設備來說，這種開銷是不容忽視的。而在非虛擬化條件下，操作系統實例互相隔離，獨占私有的外設資源，既可以充分發揮性能，又可以提升信息安全性[3]。華為海思Hi3559AV100 SOC的雙操作系統架構采用非虛擬化方式，系統分別運行于不同的CPU，外設資源按照功能需求分成2部分由雙操作系統分別單獨占有，不能共享使用。采用上述方式時，外設資源配置方案在操作系統源代碼中被靜態指定，系統部署之后便無法調整。搭載了該雙操作系統架構的嵌入式設備在運行時，如果某端系統發生了故障，其上運行的與外設交互的任務便無法繼續，從而影響到整個系統的正常運行，輕則造成設備功能失效、失控或損壞，重則影響用戶的健康安全。

本文基于上述問題提出一種外設資源在雙操作系統運行期間動態遷移的解決方案。在某端系統出現故障之后，把配置到該端的外設資源遷移到另一端系統，啟動相應的用戶處理程序，控制外設繼續工作，最大限度地保證用戶和設備的安全，避免損失。最后在EVM3559A嵌入式開發平臺上對所提方案的可行性和可靠性進行實驗驗證。

2 Hi3559AV100雙操作系統架構簡介

2.1 Hi3559AV100 SOC簡介

Hi3559AV100是華為海思面向智能網絡監控攝像頭、3D/VR攝像頭、視頻會議終端、智能工業機器人、智能無人機、實時護理系統終端等領域設計的專業8K ultra HD mobile camera SOC，它提供了8K30/4K120廣播級圖像質量的數字視頻錄制，支持4K sensor輸入，H.265編碼輸出或影視級的raw數據輸出，多路全景硬件拼接，并集成了高性能圖像信號處理器ISP(Image Signal Processor)，為用戶提供了卓越的圖像處理能力；提供高效且豐富的計算資源，集成了1個由雙核A53和雙核A73組成的四核CPU、1個單核A53、1個M7、1個GPU、1個四核數字信號處理器DSP(Digital Signal Processor)和2個神經網絡推理引擎NNIE(Neural Network Inference Engine)，可根據應用場景制定合適的業務部署方案；采用先進的12 nm低功耗工藝和小型化封裝，在縮小產品體積的同時減少功耗[4]；支持單操作系統和多操作系統(最多4個)部署方案，以滿足不同的業務需求。

2.2 雙操作系統架構

Hi3559AV100提供Linux+LiteOS的雙操作系統部署方案，Linux作為GPOS運行非實時任務，部署在雙核A53和雙核A73組成的四核CPU上，LiteOS作為RTOS運行實時任務，部署在單核A53上，雙操作系統之間共享內存，并通過共用系統總線訪問外設資源。Linux作為主流嵌入式通用操作系統，其使用廣泛，性能高效，運行穩定，功能強大，對硬件平臺適配性好，對外圍設備兼容性強，由于其開源特性，可根據具體需求進行裁剪，還可根據特殊需求實現定制化。LiteOS是華為針對物聯網領域推出的輕量級物聯網實時操作系統，具備輕量級(最小內核尺寸僅為6 KB)、高實時、高穩定性、低功耗、互聯互通、組件豐富和快速開發等關鍵能力[5]。Hi3559AV100雙操作系統架構如圖1所示。

Figure 1 Hi3559AV100 dual operating systems architecture圖1 Hi3559AV100雙操作系統架構

3 外設資源動態遷移

外設資源動態遷移的實現基于外設中斷與CPU核的動態綁定，即改變外設中斷的響應CPU，由該CPU上部署的操作系統進行處理。

3.1 Hi3559AV100外設中斷處理流程

在Hi3559AV100中，外設的中斷由通用中斷控制器GIC(Generic Interrupt Controller)負責管理，GIC是聯系外設中斷和CPU的橋梁，也是各CPU之間中斷互聯的通道。GIC共支持3種中斷類型[6]：

(1)軟中斷SGI(Software-Generated Interrupt):SGI為軟件可以觸發的中斷，統一編號為0～15，用于各個CPU核之間的通信；

(2)私有外設中斷PPI(Private Peripheral Interrupt):PPI為每個CPU核的私有外設中斷，統一編號為 16～31。例如,每個CPU核的Local Timer產生的中斷就是通過 PPI 發送給CPU核的；

(3)外設中斷SPI(Shared Peripheral Interrupt):SPI 是外部設備產生的中斷，所有CPU核共用，統一編號為32～1 019，如Global Timer、UART和GPIO產生的中斷。

由于本文研究內容只與SPI相關，所以忽略SGI和PPI。Hi3559AV100使用的是GIC-400，最多支持8個CPU接口，其與外設、CPU連接情況如圖2所示。

Figure 2 GIC connection with peripherals and CPU圖2 GIC與外設、CPU的連接

由圖2可知，CPU核與GIC之間有2條連接線，分別是快速中斷請求線FIQ(Fast Interrupt Request)與中斷請求線IRQ(Interrupt ReQuest)，FIQ用于安全模式，IRQ用于非安全模式[6]。當外設中斷發送至GIC時，GIC會把收集來的中斷緩存，然后從中選擇優先級最高的中斷請求發送至該外設中斷綁定的CPU，CPU接收到外設中斷信號后，讀GIC相應的寄存器得到中斷號，然后開始處理中斷。

3.2 GIC通用中斷控制器工作原理

GIC內部由2個部件組成：分發器(Distribut- or)和 CPU 接口(CPU Interface)。

分發器的主要作用是檢測各個中斷源的狀態，控制各個中斷源的行為，分發各個中斷源產生的中斷事件到設定的CPU接口上。雖然分發器可以管理多個中斷源，但是它總是把優先級最高的中斷請求送往CPU接口。分發器對中斷的控制包括[6]：

(1)中斷使能或禁用控制。分發器對中斷的控制分成2個級別，一個級別是對全局中斷的控制，一旦禁能了全局中斷，那么任何中斷源產生的中斷事件都不會被傳遞到CPU接口；另外一個級別是針對各個中斷源進行控制，禁用某一個中斷源會導致該中斷事件不會分發到CPU接口，但不影響其他中斷源產生的中斷事件的分發。

(2)將當前優先級最高的中斷事件分發到預先綁定的CPU接口。

(3)優先級控制。

(4)中斷屬性設定，例如是電平觸發還是邊沿觸發。

CPU接口是GIC與CPU核之間的連接接口，它的主要作用有[6]：

(1)使能或者禁能CPU接口向連接的CPU核提交中斷事件。

(2)應答中斷，改變中斷的狀態。CPU核會向CPU接口應答中斷，中斷一旦被應答，分發器就會把該中斷的狀態從等待狀態修改成活躍狀態。

(3)接收中斷處理完畢的通知。

(4)設定優先級掩碼。通過優先級掩碼可以屏蔽掉一些優先級比較低的中斷，這些中斷不會通知到CPU核。

(5)設定中斷搶占的策略。

(6)在多個中斷事件同時到來的時候，選擇一個優先級最高的中斷發送到CPU接口。

由分發器和CPU接口的功能可知，中斷分發到哪個CPU是分發器根據預先綁定的CPU接口決定的，而外設中斷與CPU接口的綁定是通過向GIC分發器部件的中斷分發目的寄存器GICD_ITARGETSRn寫CPU接口掩碼實現的[6]。在分發器分發中斷事件時，首先根據GICD_ITARGETSRn寄存器找到該中斷綁定的CPU接口掩碼，然后根據掩碼把中斷分發到相應的接口。GIC分發器的初始化是在LiteOS啟動過程中完成的，其初始化代碼[7]如下所示：

#define WRITE_UINT32(Val，Addr)(*((volatile UINT32 *)((UINT32)(Addr)))=(Val))

void platform_gic_dist_init(void *base,UINT32irq_start){

…

//256 interrupts at most

UINT32max_irq=256;

/*irq_map:An array filled with CPU mask，indicates which CPU the IRQ is sent to*/

UINT32 *irq_dist=(UINT32 *)irq_map;

…

//write CPU mask to GIC related register

for(i=32;i

WRITE_UINT32(*irq_dist,base+ARM_GIC_DIST_TARGET+i);

irq_dist++;

}

}

由代碼可以看出，GIC設置為最多支持256個中斷；irq_map定義為數組，數組元素為外設中斷綁定的CPU接口的掩碼(8 bit，無符號字符類型)，數組元素的序號與某個外設中斷一一對應，例如數組序號8對應UART2的中斷，irq_map[8]的值表示UART2的中斷綁定的CPU接口的掩碼；從偏移量32開始(0～15為軟中斷，16～31為私有外設中斷)，外設中斷綁定的CPU接口的掩碼被寫到了GIC分發器部件的GICD_ITARGETSRn寄存器(地址為base+ARM_GIC_DIST_TARGET)中，且一次循環寫4個掩碼值。

CPU接口的掩碼及其與CPU核的連接關系如表1所示。

Table 1 Mask of the CPU interface and its connection to the CPU core

irq_map數組[7]定義如下所示：

#define TO_A53MP0 1<<0x00

#define TO_A53MP1 1<<0x01

#define TO_A73MP0 1<<0x02

#define TO_A73MP1 1<<0x03

#define TO_A53UP_ 1<<0x04

const UCHARirq_map[256-32]={

…

/*UART0,UART1,UART2*/

TO_A53MP0,TO_A53UP_,TO_A53MP0,

/*SPI0*/

TO_A53MP0

…

}

在源代碼中先為CPU核掩碼作宏定義。由于Linux運行在雙核A53和雙核A73組成的四核CPU上，LiteOS運行在單核A53上，所以當irq_map數組元素值為TO_A53MP0、TO_A53MP1、TO_A53MP2或者TO_A53MP3時表示對應的中斷由Linux負責處理，數組元素為TO_A53UP_時表示對應的中斷由LiteOS負責處理。

由GIC的工作原理可知，如果外設中斷在系統運行期間可以動態綁定到不同的CPU接口，就可以改變接收該中斷CPU核，從而實現外設資源在系統間動態遷移的目的。而外設中斷與CPU接口的綁定關系是由GIC分發器的GICD_ITARGETSRn寄存器中存放的CPU接口掩碼確定的[8]，所以可以通過修改此寄存器中相應地址的值來改變外設中斷綁定的CPU接口。

3.3 具體實現

以外設UART2為例，把外設資源動態遷移實現思路分為3步：

Step1確定GIC中GICD_ITARGETSRn寄存器的地址；

Step2根據UART2中斷在irq_map數組中對應的序號和Step 1中找到的地址，確定存放UART2中斷綁定的CPU接口的掩碼地址；

Step3把Step 2確定的地址中的值修改為要綁定的CPU接口的掩碼。

由于LiteOS未使用虛擬地址機制，所以可通過物理地址直接訪問GICD_ITARGETSRn寄存器的內容。通過閱讀LiteOS系統源碼得到系統基地址為0x1F101000，GICD_ITARGETSRn地址偏移量為0x800，所以Step 1中GICD_ITARGETSRn寄存器的地址為0x1F101800。由于UART2中斷在irq_map數組中對應的序號為8，所以存放UART2中斷綁定的CPU接口的掩碼地址為0x1F101800+32+8，此地址處的默認值為0x10，即CPU接口4的掩碼，然后將該地址處的值修改為雙核A53或者雙核A73的核所連接的CPU接口的掩碼，即可實現UART2從LiteOS到Linux的動態遷移。LiteOS應用程序中實現該功能的代碼如下(以遷移到雙核A53 的核0為例)所示：

#define BASE 0x1F101000

#define GICD_ITARGETSRn 0x800

#define WRITE_UCHAR(Val,Addr) (*((volatile UCHAR*)((UINT32)(Addr)))=(Val))

static voiduart2_tomp(){

…

WRITE_UCHAR(BASE+

GICD_ITARGETSRn+40,TO_A53MP0);

…

}

Linux使用了虛擬地址機制，所以在Linux中訪問寄存器要先把它的物理地址轉換成相應的虛擬地址。Linux提供了物理內存的鏡像設備文件/dev/mem，用于訪問物理內存，由于ARM架構采用I/O端口與物理內存統一編址方式，所以可以通過訪問內存地址的方式訪問I/O設備。Linux應用程序中實現該功能的代碼如下所示：

#define BASE 0x1F101000

#define GICD_ITARGETSRn 0x800

static voiduart2_tomp(){

…

intfd=open(“/dev/mem”,O_RDWR|O_SYNC);

void *virt_base=mmap(NULL,1000,

PROT_READ|PROT_WRITE,MAP_SHARED,fd,BASE);

*((UCHAR*)( BASE+GICD_ITARGETSRn+40))=TO_A53MP0;

…

}

4 實驗驗證

本文通過實驗驗證本文所提方案是否可行，遷移過程是否可靠。實驗采用的硬件平臺是廣州英碼信息科技有限公司生產的搭載了Hi3559AV100 SOC的EVM3559A嵌入式開發板，該開發板主要硬件配置信息如表2所示。

Table 2 Main hardware configuration information on EVM3559A

4.1 測試程序設計

測試程序分2部分，分別運行于LiteOS和Linux中，模擬單核A53故障或者LiteOS 宕機導致其上運行的任務無法繼續執行時，外設資源動態遷移到Linux中。通過HeartBeat原理[9]實現Linux對LiteOS的故障檢測，當Linux端測試程序在指定時間內未收到LiteOS端測試程序定時通過處理器間通信IPCM(Internal Processor Communication Message)發送的心跳信息時，便認為LiteOS發生了故障，啟動外設資源遷移程序及相應的用戶處理程序，進行非實時降級處理，繼續控制外設運行。

在本實驗中以外設UART2為測試設備。LiteOS端測試程序每隔1 s向Linux發送心跳信息，在程序運行20 s后停止發送，Linux端測試程序等待心跳信息超時時間設置為2 s。為了方便觀察實驗結果，兩端測試程序在接收到UART2數據后輸出至調試窗口。測試程序總體流程如圖3所示。

Figure 3 Overall flow chart of the test program圖3 測試程序總體流程

4.2 實驗環境搭建

在2臺電腦上分別安裝USB轉串口驅動，其中1臺作為測試電腦，安裝由C#編寫的串口數據發送程序，該程序每隔1 s向串口發送“‘This is a test statement numbered’+消息序號”的測試數據，其中消息序號從0開始，依次遞增1，另一臺作為調試電腦，安裝串口調試工具。測試電腦通過USB轉串口線連接到EVM3559A的UART2接口，調試電腦通過USB線連接至EVM3559A的micro USB調試串口。實驗環境連接情況如圖4所示。

Figure 4 Connection of experimental environment圖4 實驗環境連接情況

4.3 實驗過程及結果

測試程序均部署為開機自啟，后臺運行。EVM3559A上電后，雙操作系統啟動，測試程序自動運行,UART2中斷默認由LiteOS負責處理。

此時LiteOS端測試程序等待接收UART2數據，并定期向Linux發送心跳消息。打開測試電腦上的串口數據發送程序，開始發送測試數據，程序運行情況如圖5所示。

Figure 5 Running of the serial data sending program圖5 串口數據發送程序運行情況

LiteOS端測試程序開始接收到UART2數據，并把數據打印輸出至調試窗口，接收情況如圖6所示。

Figure 6 Test program receiving UART2 data in LiteOS 圖6 LiteOS端測試程序接收UART2數據

LiteOS端測試程序運行20 s之后，停止發送心跳信息，2 s后Linux端測試程序等待接收心跳信息超時，啟動UART2遷移程序，開始接收UART2串口數據，并打印輸出至調試窗口。接收情況如圖7所示。

Figure 7 Test program receiving UART2 data in Linux 圖7 Linux端測試程序接收UART2數據

由運行結果可知，Linux端測試程序可以接收到UART2數據，實現了UART2在雙操作系統運行期間的動態遷移，滿足可行性要求。此外，通過改變串口數據傳輸參數和傳輸頻率進行了多次實驗，實驗結果表明，在遷移前后，2端測試程序接收到的串口測試數據的序號是連續的，未發生數據丟失，具有高可靠性。

5 結束語

雙操作系統架構是嵌入式系統的發展趨勢，如何在系統間配置外設資源是該架構面臨的重要問題。本文基于華為海思Hi3559AV100 SOC雙操作系統架構，研究其外設資源在系統間的配置原理，分析此種外設配置方式在應用中存在的問題，提出一種利用外設中斷動態綁定CPU核的方式來實現外設資源在系統運行期間動態遷移的解決方案，并利用EVM3559A嵌入式開發平臺對該方案的可行性和可靠性進行了實驗驗證。 此外，該解決方案還可應用于外設資源的靈活部署、節能省耗、負載動態平衡等場景。