2008年10月31日 星期五

關於EFI的一點介紹[轉貼]

本文主要分為如下幾個部分:
1、 EFI Overview :主要從整體上去描述一下什么是EFI。以及應用EFI對我們可能帶來的好處。
2、 Framework : 從原理,架搆等幾個方面重點介紹了EFI規範的一種標准實現Intel Platform Innovation Framework for EFI(以下簡稱Framework)。
3、 Development Tools :重點介紹了目前由AMI提供的開發工具Visual eBIOS。并簡單探討了Insyde公司的相關工具。 同時還介紹了American Arium公司提供的硬件仿真器以及調試軟件Source Point。
4、 EFI Development : Applications & Drivers :詳細探討了EFI開發的一些細節問題。并分析了一個簡單的EFI Applications。同時還探討了EFI Drivers。
5、 EFI Shell :探討了EFI Shell。

以上是主要的幾個討論方向,具體還會細分,詳見正文部分。

1、EFI Overview EFI綜述

1.1 Problems on legacy BIOS 傳統BIOS所面臨的難題
在仔細的探討EFI之前,我們先來回顧一下什么是BIOS。BIOS是英文Basic Input/Output System的縮寫,意為基本輸入輸出系統。從IBM於上世紀八十年代初推出了全世界第一台PC機開始,BIOS就成了個人計算機必備的系統軟件,用於管理基本的硬件,提供各種中斷調用,引導操作系統等等。可以看出,BIOS對於個人計算機來說,是非常重要的系統軟件,沒有BIOS的計算機是無法運行的。
傳統上的BIOS經過了長達20多年的時間,基本上沒有大的特別的改進,在操作系統已經完全32位化的今天,BIOS仍然停留在16位實模式時代。我們知道,在這個模式下,IA32架搆的CPU只能訪問1MB的基本內存,這就大大的***了程序員的創造性。同時,各種板卡上的BIOS在映射到系統內存中的時候,受到128Kbytes的大小***。這使得一台計算機不能安裝太多的板卡,否則他們的BIOS的容量將很容易突破128Kbytes,但是在一些服務器上,安裝很多板卡已經很常見。
同時由於BIOS一般選擇釆用匯編語言直接開發,使得開發入門難度很大。很多初級工程師甚至無法完成這樣的任務。并且各個公司之間的代碼不兼容,嚴重阻礙了其發展。

1.2 Intel’s solutions :EFI Intel的解決方案:EFI
EFI是Intel為了解決上述的BIOS難題而推出一項新技術,旨在向業界提供一種在未來20年內仍然可以應用的BIOS架搆。EFI是Extensible Firmware Inte***ce的縮寫。中文意思是可擴展固件接口。由於目前習慣上叫做EFI,本文將繼續稱其為EFI而不是它的中文譯名。
正如它的名字一樣,EFI并不是一套軟件,而是一整套定義的很好的接口。它是一種規範,Intel目前已經正式發布了EFI Specification Revisions 1.10。任何人都可以按照EFI寫出自己的實現來。而Intel也為我們准備好了一個標准的實現:Intel Platform Innovation Framework for EFI(以下簡稱Framework)。更加值得一提的是,Framework在BSD協議的規範下,已經實現了開放源代碼,這為我們今後開發在EFI之上的應用提供了充分的技術保障。

