【UEFI Spec笔记 10】Device Path Protocol


一、概述

1.设备路径的主要目的是允许应用程序(如操作系统加载程序)确定接口正在抽象的物理设备。
2.ACPI中定义了设备路径的集合叫做命名空间(name space),EFI定义了自己的命名空间叫设备路径。

二、 EFI Device Path Protocol

typedef struct _EFI_DEVICE_PATH_PROTOCOL {
UINT8 Type;         //< 0x01 Hardware Device Path.
                    //< 0x02 ACPI Device Path.
                    //< 0x03 Messaging Device Path.
                    //< 0x04 Media Device Path.
                    //< 0x05 BIOS Boot Specification Device Path.
                    //< 0x7F End of Hardware Device Path.
UINT8 SubType;      //< 因类型而异
                    //< 0xFF 结束整个设备路径
                    //< 0x01 结束当前实例设备路径并开始一个新的设备路径    
UINT8 Length[2];    //大小为整个结构体
UINT8 data[n]; 
} EFI_DEVICE_PATH_PROTOCOL;

1. 0x01 Hardware Device Path

Sub-Type 1 PCI
Sub-Type 2 PCCARD
Sub-Type 3 – Memory Mapped
Sub-Type 4 – Vendor
Sub-Type 5 – Controller
Sub Type 6 – BMC

2. 0x02 ACPI Device Path

Sub-Type 1 ACPI Device Path
Sub-Type 2 Expanded ACPI Device Path
Sub-Type3 _ADR Device Path //视频输出相关

3. 0x03 Messaging Device Path

Sub-Type 1 – ATAPI
Sub-Type 2 – SCSI
Sub-Type 3 – Fibre Channel //光纤通道
Sub-Type 21 – Fibre Channel Ex
Sub-Type 4 – 1394
Sub-Type 5 – USB
例子:PciRoot(0)/PCI(31,2)/USB(1,0)/USB(3,0) 路径描述:ACPI/PCI(D:31,F:2)/USB HUB/USB 详细请看spec
Sub-Type 18 – SATA
Sub-Type 16– USB WWID
Sub-Type 17 – Device Logical unit
Sub-Type 15 - USB Class
Sub-Type 6 – I2O Random Block Storage Class
Sub-Type 11 – MAC Address for a network interface
Sub-Type 12 – IPv4
Sub-Type 13 – IPv6
Sub-Type 9 – InfiniBand
Sub-Type 14 – UART
Sub-Type 10 – Vendor
根据Vendor GUID不同包含UART Flow Control Messaging,SCSI (SAS)等设备路径
Sub-Type 19 – (iSCSI)
Sub-Type 20 – Vlan (802.1q)
Sub-type 22 SAS Ex
Sub Type 23 – NVM Express Namespace
Sub Type 24 – Universal Resource Identifier (URI) Device Path
Sub-Type 25 – UFS (Universal Flash Storage)
Sub-Type 26 – SD
Sub-Type 27 – Bluetooth
Sub Type 28 – Wi-Fi Device Path
Sub-Type 29 – eMMC
Sub-Type 30 – BluetoothLE
Sub-Type 31 – DNS Device Path
Sub-type 32 - NVDIMM Namespace
Sub-Type 32– REST Service Device Path

4. 0x04 Media Device Path

UEFI模式下启动项路径定义在如下设备路径
Sub-Type 1 – Hard Drive
Sub-Type 2 – CD-ROM “El Torito” Format
Sub-Type 3 – Vendor
Sub-Type 4 – File Path
Sub-Type 5 – Media Protocol
Sub-Type 6 – PIWG Firmware File
Sub-Type 7 – PIWG Firmware Volume
Sub-Type 8 – Relative Offset Range
Sub Type 9 – RAM Disk Device Path

5. 0x05 BIOS Boot Specification Device Path

Legacy模式下启动项路径

6. 0x7F End of Hardware Device Path

三 、Device Path Utilities Protocol

创建和操作设备路径和设备节点

typedef struct _EFI_DEVICE_PATH_UTILITIES_PROTOCOL {
EFI_DEVICE_PATH_UTILS_GET_DEVICE_PATH_SIZE GetDevicePathSize;
EFI_DEVICE_PATH_UTILS_DUP_DEVICE_PATH DuplicateDevicePath;
EFI_DEVICE_PATH_UTILS_APPEND_PATH AppendDevicePath;
EFI_DEVICE_PATH_UTILS_APPEND_NODE AppendDeviceNode;
EFI_DEVICE_PATH_UTILS_APPEND_INSTANCE AppendDevicePathInstance;
EFI_DEVICE_PATH_UTILS_GET_NEXT_INSTANCE GetNextDevicePathInstance;
EFI_DEVICE_PATH_UTILS_IS_MULTI_INSTANCE IsDevicePathMultiInstance;
EFI_DEVICE_PATH_UTILS_CREATE_NODE CreateDeviceNode;
} EFI_DEVICE_PATH_UTILITIES_PROTOCOL;

GetDevicePathSize 返回指定设备路径的大小,以字节为单位
DuplicateDevicePath 复制设备路径结构
AppendDeviceNode 将设备节点追加到指定的设备路径
AppendDevicePath将设备路径附加到指定的设备路径
AppendDevicePathInstance将设备路径实例附加到另一个设备路径
GetNextDevicePathInstance从设备路径数据中检索下一个设备路径实例结构
IsDevicePathMultiInstance如果这是一个多实例设备路径,则返回TRUE
CreateDeviceNode 为指定类型和子类型的设备节点分配内存

四 、设备路径二进制与文本转换

机器识别的二进制路径与人类可以阅读的文本之间的转换,为了文本不会转换错误,有一些规则。
1.EFI_DEVICE_PATH_TO_TEXT_PROTOCOL 将设备节点和路径转换为文本

typedef struct _EFI_DEVICE_PATH_TO_TEXT_PROTOCOL {
EFI_DEVICE_PATH_TO_TEXT_NODE ConvertDeviceNodeToText;
EFI_DEVICE_PATH_TO_TEXT_PATH ConvertDevicePathToText;
} EFI_DEVICE_PATH_TO_TEXT_PROTOCOL;

2.EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL 将文本转换为设备路径和设备节点

typedef struct _EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL {
EFI_DEVICE_PATH_FROM_TEXT_NODE ConvertTextToDevicNode;
EFI_DEVICE_PATH_FROM_TEXT_PATH ConvertTextToDevicPath;
} EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL;

总结

后续有更深理解,会继续补充。
学艺不精,错误请指正;
如有侵权,请联系删除。

参考文档: 《UEFI_Spec_2_9_2021_03_18》

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、付费专栏及课程。

余额充值