UEFI Boot Flow

有图有真相：

1. SEC Phase （Security）

开机之后，系统开始执行第一条指令，此时就已经进入了SEC阶段。这时的Memory还没有被初始化，还不可用，所以这一阶段最主要的工作就是建立一些临时的Memory，它可以是处理器的Cache，或是system Static RAM(SRAM)。并且使CPU进入Protect Mode。   另外，SEC Phase可以先天知道（Prior Knowledge）这些早期的内存被映射到得位置以及BFV（Boot Firmware Volume）的位置。

2. PEI Phase（Pre-EFI Initialization Environment）

PEI阶段最主要的工作就是Memory的初始化以及一些必要的CPU、Chipset等等的初始化。由于这些都是没有压缩的Code，所以要求越精简越好。另外，PEI Phase还要确定系统的Boot Path，初始化和描述最小数量的包含DXE foundation和DXE Architecture Protocols的System RAM及firmware volume。

3. DXE Phase（Driver Execution Environment）

DXE阶段是实现EFI的最重要的阶段，大部分的工作都是在这个阶段实现的。

4. BDS Phase（Boot Device Select）

BDS阶段的主要工作是：

a. 初始化基于环境变量ConIn、ConOut、StrErr的控制台设备。

b. 尝试去加载列在环境变量Driver####和DriverOrder上的Driver。

c. 尝试从列在环境变量Boot####和BootOrder上的启动设备列表中启动。

5. TSL （Transient System Load）

指Shell

6. RT Phase（RunTime）

当OS呼叫了Boot Service ExitBootService()之后，系统就进入了RT阶段。此时，DXE Foundation和Boot Service都已经终止了，只有EFI Runtime Service和EFI System Table还可以继续被使用。

7. AL（After Life）

当OS呼叫了EFI Runtime Service ResetSystem()或者是呼叫了ACPI Sleep State，系统就进入了AL阶段。 异步Event（比如SMI、NMI）的触发也可使系统进入AL阶段，这在Server和Workstation上比较常见。

 

为什么要有SEC Phase?

1. 需要用汇编语言来完成C无法处理的工作，如C语言无法处理CPU的特殊寄存器（MSR，MTRR，CRX）。

2. C语言需要Memory当成Stack来处理Local 变数，而刚开机Memory还没有被初始化，还不可用，所以需要CAR（Cache As Ram）的初始化。

3. 让CPU进入Protected Mode(Flat Mode)。

SEC Phase的任务

SEC Phase是整个UEFI Boot过程中的第一个阶段，它主要完成的任务有：

1.  系统上电/重启的入口，处理所有的平台restart events，包括开机，重启，或是各种异常条件下的启动。

2. 创建一块临时的内存区域，在系统内存初始化之前使用，比如用CAR（Cache As Ram）或SRAM。

3. 在安全方面，是信任链的根（the root of trust）。之后模块的任何安全相关的设计都必须有个根，而因为系统开机之后最初的代码实现是在SEC阶段，所以平台设计者在调用PEI Foundation之前可以在SEC阶段验证PEI Foundation的安全性。所以说SEC阶段是系统信任链的根。

4. 传送Handoff信息到PEI Foundation（这才是SEC Phase的最终目的），这些信息包括：

1>.平台的状态，

2>.BFV(Boot Firmware Volume)的位置和大小，

3>.临时RAM的位置和大小，

4>. 栈的位置和大小。

数据结构为：EFI_PEI_STARTUP_DESCRIPTOR。

typedef struct {
  UINTN                   BootFirmwareVolume;
  UINTN                   SizeOfCacheAsRam;
  EFI_PEI_PPI_DESCRIPTOR  *DispatchTable;
} EFI_PEI_STARTUP_DESCRIPTOR;

另外，还有一个PPI：EFI_SEC_PLATFORM_INFORMATION_PPI 可以用来传送Handoff信息。在SEC_PLATFORM_INFORMATION_PPI.PlatformInformation()中定义了一个EFI_HEALTH_FLAGS，它包含了Processor，hardware，and/or安腾处理器中PLA（Processor Abstract Layer）代码中关于处理器Reset上的状态信息。

SEC阶段代码流程图：

PEI Core Entry Point 是如何确定的？

是由Build Tool来确定的。在Build出来的bin file位置0xFFFFFFE0存放。

BFV Base Address是如何确定的？

是由Build Tool来确定的。在Build出来的bin file位置0xFFFFFFFC存放。

 

 

 

Refer to:

Pre-EFI Initialization Core Interface Version 1.2

PEI：Pre-EFI Initialization

为什么要有PEI Phase？

1. ROM空间的问题，所有的Code都没有压缩

2. Memory还没有初始化

3. Chipset没有初始化

PEI Phase的特性：

1. 在ROM上执行

2. 都是没有被压缩的代码

3. PEI Core与硬体没有关联

PEI Phase的任务：

1. 基本的Chipset初始化

2. Memory Sizing

3. BIOS Recovery

4. S3 Resume

5. 切换Stack到Memory （Disable CAR， Enable Cache）

6. 启动DXEIPL（DXE Initial Program Loader）

PEI Phase包含的两个部分：

1. 一个PEI Foundation，存在于BFV。

2. 一个或多个PEIMs（Pre-EFI Initialize Module），存在于FVs。

