UEFI Spec chapter10 protocols-Device Path Protocol


前言

本节包含设备路径协议的定义,以及在UEFI环境中构建和管理设备路径所需的信息。固件构造并使用设备路径来传递重要设备的位置,如引导设备和控制台,这与系统的软件可见拓扑结构一致。


提示:以下是本篇文章正文内容,下面案例可供参考

一、Device Path Overview

设备路径用于定义到设备的编程路径。设备路径的主要目的是允许应用程序(比如OS加载程序)确定接口要抽象的物理设备。

设备路径的集合通常称为名称空间。例如,ACPI是基于用ASL (ACPI源语言)编写的名称空间。如果EFI不取代ACPI,并且在可能的情况下服从ACPI,那么在EFI中利用ACPI名称空间似乎是合理的。但是,ACPI名称空间是为在操作系统运行时使用而设计的,不太适合平台固件或OS加载程序。因此,EFI定义了自己的名称空间,称为设备路径

设备路径被设计成最大限度地利用ACPI名称空间。设备路径中的一个关键结构定义了回ACPI名称空间的链接。设备路径还用于填补ACPI遵循标准枚举算法总线的空白。设备路径能够通过标准枚举机制将有关总线上正在使用哪个设备的信息关联起来。设备路径也用来定义介质中文件的位置,或者文件是从哪里加载的。设备路径的一个特殊情况也可以用来支持从传统介质启动传统操作系统的可选启动。

设备路径的设计是为了让OS加载程序和操作系统能够知道平台固件使用哪些设备作为引导设备。这允许操作系统维护与平台固件一致的系统视图。这方面的一个例子是“无头”系统,它使用网络连接作为引导设备和控制台。在这种情况下,固件将向操作系统传递网络适配器和网络协议信息,这些信息在这些设备的设备路径中用作控制台和引导设备。

二、EFI Device Path Protocol

1.EFI_DEVICE_PATH_PROTOCOL

可以在任何设备句柄上使用,以获取有关物理设备或逻辑设备的通用路径/位置信息。如果句柄在逻辑上没有映射到物理设备,那么句柄可能不一定支持设备路径协议。设备路径描述了句柄所在的设备位置。设备路径的大小可以由组成设备路径的结构来确定。

GUID
#define EFI_DEVICE_PATH_PROTOCOL_GUID \
 {0x09576e91,0x6d3f,0x11d2,\
  {0x8e,0x39,0x00,0xa0,0xc9,0x69,0x72,0x3b}}
Protocol Interface Structure
//*******************************************************
// EFI_DEVICE_PATH_PROTOCOL
//*******************************************************
typedef struct _EFI_DEVICE_PATH_PROTOCOL {
 UINT8 Type;
 UINT8 SubType;
 UINT8 Length[2];
} EFI_DEVICE_PATH_PROTOCOL;

执行UEFI Image可以使用设备路径将自己的设备驱动程序匹配到特定的设备。注意,执行UEFI OS加载程序和UEFI应用程序映像必须通过BootServices设备句柄访问所有物理设备,直到成功调用EFI_BOOT_SERVICES.ExitBootServices()。UEFI驱动程序只能访问它提供功能的物理设备。 

三、Device Path Nodes

设备路径节点主要有六种类型:

•硬件设备路径。这个设备路径定义了一个设备是如何连接到一个系统的资源域的,其中资源域是简单的共享内存,内存映射I/O和系统的I/O空间。
•ACPI设备路径。此设备路径用于描述未以行业标准方式描述枚举的设备。这些设备必须在ACPI名称空间中使用ACPI AML进行描述;这个设备路径是一个到ACPI名称空间的链接。
•消息传递设备路径。此设备路径用于描述系统资源域以外的设备对接。该设备路径可以描述物理消息信息(如SCSI ID),或抽象信息(如网络协议IP地址)。
•媒体设备路径。该设备路径用于描述被引导服务抽象的介质部分。例如,Media Device Path可以定义正在使用硬盘驱动器上的哪个分区。
•BIOS引导规范设备路径。此设备路径用于指向引导传统操作系统;它基于BIOS Boot Specification Version 1.01。关于获得该规范的详细信息,请参阅附录Q。
•结束硬件设备路径。根据子类型的不同,该设备路径节点用于指示设备路径实例或设备路径结构的结束。

UEFI SPEC一共定义了6个大类(Type)的Device Path Node,每个大类下面又分不同的子类(Sub-Type)。大类划分参考下面表格,子类的划分比较繁杂不便一一展开,请直接参考UEFI SPEC。

大类可表示的典型设备/对象
Hardware Device PathPCI设备,Vendor自定义设备,BMC
ACPI Device PathPCI总线域(如上面的PciRoot(0x0))
显示输出设备,ACPI设备(比如鼠标/键盘等)
Messaging Device PathIDE设备,USB设备,SATA设备,SAS设备,SCSI设备,UART设备,Vendor自定义对象,MAC地址,IPv4/IPv6地址,其他新兴设备
Media Device Path硬盘分区,CDROM分区,Vendor自定义Media,文件路径,UEFI固件分区,UEFI固件文件,RAM Disk
BIOS Boot Specification Device Path传统的BIOS启动设备
End of Hardware Device PathDevice Path终结符

1. Generic Device Path Structures

