UEFI标准与架构简介

参考文档:Vincent Zimmer, Michael Rothman, Suresh Marisetty - Beyond BIOS_ Developing with the Unified Extensible Firmware Interface-De_G Press (2017).pdf

uefi  spec

http://www.lab-z.com/uefi-spec/

https://uefi.org/specifications/

 

bios全称Basic Input/Output System,会碰到的实际场景。

What can the operating system count on when it is loaded and initially receives control? 操作系统loaded初始化之后获取控制权的依据是什么?
How can the same basic structure work for handhelds and megaservers?
相同的基本结构如何适用于手持设备和大型服务器?
How do we convince ourselves today’s design will work 10 or 20 years from now?
如何确保设计在10年或20年后有效?
What comes after BIOS (Basic Input/Output System)?
bios之后的过程?

How should you boot a computer?  如何启动一个系统?

What sits at the reset vector?  复位表位于什么位置?

 

UEFI架构?UEFI的驱动模型?驱动存储的host-bus adapter, 平台rom,或者uefi系统分区

UEFI的标准规范在www.uefi.org,uefi适用于window, linux,

 

 

www.tianocore.org EDK1, EFI Developer Kit 开源efi代码
EFI由Intel发起,可扩展固件接口(EFI)项目是由英特尔开发的,其最初是于1999年发布的规范。当时,它被设计为 引导基于Itanium的系统。启动Itanium的最初建议是
SAL(系统架构层)SAL_PROC接口,带有封装 PC / AT BIOS注册为参数和参数。具体来说,访问SAL_PROC提议中的磁盘为“ SAL_PROC(0x13,0x2,…)”,即
与PC / AT常规BIOS调用“ int13h”保持一致。 
Bios演进的时间表

 

不同版本的uefi新的feature
UEFI 2.1 新增加特性 
□人机界面基础架构 
□硬件错误记录支持 
□认证变量支持 
□简单文本输入扩展 
□绝对指针支持 
■UEFI 2.2 
–现有2.1版本的兼容
–与安全/完整性相关的增强功能 
□为要运行的UEFI驱动程序提供服务接口 
与UEFI的高完整性实现 
–人机界面基础架构增强 
-联网 : IPv6,PXE +,IPsec 
–可能有其他各种学科领域 
–更多启动设备,更多身份验证支持,更多网络更新, 等等 
■UEFI 2.3 
– ARM绑定  
–固件管理协议 

UEFI 2.4
–将磁盘IO2作为对称性添加到块IO2 
– AIP协议(FCoE /图像/ iSCSI) 
–时间戳协议 
– RNG /熵协议 
–通过capsule进行FMP输送 
–磁盘上的capsule 

■UEFI 2.5  
– HASH2协议 
– ESRT 
–智能卡读卡器 
–IPV6 for UNDI
–内联密码接口协议
–永久内存类型  
– PKCS7签名验证服务 
– AArch64 
– NVMe直通协议 ,透传协议
– HTTP启动 
–蓝牙支持 
– REST协议 
–智能卡边缘协议 
–正则表达式协议
– x-UEFI关键字支持 
–传输层安全性(TLS)支持 

■UEFI 2.6  
– SD / eMMC直通协议 
– FontEx / Font字形生成器协议 
–无线MAC连接协议 
– RAM磁盘协议 
为了补充图1.5中的分层图片,图1.6显示了PI元素如何演变成UEFI。
图的左半部分包含SEC,PEI和DXE,分别为由PI规范描述。
BDS,UEFI + OS Loader握手和RT是UEFI规范的内容。

 

 

 

实现uefi涉及的组织与友商有哪些?需要各方协力合作

operating system vendors 操作系统供应商

bios vendors提供UEFI实现的BIOS供应商

平台制造商 platform manufacturers

创建UEFI应用程序和诊断程序的独立软件供应商;

为适配器卡创建驱动程序的独立硬件供应商

uefi的安全性架构

 
嵌入式系统uefi的挑战:
  1. 引导过程如何区别于正常引导和优化/嵌入式开机?如下图,设计上没有差异;可以限定内容

 

 
统一可扩展固件接口(UEFI)描述了程序接口到平台的规范。该平台包括主板,芯片组,中央处理单元(CPU)和其他组件。
UEFI的关键概念
■由基于UEFI的固件管理的对象-用于管理系统状态,包括
I / O设备,内存和事件 
UEFI驱动程序很少需要使用计数器,看门狗定时器或实时时钟。UEFI系统表是最重要的数据结构,
因为它提供对所有UEFI提供的服务以及所有其他数据的访问 描述平台配置的结构。 
■UEFI系统表-具有数据信息表的主要数据结构 
和函数调用以与系统接口 

