当前位置: 首页 > news >正文

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

3.2 Boot Manager Policy Protocol

EFI_BOOT_MANAGER_POLICY_PROTOCOL----EFI应用程序使用该协议请求UEFI引导管理器使用平台策略连接设备。

typedef struct _EFI_BOOT_MANAGER_POLICY_PROTOCOL
EFI_BOOT_MANAGER_POLICY_PROTOCOL;
struct _EFI_BOOT_MANAGER_POLICY_PROTOCOL {
UINT64 Revision; EFI_BOOT_MANAGER_POLICY_CONNECT_DEVICE_PATH ConnectDevicePath;//根据DevicepPath来connect 设备
EFI_BOOT_MANAGER_POLICY_CONNECT_DEVICE_CLASS ConnectDeviceClass; //connect 一类型的设备
};

3.3 Globally Defined Variables

本章节主要叙述关于 Variable 的定义。

通过 variable 的 attribute 可以控制 Variable 的访问时期以及生存周期,比如若是 Variable 有 NV 属性,表明这个 variable 是一个非易失性变量,也就是即使断开平台电源,也是可以保存中间的数据(也就是保存在 NVRAM 中,一般有独立的电源:纽扣电池)。在者若是 Variable 有 BS 属性,则表示这个 variable 只能再 EFI_BOOT_SERVICES.ExitBootServices() 调用之前访问,若是 Variable 有 RT 属性,则表明 Variable 可以在 EFI_BOOT_SERVICES.ExitBootServices() 调用之后访问;具有AT属性的变量是第8.2.1节中定义的具有基于时间的身份验证写访问的变量。

所有架构定义的变量都使用EFI_GLOBAL_VARIABLE 来标识,为了避免 name 冲突,其他固件定义的 Variable 需要使用唯一 GUID 来标识。

Table 3-1 Global Variables

3.4 Boot Option Recovery

BootOptionRecovery 由两部分组成,一部分是 操作系统定义的 Recovery,另一部分是平台固件定义的 recovery. 操作系统定义的 Recovery 是尝试恢复所有可能的 boot option,以及完整的操作系统恢复。平台固件定义的定义的recovery 则是最后的恢复手段当没有找到任何操作系统可以恢复时,例如Default Boot Behavior。

如果必须执行引导选项恢复,则引导管理器必须首先尝试操作系统定义的恢复,然后通过boot ####和BootOrder变量重新尝试正常启动,如果没有选项成功,最后尝试平台定义的恢复

3.4.1 OS-Defined Boot Option Recovery

如果 OSIndicators中EFI_OS_INDICATIONS_START_OS_RECOVERY位置起来了,或者处理BootOrder不成功,则平台必须处理操作系统自定义的Recovery选项。在由于OSIndicators而进入os定义的Recovery的情况下,不应处理SysPrepOrder和SysPrep####变量。为了避免意图歧义,如果设置了EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY,则在OSIndicators中忽略该位.

操作系统定义的Recovery使用OsRecoveryOrder变量,以及使用特定于供应商的VendorGuid值和遵循模式OsRecovery####的名称创建的变量。这些变量中的每一个都必须是经过身份验证的变量,并且具有EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS属性.

如果引导管理器在没有调用EFI_BOOT_SERVICES.ExitBootServices()或ResetSystem()的情况下完成处理OsRecovery####选项,它必须尝试第二次处理BootOrder。如果在此过程中引导不成功,则操作系统定义的恢复失败,并且引导管理器必须尝试基于平台的恢复。

如果引导管理器在没有调用EFI_BOOT_SERVICES.ExitBootServices()或ResetSystem()的情况下完成处理OsRecovery####选项,它必须尝试第二次处理BootOrder。如果在此过程中引导不成功,则操作系统定义的恢复失败,并且引导管理器必须尝试基于平台的恢复。

3.5 Boot Mechanisms

EFI可以加载 EFI_SIMPLE_FILE_SYSTEM_PROTOCOL或EFI_LOAD_FILE_PROTOCOL 来选择启动设备启动。支持EFI_SIMPLE_FILE_SYSTEM_PROTOCOL的设备必须抽象出一个文件系统协议才能使该设备可引导。如果一个设备不希望支持一个完整的文件系统,它可以产生一个EFI_LOAD_FILE_PROTOCOL,它允许它直接物化一个映像。Boot Manager将首先尝试加载有 installEFI_SIMPLE_FILE_SYSTEM_PROTOCOL 的设备 handle 进行引导。如果失败,那么将再尝试加载有 install EFI_LOAD_FILE_PROTOCOL 的设备。

3.5.1 Boot via the Simple File Protocol

当通过EFI_SIMPLE_FILE_SYSTEM_PROTOCOL 加载引导时,FilePath将以指向实现EFI_SIMPLE_FILE_SYSTEM_PROTOCOL或EFI_BLOCK_IO_PROTOCOL的设备路径开始。FilePath的下一部分可能指向文件名,包括包含可引导映像的子目录。如果文件名为空设备路径,则必须根据下面定义的规则生成文件名。

