小華的部落格: EFI Framework 概述

搜尋此網誌

網頁

星期四, 11月 15, 2007

EFI Framework 概述

如果有下載Intel EFI Spec的人就知道每次提到EFI的時候就會有一個很大的綠色的H,這個就是EFI 的framework。

什麼是Framework呢? 這邊就簡單說一下整個EFI framework架構。

我個人猜想,當初Intel 開發EFI其實只是為了要擴充BIOS的功能,因為在Legacy BIOS的年代,很多的東西都沒有模組化,因此當硬體或是Platform有比較大的變動的時候,對於整個BIOS開發的時間就會延長,那種感覺就好像是你每次都要對一個新的硬體重新寫一次你的BIOS程式碼,很沒有效率。

另外在Legacy BIOS年代,所有的BIOS程式碼的開發幾乎都是不同的BIOS vendor與Chipset 廠商ㄧ同合作,因此不同家的BIOS Vendor對於相同Chipset 廠商所寫出來的程式碼的穩定度就會不同,這對於 Intel 來說就等於要多花好幾倍的時間去跟不同BIOS Vendor 來討論以及處理問題。

因此,假如Intel 能夠把底層的BIOS程式碼變成模組化容易抽換,那麼BIOS在開發的過程中就會快速以及方便許多,而這種概念就像是Windows裡面的HAL 層的概念,簡單說在Windows系統中實際存取硬體是透過ㄧ個叫做HAL介面的處理,所以當Windows想要在不同的硬體上執行的時候,他只要把HAL的介面換成新的硬體的處理方式就可以了,而在Windows可以不用再重新改寫,例如你把Windows拿到Apple上面去執行,對於微軟的工程師來說,只要把HAL從新改寫就可以了。

而EFI的Framework 就像是HAL,Intel 本身提供了一些Protocol以及一些Lib來存取他們的硬體,而這一層就叫做Framework。對於Intel來說,不管你是哪一家的BIOS Vendor就不會再出現A廠商存取Intel Chipset有問題而B廠商不會,因為最底層都是Intel 自己負責。

而建構在Framework 上的一些功能就是各家BIOS Vendor自己去負責,感覺就像我之前說的,Inetl 留下一些地方給BIOS Vendor填寫他們的程式碼,然後BIOS Vendor在留下一些地方給OEM/ODM BIOS填寫ㄧ些程式碼,彼此關係就是一層一層環環相扣。

這邊還要提到EFI Framework 除了前面說的那些之外,他還提供了一些Boot Flow的控制,這就像是說從Power On--->POST--->Boot to OS的一些流程的控制也是由這個Framework 提供,感覺就像是你寫了一個main{},而裡面的FunA()/FunB()/FunC() 的先後順序的執行你也都寫好了,之後FunA() 內要填什麼樣的子程式碼就屬於BIOS Vendor跟OEM/ODM BIOS自己決定了。
//--------------------------------------------------
// EFI Framework 的概念與C語言對應的示意圖
//--------------------------------------------------
#include <--Intel提供的函數
main() <--Intel 提供的Boot Flow
{
Dispatch FunA(); <--SEC
Dispatch FunB(); <--PEI
Dispatch FunC(); <--DXE
Dispatch FunD(); <--BDS
...
}

EFI Framework還有另一個優點就是移植性高,例如Intel 可以把整個EFI Framework概念移到嵌入式系統上去實做BIOS,這樣子他們能夠開發的市場就會越來越大。

前面提到這些都是Intel提供的EFI Framework,那麼AMD/其他廠商怎麼辦? 對,我也在想這個問題,由上面的說法可以看出Intel 的野心,他想把原本BIOS Vendor做的事情自己拿來做,為了不讓人家知道太多Chipset內的秘密,他自己寫Chipset的函數並做成Framework給BIOS vendor使用,所以我個人在思考幾個問題:

a) 假設不同 BIOS Vendor 都使用相同的函數的情況下,彼此的優缺點是不是只剩下誰提供的OEM/ODM Features比較多 ?

b) 假設不同 BIOS Vendor 都使用相同的Framework下,當底層換成AMD或是其他廠商後,彼此的優缺點是不是只剩下誰對不同廠商的支援度比較高,市場佔有率就比較高?

c)假設OEM/ODM BIOS 都使用相同的Framework後,開發時間縮短相對的被取代的性質是否也相對提高?

d) Others..

以上大致上就是個人對於EFI Framework 的一些理解跟想法,如有誤請先進不吝指正,謝謝!

3 則留言:

Unknown 提到...

小華您好
小弟我剛踏入bios這行工作,沒想到才一個月就開始k EFI的東西了,對於bios這方面的東西其實還沒有很完全的了解,您的網站真的是對於我們這些新手有很大的幫助,希望能多多補充一些bios 或 EFI 的資訊!!
感謝您~

匿名 提到...

小華大大 , 您好 :
您提供的資訊相當的豐富 , 可以令 Legacy 剛轉入 EFI 的人建立一些基礎觀念 ,
但對於本文的前述 , "因此當硬體或是 Platform 有比較大的變動 ... 重新寫一次你的BIOS程式碼"
小弟有些不同的看法 : 就 BIOS Vendor 而言 , 所有的 Code 已經不再是
如同草創初期般的 UnStable , 原則上各家已有各家的 Know How 存在 ,並不會因為 Platform 內的 Function 增刪而需要將原先自家的架構破壞 ;

簡而言之 , Power On Sequence 在誤差範圍內 & Function 的 Init 只要能正常,板子開起來就好了 , 剩下的就是 OS (XP / LINUX) 的事情

只是推了新架構這麼久 , "也許" 獲益還沒回收 , 將 Porting Guide / Initial Code 變更成自己預期的 , 致使合作的 Firmware 不得不屈就
...以上是小弟就之前先後在 Chip 廠 & BIOS Service 的角度粗觀來看

"也許" 日後真會像小華大大 , 在文末所言....

說是 Coding 藝術 / 工藝的變革
, 還不如說 : 弄點花樣娛樂又或是...為了錢

波濤洶湧中 , 找不到真切...

小華的部落格 提到...

感謝你的意見!你的想法是對的!對於BIOS廠商來說移植一整套code在一個穩定的Codebase上是很方便的事情!

只是當Legacy所設計出來的模組化概念與EFI模組化的概念相比較時,就會突顯出EFI BIOS的模組化觀念與Legacy之間的差別! ^^