|
The startup process involves firmware,
firmware interfaces, and an operating system. During startup, firmware
is the first code that runs. Firmware performs basic initialization of
the computer and provides the services that allow a computer to start
loading an operating system.
Platform firmware is implemented in motherboard-chipsets. All
computers—whether tablets, desktops, or laptops—have
motherboard-chipsets. There are many types of motherboard-chipsets, and
although older motherboard-chipsets might not be updatable, most newer
ones have updatable firmware. Chipset firmware is separate and different
from the computer’s underlying firmware interface.
Windows for the ARM processor architecture, also called Windows On
Arm (or simply WOA), is designed with platform firmware that is
implemented in a motherboard
chipset as well. With WOA though, the board is a series of silicon
layers packaged together in a very small form factor called a System on
Chip (SoC).
Firmware Interface Types and Boot Data
Every computer has firmware, yet it is the interface between that
firmware and the operating system that handles the startup process. The
way a firmware interface works and the tasks it performs depend on the
type of firmware interface. Currently, the prevalent firmware interfaces are:
-
Basic input/output system (BIOS) -
Extensible Firmware Interface (EFI) -
Unified Extensible Firmware Interface (UEFI)
A computer’s BIOS, EFI, or UEFI provides the hardware-level interface
between hardware components and software. Like chipsets themselves,
BIOS, EFI, and UEFI can be updated. Most technical documentation refers
to a computer’s firmware interface simply as firmware.
For example, documentation may specify to make “such and such a change
in firmware” or to “check firmware.” Technically, you make the change in
the firmware interface, and the firmware interface makes the change in
firmware.
UEFI is both a type of firmware interface and an industry standard.
UEFI, as a firmware interface, is modular and does not necessarily serve
the same purpose or provide the same functionality as BIOS or EFI.
UEFI, as a standard, is designed to provide extensible and testable
interfaces. For WOA, UEFI is the lowest layer of the system and as with
other chip architectures, UEFI provides the services necessary to load
the operating system. WOA also supports TPM for trusted boot and
hardware-based drive encryption.
It is also important to understand that BIOS, EFI, and UEFI work in
distinctly different ways. BIOS is based on x86, 16-bit, real-mode
architecture and was originally designed to get a computer started after
the computer was powered on. This is why BIOS performs
firmware-to-operating-system interfacing and platform initialization.
Regardless of the firmware interface type, Windows 8 uses a
pre–operating system boot environment. The boot environment is an
extensible abstraction layer that allows the operating system to work
with multiple types of firmware interfaces without requiring the
operating system to be specifically written to work with these firmware
interfaces. Within the boot environment, startup is controlled by using
the parameters in the boot configuration data (BCD) store.
All computers running Windows Vista and later have a BCD store. The BCD store is contained in a file called the BCD registry. The location of this registry depends on the computer’s firmware as follows:
-
On BIOS-based operating systems, the BCD registry file is stored in the \Boot\Bcd directory of the active partition. -
On EFI-based operating systems, the BCD registry file is stored on the EFI system partition.
Entries in the BCD store identify the boot manager to use during
startup and the specific boot applications available. The default boot
manager is the Windows Boot Manager. Windows Boot Manager controls the
boot experience and enables you to choose which boot application is run.
Boot applications load a specific operating system or operating system
version. For example, the boot application for Windows 8 is the Windows
Boot Loader. This allows you to boot BIOS-based and EFI-based computers
in much the same way.
Typically, you can press F8 or F12 during startup of the operating
system to access the Advanced Boot Options menu and then use this menu
to select one of several advanced startup modes, including Safe Mode,
Enable Boot Logging, and Disable Driver Signature Enforcement. These
advanced modes temporarily modify the way the operating system starts to
help you diagnose and resolve problems. However, they don’t make
permanent changes to the boot configuration or to the BCD store.
Boot Services, Run-Time Services, and Beyond
BIOS manages the preboot data flow between the operating system and
attached devices, such as the video adapter, keyboard, mouse, and hard
disk. When BIOS initializes a computer, it first determines whether all
attached devices are available and functioning, and then it begins to
load the operating system.
Over the years, these basic features of BIOS were expanded to encompass the following:
-
Boot services Refers to the collection of interfaces
and protocols that are present in the boot environment. The services at
a minimum provide an operating system loader with access to platform
capabilities required to complete the operating system boot. These
services are also available to drivers and applications that need access
to platform capabilities. Boot services are terminated after the
operating system takes control of the computer. -
Run-time services
Refers to the interfaces that provide access to underlying
platform-specific hardware, such as timers, that might be useful during
operating system run time. These services are available during the boot
process but also persist after the operating system loader terminates
boot services. -
Advanced Configuration and Power Interface (ACPI)
Refers to a table-based interface to the system board that enables the
operating system to implement operating system–directed power management
and system configuration. -
Services for System Management BIOS (SMBIOS)
Refers to a table-based interface that is required by the Wired for
Management Baseline (WMB) specification and used to relate
platform-specific management information to the operating system or to
an operating system–based management agent.
Generally, computers with BIOS use hard disks that have master boot
record (MBR) partitions. To break free of the 16-bit roots of BIOS,
Intel developed EFI as a firmware
implementation for its 64-bit Itanium-based processors. EFI is based on
x64, 64-bit, real-mode architecture. As with BIOS, EFI performs
firmware-to-operating-system interfacing, platform initialization, and
other functions. With the introduction of EFI, Intel also provided a new
table architecture for hard disks, called the GUID partition table (GPT).
As Intel began developing EFI, Intel developers and others around the
world began to recognize the need to break the tie between firmware
and processor architecture. This led to the development of UEFI. The
UEFI 2.0 specification was finalized in January 2006 and revised in
April 2011 as UEFI 2.3.1. The UEFI specifications define a model for the
interface between operating systems and platform firmware. The
interface consists of data tables that contain platform-related
information, as well as boot
and run-time service calls that are available to the operating system
and its loader. The interface is independent of the processor
architecture. Because UEFI abstracts the processor architecture, UEFI
works with computers that have x86, x64, ARM, or an alternative
architecture. As with EFI, computers with UEFI generally use hard disks
that have GPT partitions. However, UEFI doesn’t replace all the
functionality in either BIOS or EFI and can, in fact, be wrapped around
BIOS or EFI.
Note
REAL WORLD The UEFI 2.3.1
specification is over 2,200 pages long. To save you a tremendous amount
of reading, I’ve summarized its core capabilities here.
In UEFI, the system abstraction layer (SAL) is the firmware that
abstracts platform implementation differences and provides the basic
interface to all higher-level software. UEFI defines boot services and run-time services.
UEFI boot services include:
-
Event, timer, and task priority services that create, wait for,
signal, check, and close events; set timers; and raise or restore the
priority of tasks -
Memory allocation services that allocate or free memory pages, get memory maps, and allocate or free pooled memory -
Driver model boot services that handle protocol interfaces for
devices, open and close protocol streams, and connect or disconnect from
controllers -
Image services that load, start, and unload images -
Miscellaneous services that set watchdog timers, copy and set memory, install configuration tables, and perform cyclic redundancy checking (CRC) calculations
UEFI run-time services include:
-
Variable services that get, set, and query variables -
Time services that get and set time and get and set wakeup time -
Virtual memory services that set virtual address mapping and convert memory pointers -
Miscellaneous services that reset the computer, return counters, and pass information to the firmware
UEFI defines architecture-independent models for EFI-loaded images,
device paths, device drivers, driver signing, and secure boot. It also
defines the following:
-
Console support, which allows simple text and graphics output. -
Human Interface Infrastructure support, which describes the basic
mechanisms for managing user input and provides definitions for related
protocols, functions, and type definitions that can help abstract user
input. -
Media support, which allows I/O access to file systems, files, and media devices. -
Peripheral Component Interconnect (PCI), small computer system
interface (SCSI), and Internet small computer system interface (iSCSI)
bus support, which allows I/O access across a PCI, SCSI, or iSCSI bus,
as well as SCSI or iSCSI boot. -
Universal serial bus (USB) support, which allows I/O access over USB host controllers, USB buses, and USB devices. -
Compression support, which provides algorithms for compressing and decompressing data. -
ACPI table support, which allows installation or removal of an ACPI table. -
EFI byte code virtual machine support, which allows loading and executing EFI device drivers. -
Network protocol support, which defines the Simple Network Protocol
(SNP), Preboot Execution Environment (PXE), and Boot Integrity Services
(BIS) protocols. SNP provides a packet-level interface to network
adapters. PXE is used for network access and network booting. BIS is
used to check the digital signature of a data block against a digital
certificate for the purpose of checking integrity and authorization. PXE
uses BIS to check downloaded network boot images before executing them. -
Managed network protocol support, which defines the Managed Network
Service Binding Protocol (MNSBP) and the Managed Network Protocol (MNP).
These services allow multiple event-driven drivers and applications to
access and use network interfaces simultaneously. MNSBP is used to
locate communication devices that are supported by an MNP drive and
manage instances of protocol drivers. MNP is used by drivers and
applications to perform raw asynchronous network-packet I/O. -
Network addressing protocol support, which defines the following
protocols: Address Resolution Protocol Service Binding Protocol
(ARPSBP), Address Resolution Protocol (ARP), DHCPv4, DHCPv4 service
binding, DHCPv6, and DHCPv6 service binding. -
Miscellaneous network protocol support, which defines the following
protocols: virtual local area network (LAN) configuration, EAP/EAP
management, TCPv4, TCPv4 service binding, TCPv6, TCPv6 service binding,
IPv4, IPv4 service binding and configuration, IPv6, IPv6 service binding
and configuration, IPSec and IPSec2 configuration, FTPv4, FTPv4 service
binding, UDPv4, UDPv4 service binding, UDPv6, UDPv6 service binding,
Multicast TFTPv4, and Multicast TFTPv6.
Note
With WOA, ACPI is used for plug and play enumeration of devices
(touch controller, display, and so on) during boot and for power
management of devices outside of the SoC. Otherwise, there is no device
tree or ability to discover what is connected to a SoC or determine how
the SoC is connected.
To be clear, UEFI
is not designed to replace either BIOS or EFI. Although UEFI uses a
different interface for boot services and run-time services, some
platform firmware
must perform the functions that BIOS and EFI need for system
configuration and setup because UEFI does not do this. For this reason,
UEFI is often implemented on top of traditional BIOS and EFI, in which
case UEFI takes the place of the initialization entry points into BIOS
or EFI.
|
