基于 ARMv8 的固件系统架构

自 2011 年发布以来，ARMv8 处理器架构在移动设备市场上已经相当普遍。根据ARM Limited CEO的预测，到2020年这一代处理器的全球市场份额将达到25%。历史形成的基础设施的原则。

在市场的服务器领域观察到一种根本不同的情况。基于 X86 的服务器在这个领域占据主导地位已经有一段时间了，而 ARMv8 才刚刚找到它的出路（并且只进入特定的业务领域）。 ARM 市场的新颖性以及大多数公认的标准和规范（主要是 ACPI 和 UEFI）直到最近才适用于 ARM 系统这一事实已经在软件基础设施的发展上留下了印记。

本文重点概述基于 ARM 的服务器系统和处理器功能，并不声称是详尽的描述。作者还想提请读者注意这样一个事实，即所提供的数据可能很快就会过时——很快，新处理器将带来新的技术解决方案，这些解决方案可能需要采用不同的方法来实现软件基础架构。

首先，我们应该指出，当前 ARMv8 服务器系统固件的实现由几个相对独立的组件组成。这提供了许多优势，例如可以在服务器和嵌入式系统的固件中使用相同的组件，以及引入的更改的相对独立性。

那么，这些系统中使用了哪些模块和组件，它们的功能是什么？模块加载和交互的总体图表如图 1 所示。该过程从子系统的初始化开始，例如 RAM 和处理器间接口。在当前的实现中，这是在打开主 CPU 电源后立即由处于 EL3S 模式的单独模块执行的。因此，系统的这个组件具有最大可能的特权。它通常不直接与操作系统交互。

图 1. 模块的加载和交互。 （来源：御夫座）

之后，控制权转移到下一个组件，最常见的是 ARM 可信固件 (ATF) 模块，它以相同的模式执行。 ATF 控制可以直接从上一段中描述的 0 级加载程序传输，也可以通过实现 PEI（PreEFI 初始化）的特殊 UEFI 模块间接传输。 ATF由多个模块组成，在不同时间接收控制。

BL1 启动模块执行分配给安全处理器模式的平台部件的初始化。由于基于 ARMv8 的系统对可信和非可信资源（包括 RAM）使用硬件分离，BL1 模块准备了一个可以执行可信代码的环境。特别是，这种类型的初始化包括内存/缓存控制器的配置（可信和非可信区域通过这些设备中的寄存器编程来标记）和片上设备（与能源无关的内存控制器）的标记。此标记还引入了基于设备类型（受信任/非受信任）的 DMA 事务过滤。鉴于所有这些，内存写入/读取只能到/从安全设置与设备匹配的区域进行。可信环境的实现可能非常复杂；例如，它们可以包含一个单独的操作系统。但是，对此类实现的描述超出了本文的范围。

BL1 模块配置 MMU 地址转换表以及异常处理程序表，其中最重要的元素是安全监视器调用 (SMC) 指令的异常处理程序。此时，处理程序很小，实际上只能将控制权转移到加载到 RAM 中的图像上。运行时，BL1 模块将下一阶段 (BL2) 加载到 RAM 中并将控制权转移给它。 BL2 模块工作在 EL1S 模式下，权限降低。因此，使用“ERET”指令将控制权转移到该模块。

BL2 模块的目的是加载剩余的固件模块（BL3 部分）并将控制权转移给它们。降低的特权级别用于避免可能损坏内存中已有的代码和 EL3S 数据。这些部分的代码是通过使用SMC指令调用位于BL1阶段的EL3S代码来执行的。

ATF 加载和初始化的第三阶段可以由三个阶段组成，但第二阶段通常被省略。因此，实际上只剩下两个。 BL3-1 模块是通用软件（操作系统等）在运行时可访问的可信代码的一部分。该模块的关键部分是“SMC”指令调用的异常处理程序。模块本身有用于实现标准 SMC 调用的函数：实现标准 PSCI 接口的代码（旨在控制整个平台，例如启用/禁用处理器内核、平台范围的电源管理和重新启动）并且还处理供应商- 特定调用（提供有关平台的信息、管理嵌入式设备等）。

如上所述，BL3-2 模块的存在是可选的；它的代码（在模块的情况下）在 EL1S 模式下执行。通常，它充当平台运行期间发生的事件（来自某些计时器、设备等的中断）的专门服务/监视器

实际上，BL3-3 不是 ATF 模块，而是在非安全模式下执行的固件映像。它通常在 EL2 模式下进行控制，并代表类似于广为人知的 U-Boot 的引导加载程序或 UEFI 环境的映像，这是服务器系统的标准。

ATF模块初始化的总体图如图2所示。

图。 2. ATF 模块初始化。 （来源：御夫座）