Phase 1. During early initialization, the UEFI-compatible BIOS initializes some of the underlying components of the platform (such as CPU, chipset, and memory). This also includes establishing the UEFI infrastructure so that the common UEFI components (such as the UEFI configuration infrastructure) are available to be used by later phases of operation.

Phase 2. In the later phase, the BIOS starts to launch drivers (often located in add-in device option ROMs) that have configuration-related material associated with certain configurable devices. This configuration data is registered with the BIOS through something known as the Human Interface Infrastructure (HII) services. Between Phase 2 and 3 is usually when a local user would interact with the platform to configure it (picture a user at a BIOS setup menu).

Phase 3. The BIOS initialization is complete and the BIOS proceeds to launch the boot target (which is usually an operating system for most platforms).

Phase 4. The boot target is launched and running. For most platforms, this is the phase that the machine remains in for most of the time.

Step 1. The UEFI-compliant BIOS initializes like it normally does.

Step 2. The configuration step is usually based on some previously chosen settings that the user/administrator had previously applied to that device. These settings are stored in some nonvolatile location. During this step, the settings are typically read from the nonvolatile storage and the device is configured accordingly.

Step 3. The platform is running the operating system in this illustration and has some interaction with a remote administrator. The remote administrator requests some BIOS setting changes to occur on the platform and some agent proxies this request by a couple of methods:

–Capsules. The UEFI infrastructure supports an UpdateCapsule() service, which allows for an OS-present agent to call into the BIOS and communicate some configuration request, which will typically be acted upon across a platform reset. This is a very flexible method of enabling an acrossreset update since it can potentially allow for updates of both on-motherboard devices as well as third-party devices (which often use their own proprietary local nonvolatile storage). Platform behavior changes typically do not occur until the platform has reset and the hardware has then been reconfigured based on the desired settings.

–EFI Variable. The UEFI infrastructure provides abstractions to a platform nonvolatile storage service (that is, an EFI variable). This is primarily used by the motherboard devices and the setting requests can be directly established from the OS-present phase of operations. Platform behavior changes typically do not occur until the platform has reset and the hardware has then been reconfigured based on the desired settings.

Step 4. Once the remote configuration update request has been received and acted upon, the platform typically resets so that the boot timeline is restarted. It should be noted, though, that during this subsequent boot, the items that normally occur in Step 2 would still occur, but typically based on the aforementioned configuration updates in the current configuration settings.

Database Services. A series of UEFI protocols that are intended to be an inmemory repository of specialized databases. These database services are focused on differing types of information:

–Database Repository. This is the interface that drivers interact with to manipulate configuration-related contents. It is most often used to register data and update keyboard layout-related information.

–String Repository. This is the interface that drivers interact with to manipulate string-based data. It is most often used to extract strings associated with a given token value.

–Font Repository. The interface to which drivers may contribute font-related information for the system to use. Otherwise, it is primarily used by the underlying firmware to extract the built-in fonts to render text to the local monitor. Note that since not all platforms have inherent support for rendering fonts locally (think headless platforms), general purpose UI designs should not presume this capability.

–Image Repository. The interface to which drivers may contribute image-related information for the system to use. This is for purposes of referencing graphical items as a component of a user interface. Note that since not all platforms have inherent support for rendering images locally (think headless platforms), general purpose UI designs should not presume this capability.

Browser Services. The interface that is provided by the platform’s BIOS to interact with the built-in browser. This service’s look and feel is implementation-specific, which allows for platform differentiation.

Configuration Routing Services. The interface that manages the movement of configuration data from drivers to target configuration applications. It then serves as the single point to receive configuration information from configuration applications, routing the results to the appropriate drivers.

Configuration Access Services. The interface that is exposed by a driver’s configuration handler and is called by the configuration routing services. This service abstracts a driver’s configuration settings and also provides a means by which the platform can call the driver to initiate driver-specific operations.

Initialize hardware. The primary job of a device driver is typically to initialize the hardware that it owns. During this process of physically initializing the device, the driver is also responsible for establishing the proper configuration state information for that device. These typically include doing the following:

–Installing required protocols. Protocols are interfaces that will be used to communicate with the driver. One of the more pertinent protocols associated with configuration would be the Configuration Access protocol. This is used by the system BIOS and agents in the BIOS to interact with the driver. This is also the mechanism by which a driver can provide an abstraction to a proprietary nonvolatile storage that under normal circumstances would not be usable by anyone other than the driver itself. This is how configuration data can be exposed for add-in devices and others can send configuration update requests without needing direct knowledge of that device.

–Creating an EFI device path on an EFI handle. A device path is a binary description of the device and typically how it is attached to the system. This provides a unique name for the managed device and will be used by the system to refer to the device later.

Register Configuration Content. One of the latter parts of the driver initialization (once a device path has been established) is the registration of the configuration data with the underlying UEFI-compatible BIOS. The configuration data typically consists of sets of forms and strings that contain sufficient information for the platform to render pages for a user to interact with. It should also be noted that now that the configuration data is encapsulated in a binary format, what was previously an opaque meaningless set of data is now a well-known and exportable set of data that greatly expands the configurability of the device by both local and remote agents as well as BIOS and OS-present components.

Respond to Configuration Event. Once the initialization and registration functions have completed, the driver could potentially remain dormant until called upon. A driver would most often be called upon to act on a configuration event. A configuration event is an event that occurs when a BIOS component calls upon one of the interfaces that the driver exposed (such as the Configuration Access protocol) and sends the driver a directive. These directives typically would be something akin to “give me your current settings” or “adjust setting X’s value to a 5.”

Step 1. During driver initialization, install services on the controller handle.

Step 2. During driver initialization, discover the managed device. Create a device handle and then install various services on it.

Step 3. During driver initialization, configuration data for the device is registered with the HII database (through the NewPackageList() API) using the device’s device handle. A unique HII handle is created during the registration event.

Step 4. During system operation, when a configuration event occurs, the system addresses (through the Configuration Access protocol) the configuration services associated with the device.

Step 1. During driver initialization, install services on the controller handle.

Step 2. During driver initialization, discover the managed device(s). Create device handle(s) and then install various services on them.

Step 3. During driver initialization, configuration data for each device is registered with the HII database (through the NewPackageList() API) using each device’s device handle. A unique HII handle is created during the registration event.

Step 4. During system operation, when a configuration event occurs, the system addresses (through the Configuration Access protocol) the configuration services associated with the driver. In this example, the configuration services will be required to disambiguate references to each of its managed devices by the passedin HII handle.

Step 1. Remote administrator sends a query to a target workstation. This query could actually be a component of a broadcast by the administrator to all members of the network.

Step 2. Request received and an agent (possibly a shell-based one) proxies the request to the appropriate device.

Step 3. The agent responds based on interaction with the platform’s underlying configuration infrastructure.