2.1 Staged Architecture
The Minimum Platform Architecture defines a number of stages that are integral to the design and implementation of conformant firmware solutions. Stages define what code needs to be built, what functionality is required, what binary components are required at the FV and UEFI PI Architecture executables level, and what the system capabilities are available as a result of successfully executing through a firmware stage.
Stage |
Functional Objective |
Example Capabilities |
|---|---|---|
I |
Minimal Debug | Serial Port, Port 80, External debuggers Optional: Software debugger |
II |
Memory Functional | Basic hardware initialization including main memory |
III |
Boot to UEFI Shell | Generic DXE driver execution |
IV |
Boot to OS | Boot a general purpose operating system with the minimally required feature set. Publish a minimal set of ACPI tables. |
V |
Security Enabled | UEFI Secure Boot, TCG trusted boot, DMA protection, etc. |
VI |
Advanced Feature Selection | Firmware update, power management, networking support, manageability, testability, reliability, availability, serviceability, non-essential provisioning and resiliency mechanisms |
VII |
Tuning | Size and performance optimizations |
Table 4 Architecture Stages
The stages correspond well to bootstrapping a system and to developing a production-worthy solution. The stages are defined in order to detail the minimum items required. It is expected that there will be more required and more present than what is defined in this specification for an end product. The stages capture what is minimally required to support the strategic objectives of transparency and quality as well as the more tactical objectives of structure, consistency, cohesion, coupling, and compatibility. Note that the stages represent enabling steps, not necessarily the order of execution. For example, ACPI initialization necessary in Stage IV may be performed before Stage III would be considered complete. Further, the stages may not necessarily be strictly additive once enabling is complete. For example, the UEFI shell may not be required in the production firmware image based on product requirements, but it must have been enabled and therefore capable of being loaded in the final firmware if chosen by a firmware engineer supporting the firmware in the final production image.