ARM系统预引导固件的新机遇-UEFI

ARM处理器已经在智能手机市场占主导地位，并越来越成为整个嵌入式领域的主流。最近，ARM处理器也进军服务器领域，追求计算连续性。

然而，历史上，ARM系统没有一个预引导固件的标准。这使得每个设计都有自己独特的与所引导的操作系统紧密结合的模式。这种传统的方法意味着固件开发者必须保持完全不同的代码库，即使系统可能使用的外围设备(网络，SATA接口，USB控制器等)和整个设计功能集是相同的。传统的ARM设计依赖诸如UBoot，Redboot，或专有软件启动软件包。

如何有效地开发生产这些产品来满足快捷上市需求已成为一个挑战。很有必要用某种形式的融合固件基础设施来实现代码重用的最大化，使这些产品可在有限的工程资源条件下实现更快推上市场，并同时添加创新功能。

统一可扩展固件接口(UEFI)对ARM系统的预引导固件是一个新机遇。 UEFI负责定义操作系统和系统固件之间以及固件驱动程序和系统固件之间的接口。此外，UEFI的平台初始化(PI)负责定义固件到芯片之间和固件内部的接口。 UEFI是处理器架构无关。

ARM公司，苹果，惠普和微软的专家们一起确定了UEFI的ARM绑定。这样，使用UEFI就可以最大限度地实现不同设计间的代码重用，包括那些使用不同的处理器架构的设计。

历史

在UEFI之前，有EFI(可扩展固件接口)。EFI最初创立于1998年，为的是让使用英特尔安腾处理器的系统摆脱BIOS对设计大型计算机的束缚，例如，BIOS对原有8259中断控制器的依赖，仅有64K的IO端口空间，仅有192K的OptionROM执行空间，单一的PCI段组。所有这些都影响系统的可扩展性。我们也预见到将要遇到的2.2TB主引导记录(MBR)硬盘驱动器分区限制，并定义了新的GUID分区表(GPT)格式。

在摆脱束缚的同时，EFI还采用了一个模块化的，灵活的可扩展体系结构，并使用高层次的编程语言。创建EFI时就考虑到它应与处理器架构无关，当时就支持安腾，x86和一个与处理器无关的字节代码，叫EFI字节代码(EBC)。

EFI是一个英特尔公司拥有的规范定义操作系统和系统固件之间，以及设备引导驱动程序和系统固件之间的接口。英特尔还创建了“框架”来定义系统固件内部接口以使EFI的实现进一步模块化。

2005年，计算机行业决定组建UEFI论坛来规范EFI和“框架”所涵盖的接口。英特尔贡献了EFI和“框架”规范给UEFI论坛作为新的起点。名称从EFI变为UEFI(U为统一的缩写)标志着定义、推广和使用的任务从此落在业界的肩膀上。

Figure 1: The UEFI Forum

由UEFI论坛定义的第一个规范(UEFI 2.0)在AMD和英特尔的帮助下定义了x64处理器的绑定。 “框架”也演变成了平台初始化(PI)规范。UEFI的ARM绑定作为UEFI 2.3规范的一部分于2009年公布。

开源社区“tianocore.org”于2004年开始，采用BSD许可证。随着ARM绑定的公布，苹果和惠普向tianocore.org贡献了UEFI的参考实现，其中对Beagle Board(beagleboard.org)的一个实现，使硅片供应商可为他们的硬件提供UEFI的驱动程序。 ARM公司近日贡献了使用Cortex A9 多核处理器的Versatile Express参考平台的核心代码，以及

· 修复了ARM GCC工具链的构建环境

· ARM的RealView仿真底板代码的更新

· 新的包含ARM参考平台通用组件的ArmPlatformPkg

· 支持TrustZone控制器

· 支持多核

· 支持PL18x MMC卡控制器

· 一个特制的启动设备选择BDS库以支持直接启动Linux

有关在ARM上实现UEFI的优越性和UEFI论坛组织结构的详细说明，请见下回分解。

现在我将探讨它，特别是在ARM的系统上的优越性。我也会更详细地描述UEFI论坛的组织结构。优越性

尽管现有的ARM预引导固件并没有BIOS的束缚，使用UEFI标准对ARM预引导固件仍有很多优越性。 OEM / ODM厂商一直在试图降低开发成本。代码共享是在预引导固件领域实现这目标的一种方式。

ARM和x86都注重计算连续性，UEFI不仅使得在ARM产品之间或在x86产品之间代码共享，还可以让代码在不同处理器架构的产品之间共享。产品可以共享外围设备(网络，SATA，USB控制器等)，以及众多的设计功能集。

图2显示了从x86到ARM的一个移植有99.42%的代码不需要更改。

图2: ARM移植中添加和更改的程序行数

模块化的UEFI技术还可以使芯片厂商能够为自己的硬件提供驱动程序。这使得OEM / ODM厂商能够灵活地使用来自不同供应商的模块，扩大了选择余地。

UEFI在ARM的实现提供了真正独立于操作系统的启动解决方案，而其他大多数现有的ARM启动解决方案(UBoot，小内核等)是与他们的支持操作系统相耦合的