UEFI介绍


声明

本文主要介绍UEFI的发展历史,以及对UEFI在ARM嵌入式领域的生态状况做了简单的调研。下一篇会对UEFI和PI规范做一些简单介绍。
本篇参考内容主要来源于以下3方面:
(1) 微信公众号“ Wolf UEFI社区 ”系列文章。
(2) 《UEFI原理与编程》—戴正华。
(3) UEFI Spec和PI Spec官方文档。

1.缘起

UEFI最初是为BIOS所设计的,由于Legacy BIOS(存在近40年)历史局限性,一直无法跟上硬件的发展,并且在可编程、可维护性、安全性方面表现很差。

考虑到传统BIOS的诸多问题,前辈们迫切希望降低这些底层固件代码的复杂性,并希望对操作系统提供尽可能少的平台硬件细节。做法是:在平台固件和OS加载器\OS之间设计一套基于高级C语言(当时固件用汇编写的,相对来说C算高级语言)的接口。基于这个想法,最初的EFI(Extensible Firmware Interface)诞生,其定义了启动过程中底层固件和操作系统之间的接口,该接口和CPU架构无关。

2.历史纪年

EFI诞生:

1999年,IBI计划制定了新接口的首版规范。开发者们将新规范命名为EFI(Extensible Firmware Interface),同时呼吁使之成为未来成长的Base。EFI规范对任何特定类型的电脑保持中立性,旨在仅仅描述接口。

2000年12月,英特尔发布了EFI规范1.02初始版本。规范约定的范围涵盖了系统从平台固件运行至控制权转移到操作系统的过程。

2002年,在早期版本的基础上发布了EFI规范1.10版本。这次更新主要在规范中添加了一个固件驱动模型,该模型解决了在引导过程中使用扩展卡设备的问题。本质上,这提供了一种替代最先应用在ISA总线设备上的脆弱的16位可选ROM的可行性,并很快也用于PCI引导设备。

UEFI诞生:

2005年年中,行业大会召开。包括BIOS供应商,OS供应商,系统制造商以及芯片生产公司在内的行业参与者建立了统一的EFI论坛(UEFI,Unified Extensible Firmware Interface),并声明长期共同管理这项技术。

作为行业执牛角者,Intel贡献了EFI规范,作为新论坛的开端。创始成员们以真正统一的方式工作,制定了受到行业广泛支持和认可的新规范。这份由论坛所制定的首版规范——UEFI规范2.0,于2006年一月发行。

除了制定固件与操作系统间接口外,论坛同意为固件内部制定符合UEFI规范的标准化接口。这项工作产生了PI规范(Platform Initialization)。PI规范1.0于2016年10月发布。这份规范旨在使芯片驱动程序可以在各种固件厂商开发的平台上直接运行而无需修改,从而简化和缩短新产品的部署。

2007年1月,发布UEFI 2.1版本。这种基础设施的引入,使得固件的用户界面更加图形化,本地化。

2008年9月,推出UEFI 2.2版本。加入了对IPv6的支持,同时改进了平台安全策略。2.2版本曾在很短的段时间内是最大/最完善的版本,很大一部分原因在于实施在规范之后。

对于ARM生态的支持方面:

2009 年,UEFI 联盟公布UEFI 2.3 规范,将对ARM 平台的支持纳入规范。

2013 年,发布UEFI 2.4 规范,包含了对ARM 64 位架构处理器的支持。ARM-UEFI 已经成为了规范的一部分。

UEFI和PI还在继续演进中,最新的规范是UEFI 2.5和PI 1.4

开源:

Intel提供了首版EFI规范的最初的开源示例实现。随着UEFI和PI规范的更新,这项工作还在进行中。

UEFI项目目标比较远大,希望支持所有类型的CPU,并成为事实上的BIOS标准。为此,Intel成立了开源组织TianoCore,其目标就是提供UEFI标准的实现,以及各类工具和开源代码,促进UEFI的健康发展。

