顯示具有 BIOS 標籤的文章。 顯示所有文章
顯示具有 BIOS 標籤的文章。 顯示所有文章

2011年1月27日 星期四

freevanx's UEFI/BIOS training home

freevanx's UEFI/BIOS training home

freevanx寫了一些關於EFI的資料, 有興趣的可以去參考一下囉!
ASL簡介寫的不錯呢!雖然資料舊了點, 但可以用來入門不錯!
By 於 沒有留言:
標籤：

2009年1月18日 星期日

從VT-x到VT-d Intel虚擬化技術發展藍圖[轉貼]

當前非常熱門的Virtualization虚擬化技術的出現和應用其實已經有數十年的歷史了，在早期，這個技術主要應用在服務器以及大型主機上面，現在，隨着PC性能的不斷增長，Virtualization也開始逐漸在x86架構上流行起來。

虚擬化技術將各種資源虚擬出多台主機，以提高這些資源的共享率和利用率，虚擬化可以將IT環境改造成為更加强大、更具彈性、更富有活力的架構。通過把多個操作系統整合到一台高性能服務器上，最大化利用硬件平台的所有資源，用更少的投入實現更多的應用，還可以簡化IT架構，降低管理資源的難度，避免IT架構的非必要擴張。客户虚擬機的真正硬件無關性還可以實現虚擬機的運行時遷移，可以實現真正的不間斷運行，從而最大化保持業務的持續性，而不用為購買超高可用性平台而付出高昂的代價。

和Sun上的虚擬化技術（CPU分區）比起來，x86上的虚擬化要落後不少的，然而確實在不斷進步着，在數年前，x86上還没有什麽硬件支持，甚至連指令集都不是為虚擬化而設計，這時主要靠完全的軟件來實現虚擬化，當時的代表是VMware的産品，以及尚未被Microsoft收購Connectix開發的Virtual PC，在服務器市場上應用的主要是VMware的産品，包括GSX Server和稍後的ESX Server，這些軟件虚擬化産品在關鍵指令上都采用了二進制模擬/翻譯的方法，開銷顯得比較大，後期出現了Para-Virtualization部分虚擬化技術，避免了一些二進制轉换，性能得到了提升，不過仍然具有隔離性的問題。

今天，虚擬化技術的各方面都有了進步，虚擬化也從純軟件逐深入到處理器級虚擬化，再到平台級虚擬化乃至輸入/輸出級虚擬化，代表性技術就是Intel Virtualization Technology for Directed I/O，簡寫為Intel VT-d，在介紹這個Intel VT-d之前，我們先來看看x86硬件虚擬化的第一步：處理器輔助虚擬化技術，也就是Intel Virtualization Technology，分為對應Itanium平台的VT-i和對應x86平台的VT-x兩個版本。AMD公司也有對應的技術AMD-V，用于x86平台。我們介紹的是x86平台上的VT-x技術，VT-i技術原理上略為相近。
純軟件虚擬化主要的問題是性能和隔離性。Full Virtualization完全虚擬化技術可以提供較好的客户操作系統獨立性，不過其性能不高，在不同的應用下，可以消耗掉主機10%~30%的資源。而OS Virtualization可以提供良好的性能，然而各個客户操作系統之間的獨立性并不强。無論是何種軟件方法，隔離性都是由Hypervisor軟件提供的，過多的隔離必然會導致性能的下降。
這些問題主要跟x86設計時就没有考慮虚擬化有關。我們先來看看x86處理器的Privilege特權等級設計。

x86架構為了保護指令的運行，提供了指令的4個不同Privilege特權級彆，術語稱為Ring，從Ring 0～Ring 3。Ring 0的優先級最高，Ring 3最低。各個級彆對可以運行的指令有所限制，例如，GDT，IDT，LDT，TSS等這些指令就只能運行于Privilege 0，也就是Ring 0。要注意Ring/Privilege級彆和我們通常認知的進程在操作系統中的優先級并不同。
操作系統必須要運行一些Privilege 0的特權指令，因此Ring 0是被用于運行操作系統内核，Ring 1和Ring 2是用于操作系統服務，Ring 3則是用于應用程序。然而實際上并没有必要用完4個不同的等級，一般的操作系統實現都僅僅使用了兩個等級，即Ring 0和Ring 3，如圖所示：

也就是説，在一個常規的x86操作系統中，系統内核必須運行于Ring 0，而VMM軟件以及其管理下的Guest OS却不能運行于Ring 0——因為那様就無法對所有虚擬機進行有效的管理，就像以往的協同式多任務操作系統（如，Windows 3.1）無法保證系統的穩健運行一様。在没有處理器輔助的虚擬化情况下，挑戰就是采用Ring 0之外的等級來運行VMM (Virtual Machine Monitor，虚擬機監視器)或Hypervisor，以及Guest OS。
現在流行的解决方法是Ring Deprivileging（暫時譯為特權等級下降），并具有兩種選擇：客户OS運行于Privilege 1（0/1/3模型），或者Privilege 3（0/3/3模型）。
無論是哪一種模型，客户OS都無法運行于Privilege 0，這様，如GDT，IDT，LDT，TSS這些特權指令就必須通過模擬的方式來運行，這會帶來很明顯的性能問題。特彆是在負荷沉重、這些指令被大量執行的時候。
同時，這些特權指令是真正的“特權”，隔離不當可以嚴重威脅到其他客户OS，甚至主機OS。Ring Deprivileging技術使用IA32架構的Segment Limit（限制分段）和Paging（分頁）來隔離VMM和Guest OS，不幸的是EM64T的64bit模式并不支持Segment Limit模式，要想運行64bit操作系統，就必須使用Paging模式。
對于虚擬化而言，使用Paging模式的一個致命之處是它不區分Privileg 0/1/2模式，因此客户機運行于Privileg 3就成為了必然（0/3/3模型），這様Paging模式才可以將主機OS和客户OS隔離開來，然而在同一個Privileg模式下的不同應用程序（如，不同的虚擬機）是無法受到Privileg機構保護的，這就是目前IA32帶來的隔離性問題，這個問題被稱為Ring Compression。

