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厂商存取inel Chipset有问题而B厂商不会，因为最底层都是Intel

自己负责。

而建构在Framework上的一些功能就是各家BIOS Vendor 自己去负责，感觉就像我之前说的，Intel留下一些地方给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,

这样子他们能够开发的市场就会越来越大。

先解释几个名词：

UEFI System Table  系统中最主要的结构体，一般包括这么几个指针，指向active console device的，

指向boot  Services 表的，指向Runtime service 表的，还有各种系统配置表的，比如ACPI, SMBIOS, SAL system table.

////// EFI System Table///typedef struct {  ///  /// The table header for the EFI System Table.  ///  EFI_TABLE_HEADER                  Hdr;  ///  /// A pointer to a null terminated string that identifies the vendor  /// that produces the system firmware for the platform.  ///  CHAR16                            *FirmwareVendor;  ///  /// A firmware vendor specific value that identifies the revision  /// of the system firmware for the platform.  ///  UINT32                            FirmwareRevision;  ///  /// The handle for the active console input device. This handle must support  /// EFI_SIMPLE_TEXT_INPUT_PROTOCOL and EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.  ///  EFI_HANDLE                        ConsoleInHandle;  ///  /// A pointer to the EFI_SIMPLE_TEXT_INPUT_PROTOCOL interface that is  /// associated with ConsoleInHandle.  ///  EFI_SIMPLE_TEXT_INPUT_PROTOCOL    *ConIn;  ///  /// The handle for the active console output device.  ///  EFI_HANDLE                        ConsoleOutHandle;  ///  /// A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL interface  /// that is associated with ConsoleOutHandle.  ///  EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL   *ConOut;  ///  /// The handle for the active standard error console device.  /// This handle must support the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.  ///  EFI_HANDLE                        StandardErrorHandle;  ///  /// A pointer to the EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL interface  /// that is associated with StandardErrorHandle.  ///  EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL   *StdErr;  ///  /// A pointer to the EFI Runtime Services Table.  ///  EFI_RUNTIME_SERVICES              *RuntimeServices;  ///  /// A pointer to the EFI Boot Services Table.  ///  EFI_BOOT_SERVICES                 *BootServices;  ///  /// The number of system configuration tables in the buffer ConfigurationTable.  ///  UINTN                             NumberOfTableEntries;  ///  /// A pointer to the system configuration tables.  /// The number of entries in the table is NumberOfTableEntries.  ///  EFI_CONFIGURATION_TABLE           *ConfigurationTable;} EFI_SYSTEM_TABLE;

Handle database and protocols 在UEFI 里面，把对device 的访问抽象成handles 和 protocol. handle 由一个

或多个protocol 组成。

protocol 就长这个样子

struct _EFI_PCI_IO_PROTOCOL {  EFI_PCI_IO_PROTOCOL_POLL_IO_MEM         PollMem;  EFI_PCI_IO_PROTOCOL_POLL_IO_MEM         PollIo;  EFI_PCI_IO_PROTOCOL_ACCESS              Mem;  EFI_PCI_IO_PROTOCOL_ACCESS              Io;  EFI_PCI_IO_PROTOCOL_CONFIG_ACCESS       Pci;  EFI_PCI_IO_PROTOCOL_COPY_MEM            CopyMem;  EFI_PCI_IO_PROTOCOL_MAP                 Map;  EFI_PCI_IO_PROTOCOL_UNMAP               Unmap;  EFI_PCI_IO_PROTOCOL_ALLOCATE_BUFFER     AllocateBuffer;  EFI_PCI_IO_PROTOCOL_FREE_BUFFER         FreeBuffer;  EFI_PCI_IO_PROTOCOL_FLUSH               Flush;  EFI_PCI_IO_PROTOCOL_GET_LOCATION        GetLocation;  EFI_PCI_IO_PROTOCOL_ATTRIBUTES          Attributes;  EFI_PCI_IO_PROTOCOL_GET_BAR_ATTRIBUTES  GetBarAttributes;  EFI_PCI_IO_PROTOCOL_SET_BAR_ATTRIBUTES  SetBarAttributes;    ///  /// The size, in bytes, of the ROM image.  ///  UINT64                                  RomSize;  ///  /// A pointer to the in memory copy of the ROM image. The PCI Bus Driver is responsible   /// for allocating memory for the ROM image, and copying the contents of the ROM to memory.   /// The contents of this buffer are either from the PCI option ROM that can be accessed   /// through the ROM BAR of the PCI controller, or it is from a platform-specific location.   /// The Attributes() function can be used to determine from which of these two sources   /// the RomImage buffer was initialized.  ///   VOID                                    *RomImage;};