开源社区“tianocore.org”于2004年开始,采用BSD许可证。TianoCore的代码最早落户于www.tianocore.org。在开源大潮的带领下,先扎根于SourceForge,后随着Github火遍全球,也移步于Github。可以在https://github.com/tianocore下找到许多相关的项目。其中,最核心的项目就是EDK2。EDK2项目是TianoCore为实现UEFI标准和PI标准(平台初始化标准)而开发的,支持多种CPU架构的固件和程序。包括ARM、X86、RISC-V等。

对于ARM生态的支持方面:

随着ARM平台纳入UEFI规范,苹果和惠普向tianocore.org贡献了UEFI的参考实现(其中对Beagle Board的一个实现)。使供应商可为他们的硬件提供UEFI的驱动程序。 ARM公司也贡献了使用Cortex A9 多核处理器的Versatile Express参考平台的核心代码。

现在已经过去十多年,越来越多的ARM玩家已经加入到了UEFI大家庭。下一章对UEFI + ARM 平台生态进行更详细介绍。

3. UEFI在ARM 中的生态

前面我们介绍了UEFI的诞生主要是为了解决传统BIOS的痼疾,UEFI一开始就是作为Legacy BIOS的替代品使用的。So, UEFI主要是X86的开发者在玩吗?答案当然是:NO!

ARM生态越来越需要通用性和标准。

ARM生态一直以来缺乏统一的标准。随着ARM进入到x86的传统领域—PC和服务器市场,他们一样也要面临碎片化的生态系统的问题。于是接受UEFI和ACPI变成了必然的选择。

** UEFI在ARM生态中越来越成熟。**

就UEFI对ARM的支持来讲, UEFI 2.3 规范,将对ARM 平台的支持纳入规范。UEFI 2.4 规范,包含了对ARM 64 位架构处理器的支持。ARM-UEFI 已经成为了规范的一部分。

UEFI在ARM生态中越来越成熟。这也从EDK2社区最活跃的用户在近几年已经不是x86的开发者,而是ARM相关开发者(最近一年多换成了RISC-V)可以看出。于此同时EDK2开源平台仓库EDK2_Platforms下面也涌入了大量ARM平台,如海思、NXP、树莓派等等。

当前现状是,所有成熟的ARM服务器产品都采用UEFI+ACPI方案;很多ARM移动和桌面产品也已经采用UEFI+ACPI方案;大量ARM产品在赶来的路上。

4.UEFI在嵌入式中的生态

前面我们介绍了,UEFI 起初主要是作为BIOS的替代品,也就是说起初主要玩家在PC领域。那么UEFI在嵌入式产品中的情况是什么样的呢?

在大多数人心目中,ARM 嵌入式世界的BootLoader还被Uboot+DeviceTree统治。但是只要查看EDK2代码,就会发现Hisilicon、NXP、RaspberryPi等好多大厂都upstream了他们的ARM嵌入式平台代码。可见UEFI在ARM 嵌入式中的生态也已经非常成熟。以手机芯片大厂高通为例,其从MSM8998开始使用UEFI替代LK(Little Kernel)作为手机的Bootloader。

除了很多ARM芯片厂商都在其自己的芯片上使用UEFI固件之外,嵌入式Bootloader(Uboot等)也在向UEFI靠拢。具体表现为,部分bootloader也在基于UEFI标准定义自己的接口,比如U-boot20号称实现了40%的UEFI接口。

作为嵌入式开发者我们知道,嵌入式领域的Bootloader(u-boot、LK等)大都是基于C语言开发的,并没有之前所说的传统BIOS那样的问题。

为什么大厂他们的嵌入式产品也开始向UEFI 转移阵地呢?UEFI相对当前的嵌入式Bootloader有什么优势呢?下一节展开描述。

5.为何选择UEFI

为何大家都开始玩UEFI呢?