IA32不支持VT，就無法虚擬64-bit客户操作系統
這個問題的實際表現是：VMware在不支持Intel VT的IA32架構CPU上無法虚擬64-bit客户操作系統，因為無法在客户OS之間安全地隔離。
作為一個芯片輔助（Chip-Assisted）的虚擬化技術，VT可以同時提升虚擬化效率和虚擬機的安全性，下面我們就來看看Intel VT帶來了什麽架構上的變遷。我們談論的主要是IA32上的VT技術，一般稱之為VT-x，而在Itanium平台上的VT技術，被稱之為VT-i。
VT-x將IA32的CU操作擴展為兩個forms（窗體）：VMX root operation（根虚擬化操作）和VMX non-root operation（非根虚擬化操作），VMX root operation設計來供給VMM/Hypervisor使用，其行為跟傳統的IA32并無特彆不同，而VMX non-root operation則是另一個處在VMM控制之下的IA32環境。所有的forms都能支持所有的四個Privileges levels，這様在VMX non-root operation環境下運行的虚擬機就能完全地利用Privilege 0等級。

兩個世界：VMX non-root和VMX root
和一些文章認為的很不相同，VT同時為VMM和Guest OS提供了所有的Privilege運行等級，而不是只讓它們分彆占據一個等級：因為VMM和Guest OS運行于不同的兩個forms。
由此，GDT、IDT、LDT、TSS等這些指令就能正常地運行于虚擬機内部了，而在以往，這些特權指令需要模擬運行。而VMM也能從模擬運行特權指令當中解放出來，這様既能解决Ring Aliasing問題（軟件運行的實際Ring與設計運行的Ring不相同帶來的問題），又能解决Ring Compression問題，從而大大地提升運行效率。Ring Compression問題的解决，也就解决了64bit客户操作系統的運行問題。
為了建立這種兩個虚擬化窗體的架構，VT-x設計了一個Virtual-Machine Control Structure（VMCS，虚擬機控制結構）的數據結構，包括了Guest-State Area（客户狀態區）和Host-State Area（主機狀態區），用來保存虚擬機以及主機的各種狀態參數，并提供了VM entry和VM exit兩種操作在虚擬機與VMM之間切换，用户可以通過在VMCS的VM-execution control fields裏面指定在執行何種指令/發生何種事件的時候，VMX non-root operation環境下的虚擬機就執行VM exit，從而讓VMM獲得控制權，因此VT-x解决了虚擬機的隔離問題，又解决了性能問題。
我們可以看到，Inter VT的出現，可以解决了重要的虚擬處理器架構問題，讓純軟件虚擬化解决方案的性能問題得以大大緩解。然而要做的事情還有很多。
我們知道對于服務器而言，很重要的一個組成部分就I/O，CPU的計算能力提升雖然可以更快地處理數據，但是前提是數據能够順暢的到達CPU，因此，無論是存儲，還是網絡，以及圖形卡、内存等，I/O能力都是企業級架構的一個重要部分。為此，人們不但在傳輸帶寬上投資（比如從百兆以太網到千兆以太網再到萬兆以太網），還在各種系統和架構上進行了大量的投入（比如吞吐量更高的RAID系列、多層數據中心）。
在虚擬化技術中，隨着整體處理器資源的利用效率的提升，對數據I/O也提出了更高的要求。
VMM虚擬機管理器必須提供I/O虚擬化來支持處理來自多個客户機的I/O請求，當前的虚擬化技術采用下列的方式來處理I/O虚擬化。

Full Virtualization


模擬I/O設備：VMM對客户機摸擬一個I/O設備，通過完全模擬設備的功能，客户機可以使用對應真實的驅動程序，這個方式可以提供完美的兼容性（而不管這個設備事實上存不存在），但是顯然這種模擬會影響到性能。作為例子，各種虚擬機在使用軟盤映像提供虚擬軟驅的時候，就運行在這様的方式，以及Virtual PC的模擬的真實的S3 Virge 3D顯卡，VMware系列模擬的Sound Blaster 16聲卡，都屬於這種方式。

Para- Virtualization


額外軟件界面：這個模型比較像I/O模擬模型，VMM軟件將提供一系列直通的設備接口給虚擬機，從而提升了虚擬化效率，這有點像Windows操作系統的DirectX技術，從而提供比I/O模擬模型更好的性能，當然兼容性有所降低，例如VMware模擬的VMware顯卡就能提供不錯的顯示速度，不過不能完全支持DirectDraw技術，Direct3D技術就更不用想了。相似的還有VMware模擬的千兆網卡，等等，這些品牌完全虚擬的設備（例如，VMware牌顯卡，VMware牌網卡）需要使用特制的驅動程序部分直接地和主機、硬件通信，比起以前完全模擬的通過虚擬機内的驅動程序訪問虚擬機的十兆百兆網卡，可以提供更高的吞吐量。
現在的I/O設備虚擬化主要是采用模擬方式或者軟件接口方式，因此性能上很容易成為瓶頸——畢竟傳統的機器上，I/O設備都很容易成為瓶頸，因此Intel就適時提出了Intel Virtualization Technology for Directed I/O，簡稱為Intel VT-d。
I/O虚擬化的關鍵在于解决I/O設備與虚擬機數據交换的問題，而這部分主要相關的是DMA直接内存存取，以及IRQ中斷請求，只要解决好這兩個方面的隔離、保護以及性能問題，就是成功的I/O虚擬化。