1.3 Benefits of the EFI EFI的優點
EFI設計的充分原則就是屏蔽掉下層的硬件,事實上通過我們的分析,EFI已經很有操作系統的味道,EFI大概包括如下的幾個部分:
1) Pre-EFI基礎代碼
2) 針對特定晶片的Pre-EFI模塊
3) DXE基礎代碼
4) DXE驅動(Framework)
5) DXE驅動(硬件)
6) 兼容性支持模塊CSM(可選,只支持IA32)
EFI通過上述的這些組成部分,提供了以往BIOS可以提供的全部功能,并且做了大量的更新。同時在容量上也做的相當的完美,可以放入4MB的Flash中。而啟動速度和喚醒速度也符合HDG標准。
更加重要的是,EFI要求使用C語言作為開發語言,這樣一來,使得我們可以更加容易的加入到BIOS的開發中來,同時也容易實現模塊化與標准化。完全模塊化的一個好處就是那些ODM或者OEM們可以方便添加他們想要的功能到EFI上。對我們而言,好處也是不言自明的,如果我們決定開始基於EFI的項目,那么我們可以在EFI中添加屬於我們自己的模塊,更加方便我們的用戶的定制,甚至為用戶提供個性化服務提供了可能。

1.4 Supported OS 操作系統系統支持情況
目前正式宣布支持EFI的操作系統包括Microsoft Windows Longhorn以及部分Linux。目前Longhorn已經進入了Beta1測試階段,Intel也在一個DEMO中展示了用EFI來引導Longhorn的實際情況。同時展示的還有如何用EFI去引導RedHat Linux(需要借助一個第三方的開源軟件ELILO)。至於其他的操作系統如Windows XP等,則暫時還不能支持EFI,所以只得使用CSM來達到引導目的。

2、 Framework

2.1 Framework Overview 架搆綜述
簡單的說,Framework就是EFI的一種實現,由Intel完成。完全實現了EFI Specification Revisions 1.10中提及的各項功能。開發者可以基於Framework,開發出各種EFI應用來。同時也可以為Framework新增新的功能。

2.2 Benefits of using the Framework 使用Framework的好處
最大的好處可以大大減輕我們的勞動量,我們只把注意力集中到最需要注意的地方上去,既然已經有了EFI的實現,并且是開源的實現,那么自然不需要我們再次實現一次。此外,Framework的其他一些好處還包括:
(1)跨平台Cross platform 目前Framework可以支持Intel IA32/64,XScale等硬件平台。同時我們注意到,Framework并不排斥其他平台,他擁有極高的可移植特性。
(2)模塊化設計Model Design Framework的所有特性都在驅動程序之中實現。而Framework本身則提供了高效的管理這些驅動程序的方法。比方說,你可以load一個驅動,而不需要重新啟動計算機;當你想更新已經load過的驅動,你只需簡單將它unload,然後再load新的驅動就可以了。對我們開發者而言,可以通過編寫我們自己的驅動,來為Framework提供我們自己需要的功能。
3) 快速的啟動時間Fast Startup Time 正如EFI要求的那樣,Framework的啟動時間非常迅速,在這一點上,它一點也不比那些傳統的BIOS落後。
此外,由於Framework是EFI的實現,所有EFI的優點應該說Framework也都具備。

