ARMv8 Firmware Architektur: Kernkomponenten und Boot Flow in Server Systemen

Seit seinem Debüt 2011 ist die ARMv8 Architektur in mobilen Geräten allgegenwärtig geworden. Prognosen von ARM Limited's CEO projizierten, dass ARMv8 Prozessoren bis 2020 bis zu 25 % des globalen Marktes erobern würden. Natürlich folgte Software Support, indem er Features und Prinzipien des lang etablierten ARM Ökosystems erbte.

In der Server-Arena unterscheidet sich die Landschaft jedoch markant. x86-basierte Server dominieren seit Jahrzehnten, während ARMv8 erst kürzlich begonnen hat, eine Nische in ausgewählten Enterprise-Segmenten zu besetzen. Die Neuheit von ARM in dieser Domäne, gekoppelt mit der späten Adaption Schlüsselstandards wie ACPI und UEFI, hat die Evolution seines Firmware Stacks geprägt.

Dieser Artikel bietet einen High-Level Überblick der Firmware Architektur, die ARMv8 Server Systeme antreibt. Er ist nicht exhaustiv, und Leser sollten beachten, dass neue Prozessor Releases unterschiedliche technische Lösungen einführen können, die aktualisierte Ansätze rechtfertigen.

Aktuelle Firmware Implementierungen für ARMv8 Server sind modular, was den Vorteil bietet, Komponenten über Server und Embedded Firmware wiederzuverwenden, während Änderungen isoliert werden. Abbildung 1 illustriert die Loading Sequence und Interaktionen zwischen Modulen.

Fig 1. Modul Loading und Interaction Flow. (Quelle: Auriga)

Boot beginnt mit der Initialisierung Low-Level Subsystems – RAM, Inter-Processor Communication, etc. – gehandhabt durch ein dediziertes Modul, das in EL3S Mode unmittelbar nach CPU Power-On läuft. Diese Komponente genießt höchste Privilegien und interagiert typischerweise nicht direkt mit dem Operating System.

Kontrolle wird dann an das ARM Trusted Firmware (ATF) Modul übergeben, ebenfalls in EL3S ausführend. ATF kann direkt vom Level-0 Loader oder indirekt via UEFI PEI Modul invokiert werden. Die ATF Chain besteht aus mehreren Stages, jeweils aktiviert an einem spezifischen Punkt im Boot Prozess.

Die erste Stage, BL1, konfiguriert Secure Hardware Resources. ARMv8's Hardware-basierte Isolation zwischen Trusted und Non-Trusted Memory mandiert, dass BL1 eine Secure Environment etabliert: es programmiert Memory und Cache Controller, designiert Trusted vs. Non-Trusted Zonen und setzt DMA Filtering Rules. Nur Devices mit matching Security Attributes können die entsprechenden Memory Regions zugreifen. BL1 baut auch die MMU Translation Tables und die Exception Vector Table, insbesondere den Secure Monitor Call (SMC) Handler, der Control an spätere Stages delegieren kann.

Sobald BL1 fertig ist, lädt es BL2 in RAM und übergibt Execution via ERET Instruction. BL2 läuft in EL1S, einem Reduced-Privilege Mode, der BL1 Data und Code vor accidental Modification schützt. Seine primäre Rolle ist, die verbleibenden Firmware Stages (BL3 Varianten) zu laden und Control an sie zu transferieren.

Die dritte Stage kann bis zu drei Sub-Stages umfassen, though BL3-2 oft weggelassen wird. BL3-1 ist der Trusted Runtime Code, mit dem das Operating System während Operation interagiert. Er enthält den SMC Handler und implementiert das PSCI Interface – Standard Calls für Power Management und Core Control – sowie Vendor-spezifische Extensions. BL3-2, falls present, operiert in EL1S und dient als Lightweight Monitor für Platform Events wie Timer Interrupts oder Peripheral Signals.

BL3-3 ist nicht Teil von ATF; es ist ein Non-Secure Image, das in EL2 Mode übernimmt. Typische Beispiele sind U-Boot oder eine UEFI Environment, beide Standard für Server Boot Flows.

Die ATF Initialisierungs-Sequenz ist in Abbildung 2 zusammengefasst.

Fig 2. ATF Modul Initialisierung. (Quelle: Auriga)