和處理器上的Intel VT-i和VT-x一様，Intel VT-d技術是一種基于North Bridge北橋芯片（或者按照較新的説法：MCH）的硬件輔助虚擬化技術，通過在北橋中内置提供DMA虚擬化和IRQ虚擬化硬件，實現了新型的I/O虚擬化方式，Intel VT-d能够在虚擬環境中大大地提升 I/O 的可靠性、靈活性與性能。
傳統的IOMMUs（I/O memory management units，I/O内存管理單元）提供了一種集中的方式管理所有的DMA——除了傳統的内部DMA，還包括如AGP GART、TPT、RDMA over TCP/IP等這些特彆的DMA，它通過在内存地址範圍來區彆設備，因此容易實現，却不容易實現DMA隔離，因此VT-d通過更新設計的IOMMU架構，實現了多個DMA保護區域的存在，最終實現了DMA虚擬化。這個技術也叫做DMA Remapping。

I/O設備會産生非常多的中斷請求，I/O虚擬化必須正確地分離這些請求，并路由到不同的虚擬機上。傳統設備的中斷請求可以具有兩種方式：一種將通過I/O中斷控制器路由，一種是通過DMA寫請求直接發送出去的MSI（message signaled interrupts，消息中斷），由于需要在DMA請求内嵌入目標内存地址，因此這個架構須要完全訪問所有的内存地址，并不能實現中斷隔離。
VT-d實現的中斷重映射（interrupt-remapping）架構通過重新定義MSI的格式來解决這個問題，新的MSI仍然是一個DMA寫請求的形式，不過并不嵌入目標内存地址，取而代之的是一個消息ID，通過維護一個表結構，硬件可以通過不同的消息ID辨認不同的虚擬機區域。VT-d實現的中斷重映射可以支持所有的I/O源，包括IOAPICs，以及所有的中斷類型，如通常的MSI以及擴展的MSI-X。
VT-d進行的改動還有很多，如硬件緩衝、地址翻譯等，通過這些種種措施，VT-d實現了北橋芯片級彆的I/O設備虚擬化。VT-d最終體現到虚擬化模型上的就是新增加了兩種設備虚擬化方式：

左邊是傳統的I/O模擬虚擬化，右邊是直接I/O設備分配
直接I/O設備分配：虚擬機直接分配物理I/O設備給虚擬機，這個模型下，虚擬機内部的驅動程序直接和硬件設備直接通信，只需要經過少量，或者不經過VMM的管理。為了系統的健壯性，需要硬件的虚擬化支持，以隔離和保護硬件資源只給指定的虚擬機使用，硬件同時還需要具備多個I/O容器分區來同時為多個虚擬機服務，這個模型幾乎完全消除了在VMM中運行驅動程序的需求。例如CPU，雖然CPU不算是通常意義的I/O設備——不過它確實就是通過這種方式分配給虚擬機，當然CPU的資源還處在VMM的管理之下。
I/O設備共享：這個模型是I/O分配模型的一個擴展，對硬件具有很高的要求，需要設備支持多個功能接口，每個接口可以單獨分配給一個虚擬機，這個模型無疑可以提供非常高的虚擬化性能表現。
運用VT-d技術，虚擬機得以使用直接I/O設備分配方式或者I/O設備共享方式來代替傳統的設備模擬/額外設備接口方式，從而大大提升了虚擬化的I/O性能。

主流雙路Xeon Stoakley平台將支持Intel VT-d技術

高端四路Caneland平台也會支持VT-d功能
根據資料表明，不日發布的Stoakley平台和Caneland平台上將包含VT-d功能，Stoakley平台是現在的Bensley的下一代産品，用于雙路Xeon處理器，而Caneland則是Truland的繼任者，用于四路Xeon處理器，這些芯片組都能支持最新的45nm Penryn處理器。

從Intel虚擬化技術發展路綫圖來看，虚擬化無疑是從處理器逐漸擴展到其他設備的，從VT-i/VT-x到VT-d就非常體現了這個過程，對于關注I/O性能的企業級應用而言，完成了處理器的虚擬化和I/O的虚擬化，整個平台的虚擬化就接近完成了，因此在未來，Intel將會持續地開發VT-d技術，將各種I/O設備中加入虚擬化特性，從而提供一個强大的虚擬化基礎架構。

資料來源:
http://www.wlkj.net/redirect.php?tid=34660&goto=lastpost
http://www-07.ibm.com/tw/imc/seminar/download/200711_C_2.ppt
漫談CPU虛擬技術之Intel篇
影片:IBM何謂虛擬化技術？
影片:IBM BladeCenter 虛擬化I/O技術
影片:IBM 第四代多處理器伺服器為虛擬化環境所帶來的好處
IBM虛擬化新五步
IBM多系統虛擬技術運作優勢白皮書
Xen and the Art of Virtualization
Linux_Weather_Forecast/virtualization

By 於 沒有留言:
標籤：

2009年1月16日 星期五

CES 2009：Phoenix的HyperSpace可讓Windows與BIOS裡的OS同時運行

Phoenix（鳳凰科技）這次在CES 2009展示了新的BIOS技術，名為 "HyperSpace" 。這項技術的用意，簡單來說就是可以讓Windows與內嵌在BIOS的作業系統同時運行，並且可以即時切換，如果只是要單純上網或發E-mail，就可在HyperSpace裡完成，可以兼具省電與便利性（因為開機較快）...

HyperSpace很類似華碩的ExpressGate功能，不過HyperSpace感覺上在技術上又更複雜了些，Annti先將Hyperspcae的重要特色交代如下：

1.因為會用到虛擬化技術（VT-x或SVM），所以CPU要支援虛擬化技術
2.開機進入到HyperSpace的OS約14秒
3.Windows與HyperSpace的OS同時運行，並有硬體快速鍵切換（據說是F4），切換成HyperSpace模式後，Windows會進入待機或休眠狀態（依HyperSpace版本而定）
4.一直HyperSpace模式運作，續航力可再多延長25％
5.HyperSpace的OS為Linux，有瀏覽器、收發MAIL、即時通訊與多媒體（播放DVD或聽MP3）
6.因為是基於硬體端上運作，即使Windows掛了，仍可進入HyperSpace
7.可與Phoenix其他功能結合，如在IDF展出的FailSafe安全技術，或是BelnSync（可將資料透過網路備份、同步或分享）
8.結合筆電的上網能力（WLAN或3.5G），可透過網路作遠端遙控、鎖機或IT維護
9.HyperSpace有兩種模式，使用虛擬化技術叫 "HyperSpace Hybrid" ，如果CPU沒有虛擬化技術也可使用，只是兩者無法同時開啟並存，叫做 "HyperSpace Dual" 。
10.可依廠商需求來客製化HyperSpace的功能，也能在輕省筆電（Netbook）上運作