设备路径是一个变长二进制结构,由变长通用设备路径节点组成。表10-1定义了可变长度通用设备路径节点的结构及其组件的长度。该表定义了10.3节中描述的设备路径对应的类型和子类型值;其他类型和子类型均为“保留”。

一个设备路径是一系列通用的设备路径节点。第一个设备路径节点从设备路径的字节偏移量0开始。下一个设备路径节点从上一个设备路径节点的末尾开始。因此,所有节点都是字节打包的数据结构,可能出现在任何字节边界上。所有对设备路径注释的代码引用必须假设所有字段都是不对齐的。由于每个设备路径节点都在已知位置包含长度字段,因此可以遍历未知类型的设备路径节点。设备路径中节点的数量、类型和顺序没有限制。

设备路径由“硬件设备路径结束”节点终止。这种类型的节点有两个子类型(见表10-2):

•结束该设备路径实例(子类型0x01)。这种类型的节点终止一个设备路径实例,并表示另一个的开始。只有当环境变量表示多个设备时才需要这样做。这方面的一个例子是由VGA控制台和串行输出控制台组成的ConsoleOut环境变量。这个变量将描述一个控制台输出流,它同时被发送到VGA和串行,因此有一个包含两个完整设备路径的设备路径。
•结束整个设备路径(子类型0xFF)。这种类型的节点终止整个设备路径。软件搜索此子类型以找到设备路径的结尾。所有“设备路径”必须以该子类型结尾。


This Unified Extensible Firmware Interface (hereafter known as UEFI) Specification describes an interface between the operating system (OS) and the platform firmware. UEFI was preceded by the Extensible Firmware Interface Specification 1.10 (EFI). As a result, some code and certain protocol names retain the EFI designation. Unless otherwise noted, EFI designations in this specification may be assumed to be part of UEFI. The interface is in the form of data tables that contain platform-related information, and boot and runtime service calls that are available to the OS loader and the OS. Together, these provide a standard environment for booting an OS. This specification is designed as a pure interface specification. As such, the specification defines the set of interfaces and structures that platform firmware must implement. Similarly, the specification defines the set of interfaces and structures that the OS may use in booting. How either the firmware developer chooses to implement the required elements or the OS developer chooses to make use of those interfaces and structures is an implementation decision left for the developer. The intent of this specification is to define a way for the OS and platform firmware to communicate only information necessary to support the OS boot process. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the OS by the platform and firmware. Using this formal definition, a shrink-wrap OS intended to run on platforms compatible with supported processor specifications will be able to boot on a variety of system designs without further platform or OS customization. The definition will also allow for platform innovation to introduce new features and functionality that enhance platform capability without requiring new code to be written in the OS boot sequence. Furthermore, an abstract specification opens a route to replace legacy devices and firmware code over time. New device types and associated code can provide equivalent functionality through the same defined abstract interface, again without impact on the OS boot support code. The specification is applicable to a full range of hardware platforms from mobile systems to servers. The specification provides a core set of services along with a selection of protocol interfaces. The selection of protocol interfaces can evolve over time to be optimized for various platform market segments. At the same time, the specification allows maximum extensibility and customization abilities for OEMs to allow differentiation. In this, the purpose of UEFI is to define an evolutionary path from the traditional “PC-AT”- style boot world into a legacy-API free environment.
统一可扩展固件接口(UEFI)规范描述了操作系统和平台固件之间的接口。UEFI之前是可扩展固件接口规范1.10 (EFI)。因此,一些代码和某些协议名称保留了EFI名称。除非另有说明,本规范中的EFI名称可能被认为是UEFI的一部分。 接口采用数据表的形式,其中包含与平台相关的信息,以及OS加载器和OS可用的引导和运行时服务调用。它们共同提供了一个引导操作系统的标准环境。本规范是作为一个纯粹的接口规范设计的。因此,该规范定义了平台固件必须实现的接口和结构集。类似地,该规范定义了操作系统在引导时可能使用的一组接口和结构。固件开发人员如何选择实现所需的元素,或者操作系统开发人员如何选择利用这些接口和结构,这是留给开发人员的实现决策。 该规范的目的是定义一种方法,使操作系统和平台固件仅通信支持操作系统引导过程所必需的信息。这是通过平台和固件提供给操作系统的软件可见接口的正式和完整的抽象规范来实现的。 使用这一正式定义,旨在运行在与受支持的处理器规范兼容的平台上的收缩包装操作系统将能够在各种系统设计上启动,而无需进一步的平台或操作系统定制。该定义还允许平台创新引入新特性和功能,以增强平台的能力,而不需要按照操作系统的引导顺序编写新代码。 此外,抽象规范开辟了一条替代遗留设备和固件代码的路径。新的设备类型和相关代码可以通过相同定义的抽象接口提供同等的功能,同样不会影响OS引导支持代码。 该规范适用于从移动系统到服务器的所有硬件平台。该规范提供了一组核心服务以及一组协议接口。协议接口的选择可以随着时间的推移而发展,并针对不同的平台市场细分进行优化。与此同时,该规范允许oem提供最大限度的可扩展性和定制能力,以实现差异化。在这方面,UEFI的目的是定义一个从传统的“PC-AT”风格的引导世界到一个没有遗留api的环境的进化路径。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值