2.3 The life cycle of the Framework Framework的生命周期
Framework的執行,是按照如下的順序來的:
(1)SEC :Security。這個是系統上電後立即進入的一個階段,在這一階段,Intel并沒有做太多的說明,相反,他們說這個階段可以由大家按照自己的需要利用。也就是說,我們可以安排我們自己想要的任何代碼在這個階段,比如一些身份驗證之類的,總之,SEC可以說給開發者帶來了充分的可定***務。
(2)Pre-EFI :正如它的名字一般,這個是在真正的EFI環境之前進入的一個狀態,這個狀態相當重要,以至於Intel花了很多時間來向我們闡述。根據目前的信息,這個階段大概會做很多初始化的工作,會初始化CPU,初始化主板上的一些控制器以及晶片組,更加重要的是,再這個階段內,會使用一種技巧,來迅速的建立起C 代碼的執行環境,也就是說,會建立一個堆棧。這樣,以後機器就可以運行那些由C語言編寫的軟件了。最後PEI內核會按照一種方法來加載所有的PEIM( Pre-EFI Module )。PEIM是一種可以運行在這個階段的一種模塊化的程序,任何人都可以開發自己的PEIM,加載的工作由PEIM Dispatcher完成。全部加載之後,PEI會調用DXE Main并將系統控制權交給下一個階段DXE。
(3)DXE :Driver Execution Environment。這應該說是最激動人心的階段,在這個階段,EFI真正的提供了一個類似OS一樣的東西。在上一個階段PEI,系統已經建立了C代碼執行的環境,那么從這個階段開始,所有的東西,都是用高級語言完成了。進入DXE後,會首先調用各種驅動,比如Video Driver,NIC Driver,Soundcards Driver,USB Driver,PCI Controller Driver等等。完成之後,就開始進行BOOT。而這就是下一個階段了。
(4)BDS :Boot Device Select。在這里,應該會有一個選擇,是進入OS呢?還是去執行那些EFI Applications ?選擇完成之後,就進入下一個階段了。
(5)TSL :Transient System Load。這個階段會按照在BDS階段選擇的結果來做不同的事情,如果選擇了進入OS,那么控制權會被傳遞給Final OS Loader。而如果是要去運行EFI Applications,那么控制權交給Transient OS Boot Loader,這樣就會建立起一個執行環境,之後就可以執行那些EFI Applications了。目前,應該會執行一個叫EFI Shell的程序。而傳統的BIOS Setup也被寫成一個EFI Applications。
(6)RT :Run Time。這個階段就是OS運行的階段。
(7)AL :After Life。這個是OS運行之後的階段,比如關機之類的。但OS崩潰之後也屬於這個階段,也就是說,在系統萬一崩潰之後,如果使用EFI,那么還是可以做許多事情的。
以上就是Framework的執行周期。我們可以看到,Framework除了做很多傳統BIOS的工作之外,還完成了很多其他的工作。比如建立起高級語言執行環境,調用設備驅動等等。最值得注意的是,甚至還有一個執行特定應用程序的機會。

3、Development Tools 開發工具
3.1 Overview 綜述
目前到底使用什么開發工具還不是很明晰。在這次Training上,為了給大家演示,使用的是Microsoft Visual Studio.NET 2003。不過那編譯的是一個Emulator程序,用來模擬真實的EFI環境,況且由於EFI是系統軟件,不太可能直接使用類似VS.NET這樣的高級開發工具。
後來在EFI Driver Development這門課程上,一位HP的工程師認為只要是C Compiler,理論上都可以開發。但是如果要編譯成EBC( EFI Byte Code )代碼的話,那么還得向Intel購買相應的編譯器。(我看了下價格,一個許可證是900多美金!靠!)將代碼編譯成EBC代碼的好處就是,不同的硬件架搆可以共同使用同一套最終的二進制代碼。比如,如果一個設備的Option ROM內的程序是編譯成EBC的話,那么該設備就可以不做任何的修改就可以直接支持IA32/64。而事實上,我們知道,目前Intel的64位安騰處理器與32位的Pentium4處理器在指令集上是不兼容的。那么這又是為什么呢?因為Intel在Framework內,提供了一個叫做EBC Virtual Machine Driver的Protocols。正是靠它,才實現了這樣一個功能。
不過一些第三方廠商到是展示了不少很不錯的開發工具。主要有AMI的開發工具Visual eBIOS,Insyde公司的調式工具H2ODDT,以及American Arium的硬件調式工具以及配套的軟件SourcePoint。

3.2 AMI Visual eBIOS
VEB是一款非常出色的開發工具,由著名的BIOS Venders AMI提供。他為EFI提供了大量的Value Add的工具,AMI認為,Intel的EFI僅僅只是一個骨架(Skeleton)。而他們的VEB則為其穿上了衣服,并為不同的應用目的而做了大量的個性化開發。

3.3 Insyde H2ODDT
由於Insyde公司之前很少進入中國市場,所以我們對其產品了解不深,這款軟件從介紹上看,似乎是專門用於調式Framework的。其余的詳細細節還有待繼續研討。