具有HyperSpace功能的筆電，除了可以模式切換，並且能同時並存運作。

BelnSync是未來鳳凰另一個新計畫，在BIOS裡（如Hyperspace或FailSafe）可將資料透過網路同步、分享或備份等動作，而不用開啟作業系統。

以下為HyperSpace的情境影片：


Why use HyperSpace


HyperSpace Switch


HyperSpace Demo


資料來源:
http://chinese.engadget.com/2009/01/07/new-bios-technology-phoenix-hyperspace/
By 於 沒有留言:
標籤：

2008年12月25日 星期四

EFI - SEC(Security)階段

EFI - SEC(Security)階段

SEC階段是EFI的第一個執行階段，當電腦Power-On時就會進入此階段，原則上EFI只有這個部份會使用組合語言搭配C語言撰寫，此階段的重點目的是把CPU的SP(Stack Pointer)指到CPU內部的Cache中。

SEC階段主要功能
  1. 掌控平台的restart事件

  2. Real Mode to Protected Mode

  3. 使用CPU Cache當做記憶體(Creates a temporary memory store)

    4. 因為在此階段時，北橋裏的Memory Controller還沒有初使化，尚無法使用系統記憶體，但C語言執行時需要Stack Area，因此暫時先拿Cache來做堆疊區。
  4. 進入下個PEI階段(Passes handoff information to the PEI)


更詳細的參考資料可以看Intel® Platform Innovation Framework for EFI Architecture Specification - Draft for Review
By 於 沒有留言:
標籤：

2008年11月8日 星期六