UEFI系统表是UEFI中最重要的数据结构。指向的指针
UEFI系统表作为其入口点的一部分传递到每个驱动程序和应用程序中 
交出。通过这种数据结构,UEFI可执行映像可以访问
系统配置信息和丰富的UEFI服务集合,其中包括以下几点: 
--》UEFI引导服务 
--》UEFI运行时服务 
--》协议服务

■处理数据库和协议-调用可调用接口的方法
处理数据库Handle database
UEFI句柄可能代表以下组件:
--》可执行映像,例如UEFI驱动程序和UEFI应用程序 
--》设备,例如网络控制器和硬盘驱动器分区 
--》UEFI服务,例如UEFI减压和EBC虚拟机 

协议

UEFI的可扩展性在很大程度上是围绕协议构建的。UEFI驱动容易与UEFI协议混淆。尽管它们密切相关,但他们明显不同。
UEFI驱动程序是可执行的UEFI映像,可安装各种处理各种协议来完成其工作。 协议描述如下
Sample GUID

#define EFI_COMPONENT_NAME2_PROTOCOL_GUID \

{0x6a7a5cff, 0xe8d9, 0x4f70, 0xba, 0xda, 0x75, 0xab,

0x30, 0x25, 0xce, 0x14}

Protocol Interface Structure

typedef struct _EFI_COMPONENT_NAME2_PROTOCOL {

EFI_COMPONENT_NAME_GET_DRIVER_NAME

GetDriverName;

EFI_COMPONENT_NAME_GET_CONTROLLER_NAME

GetControllerName;

CHAR8

*SupportedLanguages;

} EFI_COMPONENT_NAME2_PROTOCOL;
 

 

 

 

 

 

 
图2.3显示了来自句柄数据库的单个句柄和协议,由UEFI驱动程序引导。该协议由一个GUID和一个协议接口组成结构体。
很多时候,生成协议接口的UEFI驱动程序会维护
其他私人数据字段。协议接口结构本身仅包含协议功能的指针。协议功能实际包含
在UEFI驱动程序中。UEFI驱动程序可能会产生一个协议或多个协议取决于driver的复杂程度。
并非所有协议都在UEFI 2.6规范中定义。EFI开发人员套件II(EDKII)包含许多不属于UEFI 2.6规范的协议。

该项目可以在http://www.tianocore.org上找到。这些协议提供了更广泛的任何特定实现中可能需要的功能范围,但
它们未在UEFI 2.6规范中定义,因为它们不提供支持引导操作系统或编写UEFI驱动程序所需的内部接口。 
新协议的创建是如何随时间扩展基于UEFI的系统。随着新设备,总线和技术的引入。例如,某些协议在EDK II中但不在UEFI 2.6规范中的是:  
--》Varstore –用于抽象存储UEFI持久二进制对象的接口 
--》ConIn –提供字符控制台输入的服务 
--》ConOut –提供字符控制台输出的服务 
--》 StdErr –为错误消息提供字符控制台输出的服务 
--》PrimaryConIn –具有主视图的控制台输入 
--》VgaMiniPort –提供视频图形阵列输出的服务 
--》UsbAtapi –一种抽象访问USB总线上的块的服务 
 
UEFI应用工具包还包含许多UEFI协议,这些协议可能是在某些平台上找到,例如:  
--》 PPP守护程序–点对点协议驱动程序 
--》Ramdisk –随机存取内存缓冲区上的文件系统实例 
--》TCP / IP –传输控制协议/ Internet协议 
--》Trusted Computing Group接口和平台规范,例如:

在启动期间,任何UEFI代码都可以使用协议进行操作。但是,退出后-
调用BootServices()后,句柄数据库将不再可用。一些
UEFI引导时间服务与UEFI协议一起使用。  
■UEFI映像-部署代码所采用的可执行内容格式 
■事件-响应其他信号而发出信号的方式 
事件是通过UEFI服务管理的另一种对象。一个事件可以被创建和销毁,事件可以处于等待状态或信号
最终状态。UEFI映像可以执行以下任一操作:
--》 创建一个事件。 
--》销毁事件。 
--》检查事件是否处于信号状态。 
--》等待事件处于信号状态。  
--》请求将事件从等待状态转移到发信号状态。
由于UEFI不支持中断,因此可能会给习惯了中断驱动程序模型的驱动程序编写者带来挑战 。相反,UEFI支持轮询
driver。UEFI驱动程序最常见的事件用法是使用计时器事件允许驱动程序定期轮询设备。
■设备路径-描述实体硬件位置的数据结构,例如格式化后的UEFI映像的总线,spindle,分区和文件名磁盘。
 
 
 
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.
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值