一、关于PEI Foundation

PEI Foundation存在于FV0(即BFV)，它是在SEC阶段被发现并通过验证的，这也就允许PEI阶段能够确定FV文件有没有被破坏掉。

PEI Foundation负责：

1. Dispatching PEIM

2. Maintaining the boot mode

3. Initialize permanent memory

4. Invoking DXEIPL

PEI Services

PEI Foundation建立了一个system table叫做PEI Services Table，它对所有的PEIM都可见。PEI Services的分类有：

二、关于PEIM（Pre-EFI Initialization Modules）

PEIM就是一些可执行的二进制代码，它封装着一些关于Processor，chipset，device或者是平台相关的一些功能。由PEI Foundation负责来Dispatch这些PEIMs。

大部分的PEIM都存在于ROM上，它们是没有被压缩的，只有极少数的PEIM为了提高性能而存在于RAM上，是被压缩的。

因为PEI Phase存在的环境只有极少的Hardware Resource可用，且PEIM大都位于ROM上，所以强烈建议PEIM只做尽可能少的，不得不做的工作来满足DXE阶段执行的要求。

PPI（PEIM to PEIM Interface）

PEIM与PEIM沟通是通过PPI，即PEIM to PEIM Interface。PPIs包含在数据结构EFI_PEI_PPI_DESCRIPTOR中，由一个GUID和一个指针组成。

一个PEIM通过PEI Service InstallPPI()和ReinstallPPI()来发布一个有效的PPI到PPI Database；

其他的PEIM通过PEI Service LocatePPI()来找到相关的PPI。

PEI Phase 代码流程图

DXE: Driver Execution Environment

为什么要有DXE Phase？

大部分系统的初始化工作都是在DXE 阶段实现的。

DXE Phase由以下几部分组成：

1. DXE Core (DXE Foundation)

     产生一组Boot Services, Runtime Services, DXE Services。 由boot service code组成，boot到OS之后就不存在了。

2. DXE Dispatcher

    负责发现并以正确的顺序执行DXE Drivers。

3. DXE Drivers

    负责初始化CPU，Chipset，系统组件以及为Sysem Services、控制台和启动设备提供系统概要。

这几部分协同工作以完成platform的初始化，并提供启动到操作系统所要求的services.

DXE Phase与PEI Phase的关系:

可以执行DXE Phase的唯一的条件是：有一个有效的HOB List。 有很多种方式产生HOB List， PEI只是其中一种。所以DXE Phase之前并不要求一定先执行PEI Phase。

DXE Phase与BDS Phase的关系：

DXE Phase与BDS Phase协同工作以建立工作台并尝试boot OS。当OS成功启动，即BDS Phase开始的时候，DXE Phase就结束了。

DXE Driver 的分类：

1. Early DXE Driver--Platform initialization Drivers

       a. 在DXE Phase最早执行的Driver

       b. 包含Dependency Expression Syntax(DEPEX) 来描述Dispatch的顺序。

       c. 典型的包含：

              Basic Services

              Processor Initialization Code

              Chipset Initialization Code

              Platform Initialization Code

       d. 产生Architectural Protocols

2. EFI Drivers that follow EFI Driver Model

        a. 初始化的过程中不会涉及到硬件

        b. Follow EFI Driver Model

        c. 典型的提供对Console Devices 和 Boot Devices的访问

        d. Abstract Bus Controller

        e. 只有Boot OS 所需要的Driver才被初始化

        f. DXE Dispather完成的时候才被呼叫

        g. 像个Driver一样被执行

        h. 需要建立控制台（Keyboard，Video）和处理EFI Boot Option（Boots OS）的时候要连接EFI Drivers

BDS: Boot Device Select

 BDS阶段的任务：

1. Initialize console devices base on the ConIn, ConOut and StdErr environment variables.

2. Attempt to load all drivers listed in the Driver#### and DriverOrder environment variables.

3. Attempt to boot from the boot selections list  in the Boot#### and BootOrder environment variables.

如果BDS 阶段不能contact a console device, load a driver, or boot a boot selection, 这就要求重新调用DXE Dispatcher。 这种调用是必须的，因为通过执行这个操作可能会发现additional firmware volumes, 它们可能包含管理Console Devices和Driver Devices所必须的DXE Driver。

一旦新发现的Firmware Volume上的DXE Drivers被Dispatched之后，控制权会再次交到BDS手中 。

Console Device：

Console Device是从Simple Text Output和Simple Input Protocol中抽象出来的。 在UEFI中，能够产生这其中一种或两种Protocl的Devide都被当作是Console Device。

Console Device的几种Type：

1. VGA Adapters, produce Simple Text Output Protocol.

2. Video Adapters, produce Simple Text Output Protocol.

3.Serial Terminal, produce both Simple Text Output Protocol and Simple Input Protocol.

4.Telnet, produce both Simple Text Output Protocol and Simple Input Protocol.

5. Remote Graphical Displays(HTTP), produce both Simple Text Output Protocol and Simple Input Protocol.

Boot Device的几种Type:

1.Devices that produce the Block I/O Protocol and are formatted with a FAT file system,  Disk Devices
2.Devices that directly produce the File System Protocol
3.Devices that directly produce the Load File Protocol                                                              Network Devices