EFI UGA & Simple Pointer[轉貼］

年前學習了有關UGA & Simple Pointer的知識，今天拿出來，總結一下。方便自己以後的理解和查閲。
UGA
UGA是 Universal Graphics Adapter （通用圖形適配器）的縮寫。在本質上講，UGA 是一個EFI driver。它在OS導入前和OS運行時都能被使用。

1，Universal Graphics Adapter Protocols主要描述了有關在EFI環境下的圖象顯示。這個部分包含了 UGA Draw Protocols 和 UGA I/O protocol 。前者描述了如何在 pre-OS space 繪入圖象，在圖象屏幕上顯示出來；後者描述了如何訪問圖象屏幕，以及支持視頻控制器的子設備，例如：圖象顯示設備。同時，後者的目標是在 OS 當前的環境下，實現初步的使用。

2，UGA ROM 是一個軟件的概念，它的目標是來支持可預知圖形硬件，并不要求VGA硬件。（不是很清楚）

3，UGA Draw Protocol 支持三個成員函數，來支持 pre-OS space 有限的圖形需求。這些成員函數允許調用者draw到虚擬的 frame buffer 裏面，來獲得當前的視頻模式，以及設置視頻模式。這些簡單的原始函數已經能充分的滿足pre-OS firmware code的總的需要。

4，在 EFI_UGA_DRAW_PROTOCOL 基本圖形操作是 Blt（Block Transfer）。Blt操作允許數據讀出和寫入視頻適配器的視頻存儲器裏。frame buffer 視頻顯示是由一組像素。每個像素在視頻顯示上的位置由 X 和 Y 坐標描述。X 代表了一個掃描行。一個掃描行是指顯示的水平的像素大小。 software Blt buffer 也是由一組像素來組成的。在buffer 裏的第一個元素是Pixel (0, 0) 。Blt buffer 可以看成是一系列的掃描行。一個像素在視頻顯示上的位置和 Blt buffer 裏相對應的轉化：Blt buffer array index = Y * Width + X 。Blt buffer 裏描述像素是有32位，字節0到字節2分彆代表了在像素中紅，緑，藍三色各含的成分，字節3是保留位，始終為0。

5，UGA I/O Protocol 支持I/O 請求模式，目的在于給 OS high performance driver 提供服務。這些I/O請求是經由 EFI_UGA_IO_PROTOCOL DispatchService() 成員函數來訪問的。I/O請求服務包含的能力由 EFI_UGA_DRAW_PROTOCOL 來支持。

6，EFI_UGA_DRAW_PROTOCOL 的三個成員函數：GetMode（）、SetMode（）、Blt（）；
EFI_UGA_IO_PROTOCOL 的成員函數：CreateDevice（）、DeleteDevice（）、DispatchService（）；

Simple Pointer
1，指定一個簡單的方法來進入指針設備。通常説來，主要是指鼠標。EFI_SIMPLE_POINTER_PROTOCOL 允許返回指針設備的有關信息。這包含了按鍵的狀態和最新訪問時鼠標的運動狀態。

2，每個EFI_SIMPLE_POINTER_PROTOCOL都必須安裝Handle 來給EFI Drivers和EFI App提供一些服務讓它們來利用。同時，EFI_DEVICE_PATH 也必須安裝同様的Handle。

相關的概念理解：
1，EBC：
對于不同的處理器和平台，Option ROMs要求有不同的可執行的映像。EFI定義了EFI 字節碼編譯器（EBC）虚擬機來處理這些不同。這個虚擬器的注釋器是firmware的一部分。C語言能够被編譯成EBC，然後和相關的驅動連接，在注釋器上運行。
C語言編譯成 EBC ，同時創建 EBC 映像，它可以被系統在 EFI1.10、UEFI2.0，或更後的Spec下執行。這些系統包含 EBC 注釋器，EBC 注釋器加載和解釋 EBC image，允許 image 能够在多種平台和機制上執行，包括那些基于英特爾? 安騰?處理器, 32位英特爾? 架構處理器,以及64位英特爾體系架構處理器。

2，OPROM：
(Option ROM) Firmware 在適配器卡上控制可啓動的外圍設備。系統 BIOS 會詢查 option ROMs，來確定有哪些設備可以被啓動導入。
(Option ROM) Firmware on adapter cards that control bootable peripherals. The system BIOS interrogates the option ROMs to determine which devices can be booted.

Option ROM 有固件組成，由系統 BIOS 來調用。舉例來説：適配器卡控制導入設備，設備可能包含固件，一旦 Option ROM 被加載，固件用來將設備連接到系統。
An Option ROM typically consists of firmware that is called by the system BIOS. For example, an adapter card that controls a boot device might contain firmware that is used to connect the device to the system once the Option ROM is loaded.

資料來源：
http://blog.sina.com.cn/s/blog_4b265789010008fy.html
EFI Image綜述
By 於 1 則留言:
標籤：

EFI Driver Template Code 

#include "Tiano.h"
#include "EfiDriverLib.h"
#include "DrvSampleSetup.h"
#include "DrvSample.h"

//
// Local function declarations
//
EFI_STATUS
DrvSampleEntry (
  IN EFI_HANDLE           ImageHandle,
  IN EFI_SYSTEM_TABLE     *SystemTable
  );

EFI_DRIVER_ENTRY_POINT (DrvSampleEntry)

EFI_STATUS
DrvSampleEntry (
  IN EFI_HANDLE           ImageHandle,
  IN EFI_SYSTEM_TABLE     *SystemTable
  )
/*++

Routine Description:

  DrvSample driver entry point function.

Arguments:

  ImageHandle   - image handle for this driver image
  SystemTable   - pointer to the EFI System Table

--*/
{
  EFI_STATUS  Status;
  EFI_HANDLE  Handle;

  Status = EFI_SUCCESS;
  Handle = NULL;
  EfiInitializeDriverLib (ImageHandle, SystemTable);
  //
  // TODO: Add implementation code
  //
  //
  // Initialize our setup/forms data
  //
  Status = SetupInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  //
  // Initialize and produce our driver binding protocol
  //
  Status = DriverBindingProtocolInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  //
  // Initialize and produce our driver diagnostics protocol
  //
  Status = DriverDiagnosticsProtocolInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  //
  // Initialize and produce our component name protocol
  //
  Status = ComponentNameProtocolInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  //
  // Initialize and produce our driver configuration protocol
  //
  Status = DriverConfigurationProtocolInit (ImageHandle, SystemTable, &Handle);
  if (EFI_ERROR(Status)) {
    //
    // TODO: Handle error
    //
  }
  return Status;
}


資料來源：
http://blog.sina.com.cn/s/blog_4b265789010006gu.html
EFI Programming on Mac OS X
By 於 沒有留言:
標籤：

2008年11月5日 星期三

EFI介紹之二——框架結搆（Framework）[轉貼]


這個就是Intel設計出來的一個完整的EFI BIOS示意圖，其中綠色的部分就是Framework，我現在從下至上一一介紹。

1）Hardware 這個沒有什麼好說的，就是指我們的平台，主板。

2）Framework，一個大的“H”型結搆，好像一個大的容器，兩端都能裝東西，裝入協議和接口，下端的協議用來訪問硬件，上端協議用來和操作系統進行交互，而兩端的協議進行通信的橋梁就是Framework所設計出的兩個基本模塊：DXE Foundation和PEI Foundation。之所以有兩個，是因為在BIOS過程中分兩個階段，他們各自包含了一個稱之為調度器（Dispatcher）的東西，來調度執行子模塊。這兩個Foundation里面到底有哪些東西，我會在後面的文章中繼續介紹。Framework還包含了Framework Driver，它實現了除Foundation之外的功能，比如訪問硬件的接口等等，注意，它僅僅包含接口而已，不包含接口的實現。

3）Platform Drivers，這個是和具體硬件平台相關的驅動，訪問硬件接口的實現，前一篇文章已經提到，EFI在設計的時候就考慮到跨平台，所以我們在這里看到了他把何平台有有關的東西做到了一個模塊里面，那樣在移植到其他平台的時候，只需要換掉這個部分就可以了。

注：在這里我們經常會看到"Driver"這個詞，我想說明一下，這個“Driver”和我們日常所聽到的驅動程序有點不一樣，可以翻譯成接口，我覺得更加恰當一些。

4）EFI Drivers，這個指一個符合EFI 驅動標准（EFI Driver Modle）的驅動程序，EFI的標准化甚至滲透到了驅動層面，為了兼容性，也制定了驅動標准，凡是符合此標准的程序，都可以在所有的EFI BIOS上直接運行，而不需要任何改動。這樣也給做外圍設備的廠商提供了方便，他們在編寫設備驅動程序的時候，只需要去了解驅動模型就好，而不要去研究整個EFI BIOS，也不用考慮不同的EFI BIOS會有不兼容這個問題。

5）Capatibility Support Module（CSM）為了兼容現有的匯編語言編寫的設備驅動程序和操作系統，而提供了這個部分，計算機領域都要考慮向前兼容的問題，直到BIOS的所有部分都符合EFI標准，這個模塊才會拿掉，不過現階段，這個東西還會存在很長一段時間，因為目前使用EFI BIOS的操作系統很少，Mac OS，Vista+SP1，Linux也正在准備，前景很好：），還有重要的一點，就是現階段的一些操作系統不可能很快就被淘汰，Dos到今天還在廣泛使用。

6）EFI，再往上一層黃色薄薄的一層，EFI本身所表示的就是接口，所以我們可以看到，在Framework這幅圖里面，它只占了很少的一部分，僅僅提供了OS和Framework之間的接口而已。絕大多數工作，都是在Framework中完成。

7）OS，最上面灰色的部分，這幅圖里面有兩種OS，一種是支持EFI的操作系統，另一種是傳統的（Windos XP/98，DOS等等），後者在啟動過程中還需要CSM支持，用Int 19H中斷，所以它放在了CSM的正上方，而支持EFI的操作系統，是不要CSM支持的，它的啟動方式是EFI標准所規定的，這個我們在後面繼續介紹。

資料來源:
http://blog.csdn.net/lpg123/archive/2008/08/30/2853502.aspx
By 於 3 則留言:
標籤：

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
By 於 1 則留言:
標籤：

2008年9月25日 星期四

[轉貼]EFI/UEFI BIOS 入門 : All For Beginners – 另附深入學習指南以及有用的URL連接

我們已經使用BIOS超過了二十年．可是直到今天還友許多朋友不知道BIOS到底是什麼，以及它主要做些什麼事情，它在整個個人計算機之中所處的地位如何．事實上，BIOS是整個計算機系統中最重要的底層系統軟體．二十多年來，中國的程序員們紛紛忽略了BIOS，或者由BIOS衍生出的開發技術，相反，我們對如何調整一兩個BIOS設置津津樂道．今天，BIOS業界開始悄悄的變革，EFI或者UEFI的到來即將改變世界，從而徹底改變我們對過去的計算機啟動過程的認識．但是我們中國的開發者們仍然在談論JAVA或者.NET，我想，是到了清晰的研究BIOS的時候了．

小生不才，但也願意就我所學，貢獻成一篇簡短的入門文章，帶領大家進入BIOS這個有趣而又充滿了神秘的地域，我們一起來探究BIOS，尤其是探究下一代個人計算機的基礎系統軟體，或者說基礎固件：UEFI bios的方方面面．由于類似的文章網上也比較多，所以我就重點談些別人一般忽略的部分吧．

BIOS Definitions

BIOS -- Basic Input and Output System，is used for initializing，testing and putting the PC into the ready state so that an OS may be started．Part of the BIOS remains in the system main memory after POST，or Power On Self Test．BIOS provides a consistent software interface to varying types of the hardware devices．It also provides the basic system level services to OS．The BIOS is also used for helping IHV to fix their hardware design bugs by using the SMM mode of the IA architecture.

上面這句話是我在初學BIOS的時候，我的老師，一位受到整個業界尊敬的杰出BIOS Engineer對我說的，這段話雖然短，但是卻清楚的道出了BIOS的基本功能，那就是：
  1. 檢測硬體，又叫POST．

  2. 初始化硬體，設置其基本狀態，使得整個計算機達到所謂的＂可用狀態＂（Ready State）．

  3. 啟動OS Loader加載操作系統．

  4. 在操作系統啟動起來以後，一部分繼續駐留內存(記憶體)，向操作系統以及其他軟體提供基本的系統級的服務．如磁碟讀寫等．

  5. 修復硬體缺陷．
下面我們一個一個的來看這些功能．

(第一個)檢測硬體可能比較好理解一點，就是看看你的硬體是否還正常的工作，但是從軟體的角度看．其中最重要的就是對內存的檢測的．大家都還對剛開機的時候內存的大小一直在跳的螢幕有記憶吧，那就是在做Memory Test，或者說Memory Sizing．

(第二個)功能是初始化硬體，可能有不少朋友問：為什麼我的硬體還需要初始化？問的好，硬體的設計廠家往往為了通用市場的考慮，不願意將硬體設計成定制的狀態，可能一個網卡，可以安裝在PC，同樣也可以安裝在嵌入式系統上．所以為了使得硬體能夠按照PC的架構工作，BIOS必須要按照由IHV（Independent Hardware Vendor）提供的手冊將硬體設置好，比如寫几個必須的寄存器之類的，做一些enable的工作．這點非常重要，如果一個硬體沒有enable，那麼在OS下將不可見．

(第三個)功能是啟動操作系統，這也是BIOS必須要做的事情之一．啟動的方式是由BIOS規定，操作系統必須按照BIOS的要求來設計．這也是為什麼操作系統從DOS一直到Vista，都只能把自己的loader放在MBR，因為BIOS只讀MBR．強大的微軟都必須要按照這個不成標准的標准來：）當然，在EFI時代，這一點有所改變，EFI支持的Boot From File不在需要MBR．

(第四個)功能可能之前作過DOS開發的朋友比較熟悉吧，還記得INT 10基本螢幕服務，INT 13磁槃服務嗎？多少病毒正是靠INT 13來傳播．又有朋友曾經試圖繞過INT 10來直接寫螢幕？Windows時代，這些東西事實上仍然存在，並且繼續發揮着基本的核心作用，只是他們被Windows包裝起來了，一般的程序無法接觸到，但這並不能說明他們就沒有用處了．MS的開發人員不久前還表示，事實上甚至就是開發中的Longhorn的安裝程序，目前仍然有許多code是基於INT 10來寫螢幕的．

(第五個)功能估計一般的朋友可能就不知道了，就是之前稍微接觸過BIOS的朋友們可能也是第一次聽說吧！Intel在它的CPU裏專門留了個模式叫System Management Mode，擁有最高的權限．SMM中斷的時候，就連號稱無所不能的Windows的也不知道，這樣就可以給CPU補bug了，舉個例子，比如某天Intel的一個CPU對ADD指令給出錯誤操作結果，那麼就可以利用SMM在每次執行這個指令的時候，中斷一下，由BIOS軟體給出正確的執行結果．這就達到了給硬體修復缺陷的目的．這樣Intel也不用招回它的CPU了，呵呵．此外，每次BIOS開機的時候，事實上都會更新CPU Microcode，同樣是用來給CPU補bug的．所以很多時候，刷BIOS刷出問題，事實上某個CPU的bug沒有補上導致出了問題出現．

BIOS在哪裏
上面囉嗦了一大堆的BIOS Basics，那麼BIOS到底在哪里呢？答案是在你的計算機裏：）　的確有些無聊，事實上BIOS有三種狀態，分別是：
  1. Before Build

  2. BIOS Image

  3. BIOS Runtime
(第一種)呢，這個時候BIOS表現為BIOS開發者硬碟上的一堆源始程式． 處於(第二種)的時候，BIOS則是沉睡在Flash里的一段image．BIOS真正發揮作用是在(第三種)模式下，哪個時候BIOS執行，控制系統，與操作系統交互．

EFI BIOS
EFI是由Intel提出的，目的在於為下一代的BIOS開發樹立全新的框架。EFI是英文Extensible Firmware Interfaces的縮寫。正如它的名字一樣，EFI不是一個具體的軟體，而是在操作系統與平台固件（platform firmware）之間的一套完整的接口(interface)規範。EFI定義了許多重要的數據結構以及系統服務，如果完全實現了這些數據結構與系統服務，也就相當於實現了一個真正的BIOS核心。

EFI最早是在Spring 2000 IDF（Intel Developer’s Forum）上提出的，當時Intel認為，隨着IBM在80年代初推出了第一台個人計算機開始，直到今天為止，個人計算機硬體平台已經發生了翻天覆地的變化，相關的系統軟體如操作系統等也從最早的MS DOS1.0到今天的Windows XP，而作為整個系統的最底層也最為關鍵的系統軟體之一的BIOS卻基本上保持了架構二十年不變。這在整個軟體史上都是一件不可思議的事情。如今，BIOS已經變成了嚴重阻礙IT產業前進的絆腳石，必須通過對BIOS的革新來為下一代的操作系統（如Windows Server Longhorn）提供更加強大的支持。

上面是我很早之前寫的一段對EFI的介紹，現在看來，難免有些錯誤，不過大致意思非常明確，EFI就是用來替換傳統BIOS．作為更好的BIOS，EFI可以提供過去無法在BIOS中作到的許多事情．后面的文章我會逐步展現給大家．

一些常見的關于BIOS/EFI的問題以及我的簡短回答:
1) BIOS一般有多大?
傳統bios(以後說legacy bios)一般都是512KB,而早期的EFI bios也是512KB.現在EFI基本上是1MB了.
2) BIOS用什麼工具開發?
legacy bios一般用MASM 6.11開發,同時還會配上一些廠商自己寫的build tools. EFI則使用Visual Studio.NET 2003以及MASM 6.11開發(沒想到吧~)
3) EFI boot是怎麼一回事?
EFI有自己獨特的boot方式,完全拋棄掉了傳統的0磁道0扇區的MBR概念.EFI的boot方式與文件系統息息相關.過去的legacy bios由於不帶文件系統,不得已選擇從硬碟上特定空間裝載程序的辦法,而EFI則附帶了完整的文件系統支持,所以不再對硬碟有特定的要求,EFI下的操作系統加載程序事實上存儲在boot\ia32\bootia32.efi文件里.(假定是IA32架搆).這是一個EFI應用程序.

下面是一些深入學習bios的資源匯總:
1. BIOS Boot Specification
業內一般叫BBS,詳細描述bios啟動時必須要做的所有事情,如何區分啟動設備,如何選擇啟動設備等等.
http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdf

2. UEFI Specification
UEFI規範,詳細描述了UEFI bios必須支持的接口.以及UEFI bios的模型,提供的服務等等. 開發UEFI必備的.
http://www.uefi.org

3. Ralf Brown's Interrupt List
這個人似乎就一輩子都都在收集中斷的東西,對legacy bios學習很有用.
http://www.ctyme.com/rbrown.htm

4. El Torito CD-ROM Boot 描述了bios如何從光碟上boot的細節.
http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496-A286D893E36A/0/specscdrom.pdf

5. USB Specification USB設備規範
http://www.usb.org

6. Plug-and-Play Specifications MS的PnP規範
http://www.microsoft.com/hwdev/tech/pnp/default.ASP

7. BIOS Writer's Guide
bios開發的聖經,由cpu廠商給出.Intel的絕對看不到,Intel的是絕密級的文檔.AMD的倒是可以看到,不同的cpu有不同的BWG.這里給出一個amd比較新的cpu的BWG:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.pdf

還有很多很多相關的文檔.其實編寫bios最難的在於同時支援業界幾乎所有的通用規範.

歡迎大家回帖提出相關問題. 我會在空閑時間一一作答.

轉載自：
http://www.huarw.com/program/assembler/assembler01/200804/1561026.html
By 於 3 則留言:
標籤：

2008年9月3日 星期三

符合SMBIOS規範的電腦系統訊息獲取方法

符合SMBIOS規範的電腦系統訊息獲取方法
作者：ramble(如需轉載請注明作者)
SMBIOS (System Management BIOS, SMBIOS)，它是一種定出主機板及系統廠商如何以標準的格式顯示產品管理資訊的規格。
SMBIOS 及 DMI(Desktop Management Interface)規格兩者皆是由 Desktop Management Task Force (DMTF) 所草擬的，它是一個由業界所領導，實行技術規格以確認開放性標準的組織。
對於符合SMBIOS規範的電腦，可以通過訪問SMBIOS的結構獲得系統訊息，共有兩種辦法可以訪問：

1．通過即插即用功能接口訪問SMBIOS結構，這個在SMBIOS2.0標准裏定義了，從SMBIOS2.1開始這個訪問方法不再被推薦使用。
2．基於表結構的方法，表内容是tableentry point的數據，這個訪問方法從SMBIOS2.1以後開始被使用，從2.1開始，以後的版本都推薦使用這種訪問方式。在2.1版本中允許支援這兩種方法中的任意一種和兩種都支援，但在2.2已經以後的版本，必須支援方法2。

