基於ARMv8的固件系統體系結構


基於ARMv8的固件系統體系結構

The architecture of ARMv8-based firmware systems

2011年發布以來,ARMv8處理器架構在移動設備市場上已經相當普及。根據ARM有限公司首席執行官的預測,到2020年,這一代處理器將獲得高達25%的世界市場份額。通過繼承歷史上形成的基礎設施的特性和一般原則,軟件支持得以建立並得到進一步發展,這是很自然的。             

在服務器細分市場上,觀察到了一種根本不同的情況。基於X86的服務器在這一領域占據主導地位已有很長一段時間,而ARMv8只是找到了自己的路(而且只進入了特定的業務領域)。ARM市場的新穎性以及大多數公認的標准和規范(主要是ACPI和UEFI)直到最近才適用於ARM系統,這一點在軟件基礎設施的開發上留下了印記。             

本文着重於對基於ARM的服務器系統和處理器特性的概述,並不聲稱是詳盡的描述。作者還想提請讀者注意這樣一個事實:所提供的數據可能很快就會過時——很快,新的處理器將帶來新的技術解決方案,可能需要采用不同的方法來實現軟件基礎設施。             

首先,我們應該指出,當前ARMv8服務器系統的固件實現由幾個相對獨立的組件組成。這提供了許多優點,例如在服務器和嵌入式系統固件中使用相同組件的可能性,以及引入的更改的相對獨立性。             

那么,這些系統使用了哪些模塊和組件,它們的功能是什么?模塊的加載和交互的總體圖如圖1所示。這個過程從初始化子系統開始,比如RAM和處理器間接口。在當前的實現中,這是由EL3S模式下的一個單獨的模塊在打開主CPU電源后立即執行的。因此,系統的這個組件擁有最大的權限。它通常不與操作系統直接交互。

1. 模塊的加載和交互。             

之后,控制權被轉移到下一個組件,通常是ARM可信固件(ATF)模塊,該模塊在相同的模式下執行。ATF控制可以直接從上一段描述的0級加載器傳輸,也可以通過實現PEI(PreEFI初始化)的特殊UEFI模塊間接傳輸。ATF由幾個在不同時間接收控制的模塊組成。             

BL1啟動模塊執行分配給安全處理器模式的平台部件的初始化。由於基於ARMv8的系統對可信和非可信資源(包括RAM)使用硬件分離,BL1模塊為可信代碼的執行准備了一個環境。具體而言,這種類型的初始化包括存儲器/高速緩存控制器的配置(通過對這些設備中的寄存器的編程來標記可信和非可信區域)和片上設備的標記(能量無關的內存控制器)。這個標記還引入了基於設備類型(可信/不可信)的DMA事務過濾。考慮到所有這些,內存的寫入/讀取只能從安全設置與設備的安全設置相匹配的區域進行。可信環境的實現可能相當復雜;例如,它們可以包含一個單獨的操作系統。但是,這種實現的描述超出了本文的范圍。             

BL1模塊配置MMU地址轉換表和異常處理程序表,其中最重要的元素是安全監視器調用(SMC)指令的異常處理程序。在這一點上,處理程序是最小的,實際上只能將控制權轉移到加載到RAM中的映像。運行時,BL1模塊將下一級(BL2)加載到RAM中,並將控制權轉移給它。BL2模塊在EL1S模式下工作,權限減少。因此,使用“ERET”指令執行向該模塊的控制轉移。             

BL2模塊的目的是加載剩余的固件模塊(BL3部件)並將控制權轉移給它們。降低的特權級別用於避免可能損壞內存中已有的代碼和EL3S數據。這些部件的代碼是通過使用SMC指令調用位於BL1階段的EL3S代碼來執行的。

ATF加載和初始化的第三階段可包括三個階段,但第二階段通常被省略。因此,事實上,只剩下兩個。BL3-1模塊是可信代碼的一部分,通用軟件(OS等)可以在運行時訪問它。這個模塊的關鍵部分是由“SMC”指令調用的異常處理程序。模塊本身有實現標准SMC調用的功能:實現標准PSCI接口(設計用於控制整個平台,例如啟用/禁用處理器核心、平台范圍內的電源管理和重新啟動)以及處理特定於供應商的調用(提供有關平台的信息,管理嵌入式設備等)。             

如上所述,BL3-2模塊的存在是可選的;其代碼(對於模塊而言)是在EL1S模式下執行的。通常,它作為平台操作期間發生的事件(來自某些計時器、設備等的中斷)的專用服務/監視器              

實際上,BL3-3不是ATF模塊,而是在非安全模式下執行的固件映像。它通常在EL2模式下獲得控制權,並表示類似於眾所周知的U-Boot的引導加載程序的映像,或者表示UEFI環境的映像,UEFI環境是服務器系統的標准配置。             

ATF模塊初始化的總體圖如圖2所示。

2. ATF模塊初始化。             

在某些基於ARMv8的服務器系統中可以使用另一個初始化路徑:ATF在UEFI PEI階段啟動,之后轉換到UEFI DXE階段。             

armv8uefi與x86上的有很大不同。PEI和DXE(驅動程序)階段同時用於x86和ARMv8。然而,在許多ARMv8系統上,PEI階段顯著減少,並且在此期間不執行硬件初始化。該階段包括設置MMU轉換表、配置中斷控制器和CPU定時器(根據UEFI規范,此環境中唯一處理的中斷是定時器中斷)、構建EFI切換塊(HOB)和執行DXE內核。在這個階段,本地UEFI模塊傾向於使用上面描述的特定於平台的SMC調用。             