3.4 American Arium
American Arium是老牌的硬件調式器供應商,他們這次帶來了ECM-50與ECM-XDP。之間的差別似乎僅僅是ECM-XDP只支持那些使用XDP接口的處理器。而ECM-50則支持ITP與XDP接口。同時還演示了配套的軟件SourcePoint。從展示來看,這似乎是目前最好的調式工具,可以直接從硬件上去調式,完全跟蹤。并且支持C Source level的調試。不過根據我們猜測,這套調試工具的價格一定不菲。

4、 EFI Development : Applications & Drivers
EFI 開發 :應用程序與驅動程序

使用EFI的一個很大的好處就是有EFI Application和EFI Drivers。我下來會分別給予討論,事實上,Intel自己也認為,App和Driver在本質沒什么不同。都是一段程序,只是他們的側重點有所不同而已。App需要和用戶交互,而Driver則主要提供某種服務。

4.1 EFI Applications EFI應用程序

4.1.1 Module of the EFI Applications EFI應用程序的類型
目前有好幾種編寫EFI Applications的方法,分別是基於EFI的,基於EFI Library的,基於C Library以及基於C Standard library的。根據Intel的說法,編譯出來的應用程序的體積是一個比一個大,所以,如果想獲得最小的體積,那么就應該使用基於EFI的方法,這也是Intel所推荐的。

4.1.2 A EFI Applications based on EFI 一個基於EFI的簡單應用
最簡單的方法就是親自來看一個EFI App,下面我們就展示一個最簡單的EFI App。

#include <>

EFI_STATUS
InitializeDemoApp(
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
SystemTable->ConOut->OutputString(SystemTable->ConOut, L“DEMO Application” ) ;
return EFI_SUCCESS ;
}

這個程序的工作很簡單,就是打印一個字串到終端設備上。類似於我們常見的HelloWorld。從這個程序中,我們可以看出幾點:
(1)所有基於EFI的應用成都必須包含頭文件efi.h
(2)主函數必須被申明成EFI_STATUS
(3)必須在參數前加IN或者OUT或者OPTIONAL來說明參數的類型。這些修飾符是Intel在efidef.h中定義的。目前是空的,不過為了未來的兼容性,所以還是加上的好。
可以看出,單單就入門而言,由於是使用C語言開發,所以入門門檻很低,大多數的工程師都很輕松的加入到開發隊伍中來。至於其他的編程模型,與上述的基於EFI的方法大同小異,只是所使用的庫不同,在此就不在重復了。

4.2 EFI Drivers EFI驅動程序
現在簡單的介紹一下EFI Drivers,事實上驅動程序與一般的應用沒什么區別,只不過驅動不能直接執行,而是在EFI的調度下在後台執行,同時驅動可以接觸硬件。當然也有不接觸硬件的驅動,那叫Service Driver,是用來提供某種服務的,比如EFI EBC Virtual Machine就是一種Service Driver。EFI本身提供了很強大并且的高效的管理這些驅動的方法,當需要一個驅動的時候,我們可以load它,而當有了新版本或者該驅動所管理的硬件已經不在需要的時候,我們可以很方便的unload它。Intel已經提供了一個工具,叫DWW,用他可以很方便的生成基於EFI的驅動程序模型。

5, EFI Shell

5.1 EFI Shell Overview EFI Shell綜述
什么是EFI Shell?首先它是一個基於EFI的應用程序,其次它非常類似我們在Windows中遇到的cmd或者在Linux中的shell。事實上,這就是一個操作環境,一個外殼程序,它負責接收用戶的輸入,將用戶的輸入解釋并告訴內核執行,同時將執行結果顯示出來。它完成和用戶的交互功能。所以,EFI Shell是非常重要的應用程序。