鑒於市場上計算機已經均支援SMBIOS2.3標准，所以只考慮方法2，基於表結構的訪問方式。
基於表結構訪問SMBIOS的過程是先找到EntryPoint Structure（EPS）表，然後通過EntryPoint Structure（EPS）表的數據找到SMBIOS數據表。
訪問SMBIOSEPS表的操作過程如下：
1．從物理内存0xF0000-0xFFFFF間尋找關鍵字“_SM_”
2．找到後再向後16個字節，看後面5個BYTE是否是關鍵字“_DMI_”，如果是，EPS表即找到。
注：按照SMBIOS規範説明，找到關鍵字”_SM_”後就可以確定此處就是EPS表結構，但我在實際操作中發現有為數不少的電腦的指定64K内存中有不只一個“_SM_”，所以不能只用找到”_SM_”來確定，需要繼續判斷16個字節後是否是“_DMI_”。
SMBIOSEPS表結構如下：
位置名稱長度描述
00H關鍵字4 byte固定是“_SM_”
04HCheck Sum1 byte用於檢查數據
05H表結構長度1 byteEntry Point Structure表的長度
06HMajor版本號碼1 byte用於判斷SMBIOS版本
07HMinor版本號碼1 byte用於判斷SMBIOS版本
08H表結構大小2 byte用於即插即用接口方法獲得數據表結構長度
0AHEPS修正1 byte
0B-0FH格式區域5 byte存放解釋EPS修正的訊息
10H關鍵字5 byte固定為“_DMI_”
15HCheck Sum1 byteIntermediate Entry Point Structure(IEPS)的Check Sum
16H數據表長度2 byteSMBIOS數據表長度
18H數據表位址4 byteSMBIOS數據表的真實內存位置
1CH數據表結構數目2 byteSMBIOS數據表的結構數目
1EHSMBIOS BCD修正1 byte
通過EPS表結構中的12H以及14H處，得出數據表長度和數據表地址，即可通過地址訪問結構表。從EPS表中的1CH處可得知結構表結構的總數，其中TYPE0結構就是BIOSinformation，TYPE1結構就是SYSTEMInformation。
每個結構的頭部是相同的，格式如下：
位置名稱長度描述
00HType number1 byte結構的type number
01H長度1 byte本結的長度，就此type number的結構而言
02HHandle2 byte用於獲得SMBIOS結構，使用方法未知
每個結構都分為格式區域和字符串區域，格式區域就是一些本結構的信息，字符串區域是緊隨在格式區域後的一個區域。結構01H處標識的結構長度僅是格式區域的長度，字符串區域的長度是不固定的。
下面以TYPE0（BIOSinformation）為例説明格式區域和字符串區域的關系

TYPE0（BIOSinformation）格式區域如下：

位置名稱長度描述
00HType number1 byte結構的type number，此處是0
01H長度1 byteType 0格式區域的長度，一般為14H，也有13H
02HHandle2 byte一般為0000H
04HBIOS廠商訊息1 byte此處是BIOS賣方的訊息，可能是OEM廠商名，一般為01H，代表緊隨格式區域後的字串區域的第一個字串
05HBIOS版本1 byteBIOS版本號，一般為02H，代表字串區域的第二個字串
06HBIOS開始位址段2 byte用於計算常駐BIOS鏡像大小的計算，方法為(10000H-BIOS開始位址段)*16
08HBIOS發佈日期1 byte一般為04H，表示字串區第三個字串
09HBIOS ROM Size1 byte計算方法為(n+1)*64K，n為此處讀出的數值
0AHBIOS特徵8 byteBIOS的功能支援特徵，如PCI,PCMCIA,FLASH等等
12HBIOS特徵擴展不定
緊隨TYPE0（BIOSinformation）結構區域之後的就是TYPE0（BIOSinformation）字符串區域，如下所示：
db‘System BIOS Vendor Name’,0 ; 字符串以零結尾，第一個字符串：賣方訊息
db‘4.04’,0 ; 第二個：BIOS版本
db‘00/00/0000’,0 ; 第三個：發布日期
db0 ; 以0為整個字符區域的結尾，所以要找下一個TYPE,只要在字符區域找到連續的0000H即可
注：當有EPS表中得到結構表的開始地址後，可以直接按結構來尋找相應的TYPE號，找到後直接讀取就是該TYPE對應的結構的格式區域訊息，然後向後移動結構區域長度（結構區域長度由該結構的01H處讀出）個BYTE，即是該TYPE機構的字符串區域。


由上面介紹可知，獲得BIOS訊息的辦法就是：

1．通過EPS表的12H和14H數據找到TYPE結構表，然後找到TYPE0的内存地址。(不一定是首個)
2．由TYPE0結構區域中得出相應BIOS訊息是否存在（存在則是上面所述的 01H,02H,03H依次排布，不存在則是相應的位置上為00H）。
3．如存在訊息，則從字符串區域中讀取對應BIOS訊息。
獲得SYSTEM信息方法同上，只是TYPE結構區域有所不同，請參照SMBIOSReference Specification

在Linux環境裏可以使用dmidecode這支程式去dump SMBIOS的資料
dmidecode主要功能:
桌面管理介面提供標準化的電腦硬體描述，包括硬體的特性，比如 BIOS 的序號、與硬體連接線。dmidecode 提供由 BIOS 輸出 DMI 的資料，通常被其他硬體偵測程式當作後端工具使用。

By 於 沒有留言:
標籤：
訂閱： 文章 (Atom)
  • Chrome Browser White Screen 白屏問題
    昨天差點昏倒, 因為Chrome Browser一開啟後居然一片白畫面. 雖然還有IE可以用, 但就是習慣Chrome了啊, 然後開始Google別人如何解決, 不過看起來不少人遇到相同的問題, 但都沒什麼解決方法. 什麼掃毒啦, 重新安裝Chrome啦, 砍掉Default啦....
  • I/O對應的方式
    I/O mapped I/O(port-mapped I/O或Direct I/O) I/O與memory均擁有自己的記憶體空間 需要特別的指令來處理I/O 好處是完全不用考慮記憶體空間被I/O佔用，缺點需要額外的指令專門處理I/O存取。 Memory Mapped I/O I/...
  • UDP Server/Client 範例程式
    好像不少人會找這個Sample Code, 小修改一下好了. 先前的Code有不少的Warning出現而且會Crash耶! 底下分別列出UDP Server及Client的範例程式. UDP Server (udp-server.c) 利用 socket 介面設計網路應用程...

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

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