我们先从PC中的BIOS、嵌入式系统Bootloader、以及UEFI固件EDK2三者的功能做一个对比。

  • BIOS的最主要的功能:枚举和初始化硬件平台,并提供硬件的软件抽象,引导操作系统启动。
  • Bootloader的最主要功能:初始化硬件平台,加载并引导操作系统。
  • EDK2 针对PC具有BIOS的功能,针对嵌入式平台具有Bootloader的功能。

EDK2在兼具Legacy BIOS和传统嵌入式Bootloader功能之外,同时符合UEFI标准和PI规范的操作系统启动固件。它即可以支持不同架构的硬件平台,也可以支持启动不同的操作系统。它相对前二者最大的不同就是标准化和通用性。

通过对比我们可知,无论BIOS,还是嵌入式领域各种类型Bootloader,他们都具有两个最重要使命是:初始化硬件平台和引导操作系统。

UEFI很好的解决了传统BIOS的移植性差、碎片化等问题,是否也可以作为嵌入式Bootloader的标准呢?答案自然是:Sure。

5.1 ARM Bootloader 的不足

其实,Bootloader之于嵌入式平台,比BIOS之于PC要好太多。Bootloader(u-boot、LK等)简单快捷,移植容易。那它有什么不足吗?

当然有,至少体现在两点:缺乏标准和互操作性。

这种问题是从娘胎里带来的。嵌入式设备往往是垂直定制开发的,从硬件、固件、BSP和操作系统,都深度定制,没有问题是定制修改程序所不能解决的。这导致Bootloader 更合适专用系统,而不是通用系统。
不同芯片厂商的Bootloader也是五花八门。对下游玩家来说想像X86 PC那样,使用不同厂商的组件规划自己的产品很难实现。

随着ARM生态的发展,尤其进入PC市场后,对通用性的需求越烈越强烈。作为ARM世界的灵魂,ARM公司也意识到了生态碎片化的问题,因此推出了大量规范和标准,来规范ARM产品的行为。如针对服务器的服务器的SBSASBBR规范,最新的基本系统架构(BSA)、基本启动要求(BBR),以及针对安全的基本启动安全要求(BBSR)等等。

ARM的这些规范多而杂,后面又演化为Arm SystemReady。分别对服务器系统、物联网边缘设备、嵌入式系统等ARM产品的架构和启动等内容进行规范。

5.2 为何选择UEFI

前面已经提到,ARM嵌入式Bootloader有缺乏标准和互操作性的问题。自然UEFI 系统能解决这两个问题,所以才选择UEFI。

那么ARM SystemReady 能解决上述问题吗,它会是UEFI之外的另一个选择吗?
其实,ARM SystemReady 和UEFI并不冲突。其中ARM针对嵌入式设备的EBBR标准,旨在嵌入式系统生态系统中缺乏引导时序标准化的问题。下面是摘自EBBR规范的一段话,大家自行阅读。

EBBR was written as a response to the lack of boot sequence standardization in the embedded system ecosystem.As embedded systems are becoming more sophisticated and connected, it is becoming increasingly important forembedded systems to run standard OS distributions and software stacks, or to have consistent behaviour across alarge deployment of heterogeneous platforms. However, the lack of consistency between platforms often requiresper-platform customization to get an OS image to boot on multiple platforms.

A large part of this ecosystem is based on U-Boot and Linux. Vendors have heavy investments in both projects and are not interested in large scale changes to their firmware architecture. The challenge for EBBR is to define a set of boot standards that reduce the amount of custom engineering required, make it possible for OS distributions to support embedded platforms, while still preserving the firmware stack product vendors are comfortable with. Or in simpler terms, EBBR is designed to solve the embedded boot mess by adding a defined standard (UEFI) to the existing firmware projects (U-Boot).

However, EBBR is a specification, not an implementation. The goal of EBBR is not to mandate U-Boot and
Linux. Rather, it is to mandate interfaces that can be implemented by any firmware or OS project, while at the
same time work with both Tianocore/EDK2 and U-Boot to ensure that the EBBR requirements are implemented
by both projects.1

从这两段话,我们提取出的有用信息是:

  1. EBBR旨在解决嵌入式启动固件(U-Boot等)的启动时序缺乏标准化的问题。更简单的说,就是在现有启动固件(U-Boot等)之上增加一层标准接口(UEFI)。和PI规范目标一致。
  2. EBBR 主要限定了各种嵌入式固件和操作系统之间的接口。和UEFI规范的目标一致。
    3.Uboot可以和Tianocore/EDK2同时工作,以确保EBBR的需求得以实现。

由此可见EBBR 还是比较开放了,它的主旨和UEFI一致,就是为了使嵌入式系统启动时序标准化,在平台固件和操作系统之间提供标准接口。

EBBR并没有说必需以什么方式实现。而是提供了两个思路:

  • 现有嵌入式Bootloader实现UEFI 接口。
  • 现有Bootloader和Tianocore/EDK2同时工作。我理解是现有Bootloader和Tianocore/EDK2同时在一个嵌入式系统存在。

个人觉得,第一种方案虽然限定了接口标准,但是实现方式可能依然五花八门,不能确保启动时序的标准化。第二种方案,还不如直接使用EDK2一种。仅代表个人观点。

总结:
由此可见,ARM 嵌入式实现UEFI,是ARM SystemReady 所要求的。

5.3 使用UEFI能带来什么收益

前面已经介绍了既有ARM 嵌入式Bootloader 在通用性方面的不足,UEFI可以弥补这些不足。UEFI带来的收益自然也体现在互操作性和标准化两个方面。

最直观的收益就是降低 OEM / ODM厂商开发成本。对于 OEM / ODM厂商来说,使用UEFI系统带来的收益:

  1. 实现ARM和X86产品代码之间复用,不同处理器架构的产品之间代码复用。不同产品可以复用外设驱动代码。
  2. 由于UEFI优秀的解耦和模块化设计,可以使得嵌入式产品OEM / ODM厂商能够灵活的选择使用不同硬件厂商的硬件模块,降低移植门槛。
  3. 对于操作系统厂商,这种标准化使它们能够集中在同一个引导程序方面的投资。这种标准化也将为独立软件开发商提供新的创新的机会。

就技术来看带来的收益:

  1. 上层应用程序能很好的复用。UEFI 固件通过 抽象化的(BS和RT服务)向OS加载器和OS提供接口,屏蔽了底层硬件细节。使得UEFI上层应用可以很方便重用。
  2. 良好的可扩展性。由于UEFI 基于的各个组件都以模块化的方法设计,模块可以支持动态加载。很方便扩展和升级。