UEFI的大部分工作在DXE階段執行。首先,這涉及到加載和啟動硬件驅動程序,包括片上外圍設備和通過PCIe、USB、SATA等接口連接的外部設備。             

應該注意的是,基於ARMv8的系統在配置、設備檢測機制等方面與基於x86體系結構的類似系統有很大的不同。例如,x86的主要設備檢測機制是掃描PCI配置空間並為設備分配內存地址,這些設備必須對其進行解碼。在基於ARMv8的系統中,內置外設幾乎總是在內存空間中有固定地址(端口是未使用的,因為它們不受CPU體系結構的支持),並且在某些情況下在PCI配置空間中不可見。對於這樣的系統,有一個由平坦的設備樹組成的硬件描述,設備連接的樹狀描述也描述了諸如與這些設備相關聯的存儲器范圍和中斷號等資源。             

在更高級的系統中,soc支持通過PCI配置空間進行訪問,並包含通過增強配置訪問機制(ECAM)實現對該空間的訪問的控制器。由於這些單元的內存地址是固定的,因此通用的PCI設備配置機制不適用。具體而言,對於具有固定PCI設備地址窗口的系統,開發了增強的分配PCI功能,解決了這一矛盾。可以單獨寫一篇文章來介紹這種功能的獨特屬性。簡言之,它可以描述為一組替代寄存器,其中包含有關內存地址、總線號(對於內置PCI-PCI橋)等的信息。

UEFI與另一種傳遞平台配置信息的方法ACPI是分不開的。目前,為改進對ARMv8體系結構的支持而開發和完善ACPI規范的工作正在進行中。根據現有信息,ACPI應該成為描述ARMv8平台及其管理的基本信息(主要是處理器內核、PCI/PCIe控制器的數量和配置)及其管理的關鍵方法。一些計划發布的ARMv8操作系統只支持ACPI機制。             

DXE階段包括設備檢測和它們在UEFI中的初始化和注冊,以及操作系統啟動的准備。后者包括准備系統內存映射和配置信息,即加載、生成和發布ACPI表,修改這些表以反映平台的當前配置,對FDT進行類似的更改,以及檢查和生成校驗和。在此階段加載的模塊可以實現UEFI運行時服務(UEFI Runtime Services),這些功能可在運行時從操作系統調用。值得注意的是,在本文作者使用過的所有系統中,設備檢測都是通過PCI-ECAM機制實現的。             

完成此階段后,啟動設備選擇(BDS)開始。在這個階段通常使用一個單獨的模塊來處理“BootOrder”、“BootNext”和其他相關變量的值。通常,此模塊實現(偽)圖形用戶界面。此時,基於x86的系統有許多共同點:使用相同的引導方法–PXE、iSCSI、塊設備(如SATA/SAS/USB驅動器、SSD和NVME設備)等。              

有必要提醒讀者注意ARMv8 UEFI的外部設備(通常是PCIe設備)的驅動程序。它們可以以模塊的形式實現,這些模塊位於存儲設備(FAT32文件系統)中,也可以直接駐留在設備中(可選ROM)。在某些情況下,將ARMv8添加到支持的體系結構列表中會給供應商帶來問題。簡單地重新編譯ARMv8的源代碼並不總是足夠的,因為有些模塊並沒有設計成在完整的64位地址空間中工作。由於在ARMv8系統中廣泛使用PCI總線到處理器地址的轉換,反之亦然,也可能會出現困難。這是由於決定放棄位於內存地址空間低32位的舊“窗口”造成的。在支持增強方面,用EBC字節碼編譯的驅動程序可以提供所需的兼容性級別。然而,在撰寫本文時,ARMv8的EBC解釋器處於開發的早期階段。             

控制權轉移到加載到內存中的模塊(引導加載程序或直接進入操作系統內核)是根據UEFI規范執行的:模塊的UEFI句柄在X0寄存器中,系統表指針在X1中,返回地址在X30(LR)中。             

操作系統內核使用UEFI服務執行一些准備步驟,然后設置自己的轉換表並調用UEFI方法ExitBootServices()和SetVirtualAddressMap()。這是必要的,因為UEFI代碼在與操作系統內核相同的地址空間中執行。此外,定時器中斷和任何可能的DMA傳輸都必須被禁用。armv8linux操作系統設計有一個值得注意的方面:主內核代碼在EL1模式下執行,而EL2模式只保留給KVM管理程序代碼的一部分。因此,在初始化期間,內核將其特權級別從EL2降到EL1。之后,只有運行時服務(所有UEFI服務的子集)可用於內核。如前所述,ARMv8上的Linux內核在ATF模塊中實現時廣泛使用PSCI接口。這尤其是多核系統的特點。接口本身和二級CPU核心初始化過程可以簡單地描述為以PSCI函數號和初始化函數的入口點為參數發出SMC調用。事實上,對UEFI和SMC服務的調用是當前操作系統和固件之間交互的主要方式。有其他固件事件通知設施的規范草案,但到目前為止(2015年)還沒有任何完成實施的報告。             

總而言之,應該提到的是,本文沒有詳盡地描述基於ARMv8的固件組件的功能和交互。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM