EFI & UEFI

**

EFI & UEFI

**
1.定义

• PC BIOS有一个限制(支援16 bit 的处理器模式，1MB 位址空间与AT
  硬件架构)，而这个限制使的他无法支援大型服务器平台的系统

EFI(Extensible Firmware Interface)：可延伸韧体界面，他规范了一个
面，界于OS与 (Platform firmware)之间的一个桥梁。 EFI的改进被用
取代传统BIOS的界面(这个传统的界面被称之为IBM PC compatible
PC 的BIOS或称之为Legacy BIOS). Intel在2005年将其交由统一可延
韧体界面论坛（Unified EFI Forum）来推广与发展，为了凸显这点，
EFI也更名为UEFI

UEFI (Unified Extensible Firmware Interface)：统一可延伸韧体界面，用来定义作业系统与系统韧体之间的软件界面，作为BIOS的替代方案。
可延伸韧体界面负责加电自检（POST）、联系作业系统以及提供连接作业系统与硬件的界面。

2.开机流程

(1)SEC (Security)
此阶段其主要的特色为「cache as RAM」，即处理器的快取当成存储器。由于C语言需要使用堆栈，在这个阶段的系统存储器尚未被初始化，在没有存储器可用的情况下，便把处理器的快取当成存储器来使用，在主存储器被初始化之前来进行预先验证CPU／芯片组及主机板。因为这时候没有快取，会导致处理器的效能变得较差，所以在存储器初始化完毕之前，SEC和PEI阶段的程序码越简短，越能减少这个副作用。
(2)PEI (Pre-EFI Initialization Environment)
以唤醒CPU及存储器初始化。这时候只起始了一小部分的存储器。同时，芯片组和主机板也开始初始化。接下来的服务程序会确定 CPU芯片组被正确的初始化，在此时，EFI驱动程序dispatcher将载入EFI驱动程序存储器，进入了起始所有存储器的DXE阶段（驱动程序执行环境）。
(3)DXE (Driver Execution Environment)
主要功能在于沟通EFI驱动程序及硬件。也就是说此阶段所有的存储器、CPU（在此是指实体两个或以上的非核心数目，也就是双CPU插槽处理器甚至是四CPU插槽处理器）、PCI、USB、SATA和Shell都会被初始化。
(4)BDS (Boot Device Select)
使用者就可以自开机管理者程序页面，选择要从哪个侦测到的开机设备来启动。
(5)TSL (Transient System Load)
由作业系统接手开机。除此之外，也可以在BDS阶段选择UEFI Shell，让系统进入简单的命令列，进行基本诊断和维护。

(6)RT Phase (Run Time)
当OS Call Boot Service ExitBootService()后，系统会进入RT Phase。这时，DXE Foundation 以及Boot Service都会终止，只有EFI Runtime Service 以及 EFI System Table还能被使用。

◎启用EFI Shell主控台- EFI Shell环境常用指令
cd 显示或更改目前的目录
cls 清除荧幕画面
comp 比较两份档案的内容
date 显示目前的日期或设定系统的日期
dmem 显示存储器的内容
edit 全荧幕编辑ASCII或Unicode档案
exit 离开EFI Shell
help 显示指令清单或一个指令的意义
ls 显示档案清单及在目录中的子目录
map 显示或定义对映（储存）装置
memmap 显示存储器分布对映
pci 显示PCI装置设备
reset 系统重置
time 显示目前时间或设定系统时间
type 显示档案的内容
ver 显示版本信息

3.UEFI基本架构
(1)System Table

含有很多重要的资料结构以及系统function的interface。
它是一个DXE时建立的Table，包含
a.Boot Services：在未进入OS前 (还没call ExitBootSerivce)前可使
用的，之后就不能用了
b. Runtime Services：在进入OS后还可以使用的。
c . Protocols Services：是给Driver使用的，可以注册Handle，
Routine等等。
这些东西都可以从 System Table 找到相关 reference 。

(2)Handle Database and protocols

很多资源及概念的reference，是被注册在此处。
当Dxe Driver利用Protocol Service注册想开放的功能，它是以 Handle的方式来储存。此Database是储存的媒介。取得也是利用 Protocols Service来查询。因为是查询，使用方必须知道相关的data structure 才能正确的使用开放的Handle。

而内部主键则是利用 GUID来分别各Handle (GUID很难重覆)，Handle是由一个或多个Protocol组成的(因为Protocol是挂在Handle上的)，Protocol本身则以GUID为身份代表，开放一些Interface 。
在执行完ExitBootServices之后，Handle Database就不存在了。

Handle本身，还是有分类的。所有存在ROM里面的Image file，在载入后，都会变成一个Image Handle，而Driver被dispatch后，则是看它本身的内容看要不要再产生新的Handle。
目前已知的是：
a. Driver Handle (符合EFI Driver Model )
b. Service Routine (这个产生出的Handle没意义，重要的是它要分享
Service )

>>Protocol详述 (UEFI Spec Ch7)

简单讲Protocol就是一个“Interface”，并且也用来泛指其Interface 的Instance/GUID，Interface是一组Data与Function pointer的集合， 在C/C++用structure/class模拟之。

要取用该Interface的Driver or Application 必须知道该 Protocol/GUID然后用LocateProtocol/HandleProtocol/OpenProtocol。
值的注意的是在Install传进的Interface/Protocol本身要是Global 的，不然取用该Protocol时，会发生install时的interface(Local variable)早就被Destory而出错。

typedef
EFI_STATUS
InstallProtocolInterface (
IN OUT EFI_HANDLE *Handle,
IN EFI_GUID *Protocol,
IN EFI_INTERFACE_TYPE InterfaceType,
IN VOID *Interface
);
Handle：通常直接关连建立该Protocol的Driver本身的 handle，传NULL则系统会新建一个Handle传回来使用，无效的Handle则会得到EFI_INVALID_PARAMETER传回，当然也表示安装失败
Protocol：安装的Interface的GUID
InterfaceType：目前只定义了 EFI_NATIVE_INTERFACE
Interface：将要安装的interface pointer

typedef
EFI_STATUS
LocateProtocol (
IN EFI_GUID *Protocol,
IN VOID *Registration OPTIONAL,
OUT VOID **Interface
);
Protocol ：预取得Interface的GUID
Registration：…
Interface：取得的interface的指标

当确定只有一个Handle会拥有特定的Protocol时可以简单用LocateProtocol，去Get Interface，而当有多个Handle提供相同Protocol可以用OpenProtocol去得到该Handle的Protocol(像USB可能会有多个USB Host controller，所以会用OpenProtocol)，用LocateHandleBuffer可以得到所有提供该Protocol的Handles。

UEFI spec内建议用InstallMultipleProtocol去取代InstallProtocolInterface， 因为会检查更多有可能会发生错误的参数

Protocol Interface Function统整

安装数个Protocol与搭配的GUID至指定的Handle底下
InstallMultipleProtocolInterfaces (
　IN OUT EFI_HANDLE *Handle,
　…
);
移除数个Handle底下的Protocol与所搭配的GUID
UninstallMultipleProtocolInterfaces (
IN EFI_HANDLE Handle,
　 …
);
可将全部或以特定的条件将Handle取出
LocateHandleBuffer (
IN EFI_LOCATE_SEARCH_TYPE SearchType,
　 IN EFI_GUID *Protocol OPTIONAL,
　 IN VOID *SearchKey OPTIONAL,
　 IN OUT UINTN *NoHandles,
　 OUT EFI_HANDLE **Buffer
);
取得指定的Handle下所有的Protocol GUID阵列，并传出数量
ProtocolsPerHandle (
　 IN EFI_HANDLE Handle,
　 OUT EFI_GUID ***ProtocolBuffer,
　 OUT UINTN *ProtocolBufferCount
);
取得Handle底下指定的GUID的Information Entry阵列，并回传数量。
OpenProtocolInformation (
　 IN EFI_HANDLE Handle,
　 IN EFI_GUID *Protocol,
OUT EFI_OPEN_PROTOCOL_INFORMATION_ENTRY **EntryBuffer,
　 OUT UINTN *EntryCount
);

以指定的GUID取出第一个Protocol。
LocateProtocol (
　 IN EFI_GUID *Protocol,
　 IN VOID *Registration OPTIONAL,
　 OUT VOID **Interface
);
取出Handle中指定的Protocol，以GUID为识别。
HandleProtocol (
　 IN EFI_HANDLE Handle,
　 IN EFI_GUID *Protocol,
　 OUT VOID **Interface
);
类似HandleProtocol()，但提供了更安全的做法，绑订指定的Handle，避免使用中的Protocol被Uninstall。
OpenProtocol (
　 IN EFI_HANDLE Handle,
　 IN EFI_GUID *Protocol,
　 OUT VOID **Interface OPTIONAL,
　 IN EFI_HANDLE AgentHandle,
　 IN EFI_HANDLE ControllerHandle,
　 IN UINT32 Attributes
);

为以OpenProtocol()开启的Protocol解除占用。
CloseProtocol (
　 IN EFI_HANDLE Handle,
　 IN EFI_GUID *Protocol,
　 IN EFI_HANDLE AgentHandle,
　 IN EFI_HANDLE ControllerHandle
);

(3)EFI Image

在driver还没dispatch前，都是属于image的存在。是一种PE/COFF
的格式，存在ROM中。含有PE/COFF Format的Header。
目前有以下类型的 EFI Image：
a. EFI Application：resource在退出app时release
b. EFI Boot Service Driver：resource在ExitBootServices后release
c. EFI Runtime Driver：resource会一直存在
这也代表，使用这些格式的Image就可以被EFI所使用，而不依赖
处理器。(多了一层在处理这东西)
[ PE/COFF (可移植性可执行文件) ]
是一种用于可执行文件、目标文件和动态连结库的文件格式，主要
使用在32位和64位的Windows作业系统上。「可移植的」是指该
文件格式的通用性，可用于许多种不同的作业系统和体系结构中。
在Windows开发环境中，PE格式也称为PE/COFF格式。

• Handle是EFI Framwork自行建立的Reference，是动态建立的。
  而Image则是本身就存在ROM或是其它Storage中。可以透过
  LoadImage读出来，透过Dispatch执行该Image。

(4)Event

在UEFI开机过程中，我们会有这样的需求，某个特定的条件满足的时候，去执行某一段程序，在legacy BIOS中，是用中断去做的，而在UEFI里面，则是用EVENT 去实现的。
在EFI中，含有许多Events可供使用。Event是EFI所管理的。使用者
可以使用它来组合自己想做的事。

以下是Event的分类：
a. Wait Event
b. Signal Event
c. ExitBootServices Event
d. Timer Event
e. Periodic Timer Event
f. one-shot timer Event
◎ 一个UEFI Image可以对Event做以下的事情：
建立一个Event //CreateEvent()
销毁一个Event //CloseEvent()
查看一个Event是否处在Signaled状态 //CheckEvent()
等待一个Event进入Signaled状态 //WaitForEvent()
让Event从Waiting进入Signaled状态 //SignalEvent()