开宗明义—UEFI介绍 (一)相关推荐

  1. GTP与MBR硬盘分区区别(UEFI介绍)

    在重装win7或win8系统时,经常会提示磁盘具有MBR分区表和GPT分区表,从而无法安装Windows,那么磁盘MBR分区表和GPT分区表是什么意思呢?MBR和GPT分区表有什么不同?下面跟小编一起 ...

  2. 使用Rust开发操作系统(UEFI基本介绍)

    UEFI基本介绍 关于UEFI BIOS UEFI介绍 引导管理 UEFI Image UEFI 应用程序 OS Loader UEFI运行时服务 调用约定 调用约定的数据类型 IA-32架构调用约定 ...

  3. 高通about.html 文件,高通平台UEFI有关介绍

    高通平台UEFI有关介绍 背景 我需要在高通平台上学习点亮LCD,目前通过同事在别的平台的配置代码,我已经将kernel部分的屏幕点亮了:剩余的工作量就在BP侧,也就是系统刚开机的那一段时间.在开发过 ...

  4. 【译】愿逝者安息,UEFI先驱——BIOS

    如果你在过去的三十多年里用过计算机,那么你应该对计算机中基本输入输出系统(BIOS)很熟悉.事实上它存在了这么长时间也暗示这它需要被取代了(计算机世界里很少有技术能三十多年不变).UEFI 正在慢慢的 ...

  5. Lesson 6.5Lesson 6.6.1Lesson 6.6.2 机器学习调参基础理论与网格搜索多分类评估指标的macro与weighted过程GridSearchCV的进阶使用方法

    Lesson 6.5 机器学习调参基础理论与网格搜索 在上一小节执行完手动调参之后,接下来我们重点讨论关于机器学习调参的理论基础,并且介绍sklearn中调参的核心工具--GridSearchCV. ...

  6. 新一代人工智能院士高峰论坛-视觉预训练大模型及其在智慧城市中的应用分论坛顺利举办

    2021年12月20日,新一代人工智能院士高峰论坛-视觉预训练大模型及其在智慧城市中的应用分论坛在深圳市人才研修院成功举办.  该论坛由鹏城实验室视觉智能研究所主办,邀请了企业界和学术界的技术大咖和资 ...

  7. 【论文深度研读报告】MuZero算法过程详解

    深度强化学习实验室 官网:http://www.neurondance.com/ 论坛:http://deeprl.neurondance.com/ 作者:饼干Japson(DeepRL-Lab研究者 ...

  8. AIGC的1000+篇文章总结

    AIGC的1000+篇文章总结 本文收集和总结了有关AIGC的1000+篇文章,由于篇幅有限只能总结近期的内容,想了解更多内容可以访问:http://www.ai2news.com/, 其分享了有关A ...

  9. DeepMind | 手撕MuZero算法「AI核心算法」

    注:耕智能,深耕AI脱水干货 作者: 饼干Japson   报道:深度强化学习实验室 转载请联系作者 前言 1 算法简介 1.1 背景 1.2 理解算法思想 2 模型图文讲解 2.1 MuZero中模 ...

  10. UEFI、BIOS、Secure Boot的关系和知识介绍

    从Windows 8操作系统时代开始,安装操作系统的方法也有了很大的改变,Windows 8采用了Secure Boot引导启动的方式,而不是过去Win XP和Win 7的Legacy启动方式,从而导 ...

最新文章

  1. LR11之web_reg_find文本检查点的使用
  2. php后台数据显示到前端,php,前端_怎么在javascript中得到后台数据?,php,前端,javascript,highcharts - phpStudy...
  3. 【Android 进程保活】应用进程拉活 ( 双进程守护 + JobScheduler 保活 | 成功率最高 | 推荐使用 )
  4. 【机器学习基础】Python机器学习的神器- Scikit-learn使用说明
  5. zincrby redis python_【Redis数据结构 序】使用redispy操作Redis数据库
  6. (转)Linux内核参数之arp_ignore和arp_announce
  7. JavaWeb结合七牛云存储搭建个人相册服务
  8. 怎样保护计算机连接线,一根网线把电脑烧了:雷雨天如何保护家电?
  9. 剪映专业版 下载与安装介绍
  10. JavaScript 存储Cookie
  11. 第一易,唯一难,为什么它是ofo、天学网的不二选择
  12. php环境配置详细教程,图文教程:php环境全部配置
  13. Java合并PDF文件方式
  14. UI 设计师不容错过的12款APP UI 交互设计
  15. echarts报表javascript插件简介
  16. 2021杭电多校第3场_HDU6975_Forgiving Matching
  17. 红亚太学链之区块链技术深度剖析第9章
  18. Linksys玩多了,来看看真正的Cisco~技术帖
  19. 计算机导论题目2020,计算机网络论文题目_
  20. 怎么看待员工上班迟到扣工资行为?程序员:加班补工资就行

热门文章

  1. 海康威视4200服务器显示资源不足,硬盘录像机提示“资源不足”是什么原因 -
  2. python分位点计算(正态分布,卡方分布,t分布,F分布)
  3. 12个优秀的开源UML工具
  4. 中古调式(调式音阶) 二
  5. Android 插桩入门
  6. 电子厂计算机维修周记,关于电子厂实习周记范文
  7. 用postman测试post接口的设置步骤,参数为json
  8. SPSS分析基础——T检验
  9. 【工程/物理光学(一)——光的电磁理论基础】
  10. 新手成为黑客,需要掌握电脑网络命令汇总