如果FilePathList[0]设备不支持EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,但支持EFI_BLOCK_IO_PROTOCOL协议,则必须为FilePathList[0] with调用EFI引导服务EFI_BOOT_SERVICES.ConnectController(),DriverImageHandle和RemainingDevicePath设置为NULL,递归标志设置为TRUE。然后固件将尝试从使用下面列出的算法产生的任何子句柄启动。

文件系统的格式在13.3节中有详细说明。虽然固件必须产生一个理解UEFI文件系统的EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,但任何文件系统都可以用EFI_SIMPLE_FILE_SYSTEM_PROTOCOL接口抽象出来。

struct _EFI_SIMPLE_FILE_SYSTEM_PROTOCOL {////// The version of the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. The version/// specified by this specification is 0x00010000. All future revisions/// must be backwards compatible.///UINT64                                         Revision;EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_OPEN_VOLUME    OpenVolume;
};
3.5.1.1 Removable Media Boot Behavior

要在FilePath中没有文件名时生成文件名,固件必须以\EFI\BOOT\BOOT{machine type short-name}的形式附加一个默认文件名。EFI,其中机器类型短名称定义了一个PE32+图像格式架构。每个文件只包含一种UEFI映像类型,系统可能支持从一种或多种映像类型启动。UEFI镜像类型如表3-2所示。

3.5.2 Boot via the Load File Protocol

当通过EFI_LOAD_FILE_PROTOCOL协议引导时,FilePath是一个设备路径,它指向一个“说”EFI_LOAD_FILE_PROTOCOL的设备。映像直接从支持EFI_LOAD_FILE_PROTOCOL的设备加载。FilePath的其余部分将包含特定于设备的信息。固件将这个特定于设备的数据传递给加载的映像,但不使用它来加载映像。如果FilePath的剩余部分为空设备路径,则加载的映像负责实现查找正确引导设备.

typedef
EFI_STATUS
(EFIAPI *EFI_LOAD_FILE)(IN EFI_LOAD_FILE_PROTOCOL           *This,IN EFI_DEVICE_PATH_PROTOCOL         *FilePath,IN BOOLEAN                          BootPolicy,IN OUT UINTN                        *BufferSize,IN VOID                             *Buffer OPTIONAL);///
/// The EFI_LOAD_FILE_PROTOCOL is a simple protocol used to obtain files from arbitrary devices.
///
struct _EFI_LOAD_FILE_PROTOCOL {EFI_LOAD_FILE    LoadFile;
};

EFI_LOAD_FILE_PROTOCOL用于不直接支持文件系统的设备。网络设备通常在这种模型中启动,其中映像是固化的也就是直接时对应的 BNP 文件,而不需要文件系统。

3.5.2.1 Network Booting

网络引导由Preboot eXecution Environment(PXE) BIOS支持规范描述,该规范是有线管理基线规范的一部分。PXE指定了启动平台与智能系统负载服务器交互时可以使用的UDP、DHCP和TFTP网络协议。UEFI定义了用于实现PXE的特殊接口。这些接口包含在EFI_PXE_BASE_CODE_PROTOCOL中(参见第24.3节)。

http://www.lryc.cn/news/496575.html

相关文章:

  • ATTCK红队评估实战靶场(四)
  • Android Studio 历史版本下载
  • 微信小程序px和rpx单位互转方法
  • Vercel 部署与管理指南:简化前端应用的自动化部署流程
  • Java11使用JVM同一日志框架启用日志记录
  • onlyoffice实现文档比对(Beta版)-纯文字比对(非OCR)
  • JS querySelector方法的优点
  • 利用获取商品详情API:item_get可以获取到淘宝商品详情的哪些数据?
  • 【大数据学习 | 面经】Spark 3.x 中的AQE(自适应查询执行)
  • [Vue]Vue-router
  • 【HarmonyOS】鸿蒙应用使用lottie动画
  • 1.使用docker 部署redis Cluster模式 集群3主3从
  • vue基础之8:computed对比watch
  • Luban数据插件的用法
  • 指针(上)
  • 张伟楠动手学强化学习笔记|第一讲(上)
  • python脚本:Word文档批量转PDF格式
  • 性能测试常见面试问题和答案
  • uniapp进阶技巧:如何优雅地封装request实例
  • 实验五、流式视频服务程序mjpg-streamer移植实验
  • (长期更新)《零基础入门 ArcGIS(ArcMap) 》实验三----学校选址与路径规划(超超超详细!!!)
  • L16.【LeetCode笔记】前序遍历
  • 泰州榉之乡全托机构探讨:自闭症并非家庭的 “末日”
  • BiGRU:双向门控循环单元在序列处理中的深度探索
  • 【vue-router】Vue-router如何实现路由懒加载
  • Linux网络编程基础
  • MySQL中的幻读问题
  • AI后端工程师面试题的内容
  • MFC工控项目实例三十五读取数据库数据
  • OpenWrt -制作ubifs文件系统的固件