5.2 A EFI Shell Commands EFI Shell命令
EFI Shell使用字符界面和用戶交互,這里列出一些可能用到的命令以便參考。
( 1)pci : 顯示PCI設備或者PCI配置信息
( 2)mm :顯示或者修改內存,I/O以及PCI資源。
( 3)mem :顯示系統內存或者設備內存的情況。
( 4)memmap :顯示由EFI Environment創建的Memory Map。
( 5)drivers :按照EFI Driver 的類型來逐一顯示所有的已經安裝的驅動程序。
( 6)devices :顯示所有已經被EFI Driver控制的設備。
( 7)devtree :按照EFI Driver的類型來顯示設備樹。
( 8)dh :顯示在EFI Environment中的所有的Handles。
( 9)connect :將一個Driver綁定到一個設備并啟動設備。
(10)load :將一個Driver讀入內存。
(11)unload :將一個Driver從內存中卸載。
本文由xinxiaoc 發表於
http://bbs.matwav.com/post/view?bid=103&id=250675&sty=1

1 則留言:

匿名 提到...

關於 Intel EFI 的事情, 提供給版主參考 :
1. 據小弟當年所知, 推行 EFI 至今應該有 8 年以上,
當初 BIOS 廠商的興趣不高, 便透過一些 "策略性" 手法,
才有辦法慢慢引入, 至今 2011~2012 左右, 仍有部分非PC/NB性質的顧客,
對此有所質疑其必要性 (Why to change ?)

2. EFI BIOS 內涵 , 其實若版主深入其核心, 仍舊必須要 Assembly
Code 為前導(即:早期 BIOS 語言架構), 截至目前清楚對 EFI語
言是仿 C/C++ 的訊息, 僅看到香港某硬體 3C 的論壇報導;
再者, EFI 開機過程其實與早期 BIOS 語言差異不大

3. EFI 提到 Driver ? 這其實僅針對習以為常的 OS 階層設計者而言,
目前並沒有看到哪一家廠商針對此真的寫一套 "Driver" 使用 (不保證沒有), 相對於早期 BIOS 來講, 僅僅是 Initial(初始化設定)的工作;反過來說, 現代人用了最新 EFI BIOS, 都不用在 OS 掛 Driver 嗎?

4. 為什麼要 EFI 語法呢 ? 我個人對此仍舊抱持極大質疑,
早期 Assembly 語法即便過時(少人使用), 仍舊有 32 Bit Assembly 可用, 當然不排除有 MS 版權之問題, 也因此造成各家設計師轉換的極大不便, 比方: 記憶體定址區域, 以 C/C++ 規劃一塊來用, 卻不曉得被配在哪個 RAM的 Range, 相較於 Assembly 卻來的更精確而不被採線誤用...諸如此類

5. SIZE 差異: C/C++的語言相對於 Assembly 來的肥大, 同樣功能的BIOS 製作出來, EFI 必須占用更大的儲存裝置(ROM), 不信您可以去問業界人士

6. 有些廠商推 EFI BIOS 可使用滑鼠, 塞入遊戲, 聽CD不必進 OS !?
(1)早期的 Assembly BIOS 就已經能用滑鼠了, 何需現在可用 ?
(2)BIOS 為什麼要塞入遊戲 ? 開機不是為了使用 OS 嗎 ?
(3)聽CD不想進 OS ? 直接用 MP3隨身聽就行了, 電腦只要一通電,
所有裝置都一定會吃(基本耗電問題)

綜上所述, 小弟在業界看到 "浪費設計人力資源", 並沒有對設計者與USER 太大益處, 就像同樣的機體架構, 換了不同類型而行為類似的腦袋

一個小故事讓我們明白資金流通的意義

“又是炎熱小鎮慵懶的一天。太陽高掛,街道無人,每個人都債台高築,靠信用度日。這時,從外地來了一位有錢的旅客,他進了一家旅館,拿出一張1000 元鈔票放在櫃檯,說想先看看房間,挑一間合適的過夜,就在此人上樓的時候---- 店主抓了這張1000 元鈔,跑到隔壁屠戶那裡支付了他欠的肉錢...