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.