UEFI Spec 学习笔记---3 - Boot Manager(2)

3.1.4 Boot Manager Capabilities

boot manager 通过 BootOptionSupport 这个variable来控制支持从什么类型的 bootoption 来进行 boot，在 BDS 阶段或者其他需要设置启动项的时候，可以先获取到这个 variable 然后和对应的 bit 位来确认是否支持所需要类型的 boot option。

#define EFI_BOOT_OPTION_SUPPORT_KEY 0x00000001
#define EFI_BOOT_OPTION_SUPPORT_APP 0x00000002
#define EFI_BOOT_OPTION_SUPPORT_SYSPREP 0x00000010
#define EFI_BOOT_OPTION_SUPPORT_COUNT 0x00000300

EFI_BOOT_OPTION_SUPPORT_KEY 对应的就是 可以通过按键来创建 key option 然后进行 boot；

EFI_BOOT_OPTION_SUPPORT_APP 对应的就是 bootx64.efi 类似的可执行引导文件

EFI_BOOT_OPTION_SUPPORT_SYSPREP 对应的就是可以从SysPrep#### boot option 中去 boot.

EFI_BOOT_OPTION_SUPPORT_COUNT 对应的就是支持 boot 的 KeyXXXX 启动项数量。只有EFI_BOOT_OPTION_SUPPORT_KEY 被置起才有效。

3.1.5 Launching Boot#### Applications

Boot manager可以为应用程序支持一个单独的boot ####加载选项。Boot manager通过在BootOptionSupport全局变量中设置 EFI_BOOT_OPTION_SUPPORT_APP来表示它支持这个单独的类别

当应用程序的Boot####选项被添加到BootOrder时，安装程序应该清除 LOAD_OPTION_ACTIVE，这样引导管理器就不会尝试自动“引导” 应用程序。如果 Boot manager表明它支持单独的应用程序类别，如上文所述，安装程序应该设置BootOptionSupport 为 LOAD_OPTION_CATEGORY_APP。如果没有，它应该设置 LOAD_OPTION_CATEGORY_BOOT.

3.1.6 Launching Boot#### Load Options Using Hot Keys

Boot manager 支持通过一个 Hot Key 来加载相关联的 Boot####option.Boot Manager 通过设置BootOptionSupport 变量中的EFI_BOOT_OPTION_SUPPORT_KEY 位，中间不同的 bit 位代表的是支持的不同 Boot option.

也就是在 boot 过程中当检测到某个按键被按下时，boot manager 会去检查当前的 key 值和保存的 key#### variable 中的键值，如果相同，则去校验key#### variable 中的 Bootoption 是否有效，若是有效则会去加载这个 bootoption.

需要注意的是若是 Key#### 中的 hot key 和 Boot manager 中已有的功能键冲突 则会忽略冲突的 Key####.

Key#### option 结构体如下：

typedef struct _EFI_KEY_OPTION {
EFI_BOOT_KEY_DATA KeyData;
UINT32 BootOptionCrc;
UINT16 BootOption;
// EFI_INPUT_KEY Keys[];
} EFI_KEY_OPTION;

EFI_BOOT_KEY_DATA 结构如下：

typedef union {
struct {
UINT32 Revision : 8;
UINT32 ShiftPressed : 1;
UINT32 ControlPressed : 1;
UINT32 AltPressed : 1;
UINT32 LogoPressed : 1;
UINT32 MenuPressed : 1;
UINT32 SysReqPressed : 1;
UINT32 Reserved : 16;
UINT32 InputKeyCount : 2;
} Options;
UINT32 PackedValue;
} EFI_BOOT_KEY_DATA;

EFI_INPUT_KEY 结构如下：需要定义对应的ScanCode 和 UnicodeChar

typedef struct {
  UINT16    ScanCode;
  CHAR16    UnicodeChar;
} EFI_INPUT_KEY;

3.1.7 Required System Preparation Applications

SysPrep#### 可以看作是一个环境准备启动项，也就是会在执行 Boot#### Option 之前执行对应的应用的程序。SysPrep#### 启动顺序类似于由BootOrder控制的Boot####，他也有个 Order 变量：SysPrepOrder.所有被置为LOAD_OPTION_ACTIVE 的SysPrep####启动项必须被按照SysPrepOrder 的顺序执行在Boot#### option 之前。

加载SysPrep#### 和 Boot#### 流程并没有什么大区别，只是SysPrep####必须需要退出，而且不能调用 ExitBootServices().而且SysPrep#### 的 LOAD_OPTION_FORCE_RECONNECT 属性会被忽略，也就是若是SysPrep####需要特定的硬件支持的话，需要自己调用ConnectController() or DisconnectController()来重启对应的硬件设备和设备 Driver。

在SysPrepOrder 中所有的SysPrep####都被加载完成之后，需要触发EFI_EVENT_GROUP_READY_TO_BOOT and EFI_EVENT_GROUP_AFTER_READY_TO_BOOT 来执行对应的 event ，然后根据 BootOrder 顺序来设置 Boot#### variable LOAD_OPTION_CATEGORY_BOOT 属性.

标记为 LOAD_OPTION_CATEGORY_BOOT 的变量的 FilePathList 在 EFI_EVENT_GROUP_AFTER_READY_TO_BOOT 事件组处理完成之前不被评估。