White Paper John MacInnis Implementing Corporation – ECG Technical Marketing Engineer Firmware on Embedded Intel® Architecture Designs Intel® Architecture Firmware Design Guidelines

January 2009

321072 ® Implementing Firmware on Embedded Intel Architecture Designs

Executive Summary

Embedded Intel® architecture designs include a firmware stack which initializes CPU cores, memory, IO, peripherals, graphics and provides runtime support for operating systems. This paper gives a high-level overview of a number of firmware technologies to be considered on Embedded Intel® architecture designs. Many links to external references are included. Because of its inherent complexity and number of technologies to be considered, the general recommendation is made that OEM Embedded Intel® architecture firmware design teams consider starting with an available solution from an IBV, ISV or the Intel® ecosystem and build on it to meet their particular product requirements.

There are a number of firmware technologies to be considered on embedded Intel® architecture designs.

2 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

Contents

Business Challenge ...... 4

Solution ...... 4

Essentials of Embedded Intel® architecture (Boot Loader) Firmware...... 5

Intel® Architecture Functional Block Diagram ...... 6

The History and Evolution of BIOS...... 7 A brief history...... 7 Limitations of legacy BIOS...... 8 The Birth of the Intel® Platform Innovation Framework for EFI...... 8 What is UEFI? ...... 9 UEFI PI Firmware Phases ...... 11 UEFI Interoperability Validation Activities...... 12 Advanced Configuration and Power Interface (ACPI) ...... 13

System Management Mode (SMM) ...... 15

Independent BIOS Vendors (IBVs) ...... 15

Embedded Independent Software Vendors (ISVs)...... 16

Boot Time Optimization ...... 16

Legacy Free ...... 17

Advanced IBV BIOS Features...... 17

Intel Advanced Firmware Features ...... 21

Industry Standards: Organizations and Specs ...... 21

Conclusion ...... 22

Intel® Architecture Firmware Acronyms...... 23

Intel® architecture Firmware Terminology ...... 24

321072 3 ® Implementing Firmware on Embedded Intel Architecture Designs

Business Challenge

A firmware solution is essential for embedded Intel® architecture designs. For customers migrating to Intel® architecture from non-Intel® architecture designs, the first business challenge is the decision to make or buy. Customers must also decide if their requirements include a full-BIOS solution or a simpler Boot Loader.

Embedded Intel® architecture designs must include a firmware stack which initializes the platform hardware and provides support for the Operating System. Intel® architecture-based desktop, notebook and server products typically use a full BIOS implementation which is either provided by an Independent BIOS Vendor (IBV) or an in-house BIOS development team. Embedded system designs have significant cost versus feature requirements and time to market considerations. For many embedded products (e.g. KIOSK or Point of Sale) a full BIOS managed either through an ODM or directly with an IBV is the most effective solution. For more specialized single-purpose embedded products the benefits of full BIOS are reduced. Design simplicity, faster boot times, optimized footprint and BOM cost considerations are significant and requirements often dictate a minimal firmware implementation commonly referred to as a Boot Loader. Embedded customers migrating from non-Intel® architecture designs may find a simple Boot Loader solution more similar to non-Intel® architecture design solutions versus a full BIOS implementation.

Solution

Determine the cost-benefits of full BIOS on the design. Understand the benefits of an IBV engagement. Understand the minimal requirements of a Boot Loader and development costs. Decide whether to purchase firmware as an ODM BOM cost item, use an IBV, ISV develop or outsource a boot loader from scratch or leverage an open source and/or Intel ecosystem solution.

Note that developing and maintaining an in-house firmware or BIOS solution is generally only tenable by a handful of the largest OEM organizations. For most solutions it is advisable to leverage an existing solution and then apply engineering resources to tune, optimize or integrate value-add components into the design. Firmware or BIOS solutions are available through IBVs, ISVs and the Intel ecosystem.

4 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

Essentials of Embedded Intel® architecture (Boot Loader) Firmware

Every embedded Intel® architecture design must include a firmware stack which initializes CPU cores, memory, IO, peripherals and graphics. A fully featured PC compatible solution is engineered to perform complete discovery and initialization algorithms which can be undesirable in an embedded system. Unlike a PC, in an embedded design, the level of initialization is done in a closed system and therefore can be optimized for faster pre-boot execution and smaller footprint.

In addition to pre-boot initialization, runtime support must be provided. The level and architectural protocols of runtime support is determined by the target OS or RTOS. Runtime support is typically handled by a combination of Advanced Configuration and Power Management Interface (ACPI), interrupt services and API function calls.

In a minimal Boot Loader implementation the following basic steps are executed as shown in Figure 1:

Figure 1. Simple Firmware Flow

321072 5 ® Implementing Firmware on Embedded Intel Architecture Designs

Intel® Architecture Functional Block Diagram

In addition to a firmware flow chart, it is useful for the firmware designer to refer to functional block diagrams. Firmware components are responsible for initializing each of the block functions seen in the figure below. Firmware will generally perform basic and advanced initialization/configuration of the functional blocks during boot. During runtime, firmware components work in cooperation with the OS to manage dynamic configuration changes and power management of each functional block.

• CPU support includes micro-code upload, CPU register configuration and power management • The Graphics and Memory Controller Hub (GMCH) sometimes referred to as the north-bridge, controls main system memory and integrated graphics engine. Intel generally supplies Memory Reference Code (MRC) and video BIOS or graphics drivers on a per chipset basis to licensed developers. • The I/O Controller Hub sometimes referred to as the south-bridge, controls I/O buses and devices. Algorithms and code to support functions of the I/O Controller Hub are designed to conform to industry specifications such as PCI-Sig and USB.

6 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

Figure 2. Intel® Architecture Functional Block Diagram

The History and Evolution of BIOS

A brief history

It is commonly known that the Intel® architecture BIOS industry began in 1984 when Compaq* reverse engineered the IBM* PC/AT BIOS. The BIOS of that day was probably more like a boot loader than the full featured BIOS of today. Today most of the PC BIOS market share is captured by a few Independent BIOS Vendors (IBVs) or in-house BIOS implementations from a few large OEMs.

In early years BIOS implementations went through many architectural improvements and redesigns. Later, BIOS innovation tended more toward the adoption and integration of new industry-standard configuration and power management technologies.

321072 7 ® Implementing Firmware on Embedded Intel Architecture Designs

Limitations of legacy BIOS

Over the years, many new configuration and power management technologies were integrated into BIOS implementations as well as support for many generations of Intel® architecture hardware. However certain limitations of BIOS implementations such as 16-bit addressing mode, 1 MB addressable space, PC AT hardware dependencies and upper memory block (UMB) dependencies persisted throughout the years. The industry also began to have need for methods to ensure quality of individual firmware modules as well as the ability to quickly integrate libraries of third party firmware modules into a single platform solution across multiple product lines. These inherent limitations and existing market demands opened the opportunity for a fresh BIOS architecture to be developed and introduced to the market. The UEFI specifications and resulting implementations have begun to effectively address these persisting market needs.

One of the critical maintenance challenges for BIOS is that each implementation has tended to be highly customized for the specific motherboard on which it is deployed. Moving component modules across designs typically requires significant porting, integration, testing and debug work. This is one of the market challenges the UEFI architecture promises to address.

The Birth of the Intel® Platform Innovation Framework for EFI

The original motivation for EFI came during early development of the first Intel-HP Itanium systems in the mid-1990s. PC BIOS limitations (16-bit processor mode, 1 MB addressable space, PC AT hardware dependencies, etc.) were seen as clearly unacceptable for the larger server platforms which utilized Intel® Itanium Processors.

The EFI specification 1.02 was released by Intel on December 12, 2000.

The EFI specification 1.10 was released by Intel on December 1, 2002. It included the EFI driver model as well as several minor enhancements to 1.02.

In 2007, Intel contributed this specification to the UEFI Forum, which is now responsible for its development and promotion. EFI was renamed to Unified EFI (UEFI) to reflect this. Most documentation uses both terms interchangeably.

The UEFI Forum released version 2.1 of the UEFI specification on January 7, 2007. As of March 2007, it is the latest publicly available specification. It added and improved cryptography, network authentication, and the User

8 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

Interface Architecture (Human Interface Infrastructure in UEFI).” - http://www.logic.nl/Products/Technology/BIOS-and-EFI.aspx

Intel's implementation of EFI, is officially called the Platform Innovation Framework for EFI (or just "the framework"). It is an open source project which promotes and encourages adoption of UEFI technology for Intel based platforms.

A presentation on optimizing Framework boot times is available at the following link:

Intel Framework Customization for Optimized Platform Boot Initialization

San Francisco 2008 IDF Presentation Session ID: EFIS002

What is UEFI?

Formed in 2005, the Unified EFI Forum, Inc. is a Washington non-profit corporation whose goal is to forward the technical advancement of the IT industry through the development and promotion of a set of Unified Extensible Firmware Interface (UEFI) standard specifications. The Forum is governed by a board of directors from eleven promoter companies: AMD*, AMI*, Apple*, *, HP*, IBM*, Insyde*, Intel*, *, * and Phoenix*. In addition, there are over 120 contributor and adopter members.

UEFI specifications include advances in Intel® architecture firmware over previously existing BIOS technologies and remove some technical barriers. It is important to note that not all pre-existing BIOS technology has been abandoned or replaced. UEFI specifications include and build on many pre- existing BIOS technologies such as ACPI, and SMBIOS as only two of many examples.

Today, over 130 companies have joined the UEFI forum and have integrated UEFI capability into their products including all the major BIOS vendors. From a market perspective, it is best to view the adoption of UEFI technology as a major industry-wide advancement in BIOS technology.

The UEFI Forum is responsible for:

• Unified Exensible Firmware Interface (UEFI) specification • Platform Inititaliazation Interface (PI) specifications

The UEFI specification defines interfaces between OS, add-in firmware drivers and system firmware.

321072 9 ® Implementing Firmware on Embedded Intel Architecture Designs

• Operating systems and other high-level software should ONLY interact with interfaces and services defined by the UEFI specification • GUID Partition table • Open source Shell Environment • Human Interface Infrastructure (HII)

The UEFI Platform Initialization (PI) specifications define internal firmware implementation standards:

• Defines interoperability standards between firmware components from different providers • All interfaces and services produced and consumed by firmware only • Includes the EFI Byte Code (EBC) specification which defines an interpretive layer for portable component drivers

Figure 3. UEFI ‘Green H’ Block Diagram

TCG EFI Platform Specifications are created in partnership with the Trusted Computing Group. The TCG EFI specifications define a standard interface to the Trusted Platform Module (TPM) on an EFI/UEFI platform and the requirements for measuring boot events into TPM Platform Configuration Registers (PCRs) and adding boot event entries into the TCG Event Log.

10 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

UEFI PI Firmware Phases

The boot flow for UEFI based firmware is conceptualized in the form of six philosophical phases, see Figure 4. A brief overview is presented here. For complete information see the PI specifications at www.uefi.org.

The Security (SEC) phase is the first phase and is responsible for the following:

• Handling all platform restart events • Creating a temporary memory store • Serving as the root of trust in the system • Passing handoff information to the PEI Foundation

The PEI phase will initially operate leveraging only on-processor resources, such as the processor cache as a call stack, to dispatch Pre-EFI Initialization Modules (PEIMs). These PEIMs are responsible for the following: • Initialize some permanent memory complement • Describe the memory in Hand-Off Blocks (HOBs) • Describe the firmware volume locations in HOBs • Pass control into the Driver Execution Environment (DXE) phase

The PEI phase is intended to be the thinnest amount of code to achieve the ends listed above. As such, any more sophisticated algorithms or processing should be deferred to the DXE phase of execution.

The state of the system at the end of the PEI phase is passed to the DXE phase through a list of data structures called Hand-Off Blocks (HOBs). HOBs and the HOB list are created during the PEI phase. The HOB list is passed to and consumed by the DXE phase.

The Driver Execution Environment (DXE) phase is where most of the system initialization is performed. Pre-EFI Initialization (PEI), the phase prior to DXE, is responsible for initializing permanent memory in the platform so that the DXE phase can be loaded and executed.

321072 11 ® Implementing Firmware on Embedded Intel Architecture Designs

Figure 4. UEFI Firmware Phases

In the Boot Device Select (BDS) phase, the Boot Dispatcher is responsible for determining what to load and any interactions with the user that may be required to make such a decision. Much of the behavior of the boot manager is left up to the firmware developer to decide and design. Likely implementation options might include console interfaces, integrated platform management of boot selections, possible knowledge of internal applications or recovery drivers that may be integrated into the system.

In the Transient System Load (TSL) phase, UEFI images can contain applications that provide transient serviced to the system. Examples include a utility to create partitions or utilities to perform and log extended diagnostics. A system partition can be used to support data files, such as error logs, that can be defined and used by various OS or system firmware components.

The primary purpose of Runtime phase services is to abstract minor parts of the hardware implementation of the platform from the OS. Runtime service functions are available during the boot process and also at runtime, including the time that an operating system is running.

UEFI Interoperability Validation Activities

One of the most important and exciting aspects of new industry-standard technologies is when ISVs, IBVs, hardware, component vendors OEM and ODMs get together to verify that independently designed components all work together in order to build comprehensive computer systems. UEFI.org

12 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

and its sponsor members have held many plug-fest or interoperability events. These events will continue to occur until the technology is fully mature. For more information see http://www.uefi.org.

Advanced Configuration and Power Interface (ACPI)

First published in 1999, the Advanced Configuration and Power Interface (ACPI) specification is an open industry specification co- developed by Hewlett-Packard*, Intel, Microsoft*, Phoenix, and Toshiba*.

The ACPI specification was developed to establish industry common interfaces enabling robust operating system (OS)-directed motherboard device configuration and power management of both devices and entire systems. In compliant systems, ACPI is the key element in operating system- directed configuration and Power Management (OSPM).

ACPI evolves a pre-existing collection of power management BIOS code. Advanced Power Management (APM) application programming interfaces (APIs), PNPBIOS APIs, Multiprocessor Specification (MPS) tables and so on into a well-defined power management and configuration interface specification. ACPI is a key component of UEFI specifications.

ACPI specifications define ACPI hardware interfaces, ACPI software interfaces and ACPI data structures. The specifications also define the semantics of these interfaces. Although it addresses both software and hardware and how they must behave, ACPI is not a software specification and it is not a hardware specification. Instead, ACPI is an interface specification comprised of both software and hardware elements.

321072 13 ® Implementing Firmware on Embedded Intel Architecture Designs

Figure 5. ACPI System Architecture

OS-directed Power Management Operating System Kernel ACPI Driver / AML Interpreter

Firmware ACPI Tables

ACPI Platform Hardware Registers

Firmware providers write definition blocks using the ACPI Control Method Source language (ASL) and operating systems use an ACPI Control Method Language (AML) interpreter to produce byte stream encoding.

// ASL Example DefinitionBlock ( "forbook.aml", // Output Filename "DSDT", // Signature 0x02, // DSDT Compliance Revision "OEM", // OEMID "forbook", // TABLE ID 0x1000 // OEM Revision ) { // start of definition block OperationRegion(\GIO, SystemIO, 0x125, 0x1) Field(\GIO, ByteAcc, NoLock, Preserve) { CT01, 1, }

Scope(\_SB) { // start of scope Device(PCI0) { // start of device PowerResource(FET0, 0, 0) { // start of pwr Method (_ON) { Store (Ones, CT01) // assert power Sleep (30) // wait 30ms } Method (_OFF) { Store (Zero, CT01) // assert reset# } Method (_STA) { Return (CT01) } } // end of power } // end of device } // end of scope } // end of definition block

14 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

System Management Mode (SMM)

System Management Mode (SMM) provides the firmware designer with a very powerful capability especially when noted that ACPI control methods can be used to trigger SMIs during system runtime. Intel’s SMM provides the system designer with means of building software-controlled features into a system at the hardware/firmware level, making them transparent to operating system and application software. The SMM architecture includes the following elements.

• System Management Interrupt (SMI#) for hardware interfacing • Dedicated and protected memory space (SMRAM) for SMI handler code and CPU state data with a status signal (SMIACT#) for the system to decode access to the memory space • RESUME (RSM) instruction for exiting SMM • I/O Restart, for transparent power management of I/O peripherals

SMRAM space provides a memory area that is available for the SMI handlers and code and data storage. This memory resource is protected and normally hidden from the system OS so that the processor has immediate access to this memory space upon entry to SMM.

Independent BIOS Vendors (IBVs)

From an engineering cost perspective, only very large OEMs and ODMs find it practical to develop and maintain their own firmware. A practical approach for most embedded projects is to begin by contracting firmware through an ODM if you are using one or directly through an IBV. This approach is generally cost effective and allows your engineering resources to focus on your own value add components.

Below are companies with specific expertise developing and deploying Intel® architecture firmware technology commonly referred to as BIOS. The value of working with these companies is leveraging their many years of expertise. Despite the industry’s best efforts, not everything in an open architecture world gets documented, especially when it comes to firmware support of operating systems. Over many years of experience, much of the ‘trial and error’ the IBVs have built up a wealth of knowledge which is stored in their code bases, engineers’ heads and sometimes their documentation. The IBVs know from experience how to bring up Intel® architecture platforms and support multiple operating systems. All of them have direct relationships with Intel and multiple operating system vendors and can save a lot of time otherwise spent in the lab figuring out basic undocumented OS-BIOS interaction.

321072 15 ® Implementing Firmware on Embedded Intel Architecture Designs

The following vendors are participants in uefi.org activities and offer legacy BIOS products, UEFI compliance and boot loaders.

• Inc.* • Insyde Software Corp.* • Nanjing Byosoft Co.,Ltd.* • , LTD.* Embedded Independent Software Vendors (ISVs)

Embedded operating system vendors (or Independent Software Vendors (ISVs)), have Intel® architecture firmware and board-support package (BSP) experience and can offer solutions. For those who have previously been working with non-Intel® architecture designs, the advantage of working with one of these companies is that the technical and business model should be familiar making a transition to Intel® architecture even easier. The ISVs have direct relationships with Intel and can provide a high level of support.

• Green Hills provides a comprehensive set of development tools for Intel® Architecture applications • Lynuxworks offers custom and pre-configured BSPs for Intel® architecture embedded systems • MontaVista offers many Linux BSPs for Intel products • QNX promotes a ‘BIOS-less’ approach to Intel® architecture through their Initial Program Loader (IPL) and specializes in fast-boot. • WindRiver has expertise with VxWorks and Intel® Architecture designs Boot Time Optimization

Whether you use a UEFI implementation, legacy BIOS or a hybrid the system generally must be tuned for optimized boot speed. A generic legacy BIOS or UEFI BIOS is designed to enable dynamic hardware configuration and multiple operating systems. It may also include diagnostic routines. Optimizing for boot speed means implementing trade-offs in terms of eliminating or restricting configuration, enumeration and discovery algorithms flexibility. Ultimately, you should be able to arrive at equivalent boot times regardless of whether you use a legacy BIOS, a UEFI-based BIOS or a Boot Loader with BSP.

16 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

A presentation on optimizing Framework boot times is available at the following link.

Intel Framework Customization for Optimized Platform Boot Initialization

San Francisco 2008 IDF Presentation Session ID: EFIS002

Legacy Free

In the PC industry, the term ‘Legacy Free’ typically refers to systems built without a standard SIO (serial/parallel comm ports, floppy drive) or PS2 Keyboard controller. Building Legacy Free systems is not always a trivial matter because market demand often includes hard requirements that legacy free systems operate in legacy software environments. For example, an operating system such as DOS relies on Port 60/64h legacy keyboard mouse controller which is not present in a legacy-free system using a USB keyboard/mouse. In this case legacy emulation must be performed at the firmware level in order for the legacy-free system to be compatible in a legacy environment.

Advanced IBV BIOS Features

The following features are typically found in a full featured BIOS implementation. The combined feature set offers system flexibility, manageability and compatibility with a wide range of open architecture hardware and software.

Table 1. Advanced BIOS Features

Feature Description

1394 Also known as FireWire, it is the IEEE 1394 Serial Bus standard.

Third party Option ROM or driver IBVs can provide standard methods for integrating 3rd support party driver support.

ACPI The Advanced Configuration & Power Interface establishes industry-standard interfaces enabling OS-directed configuration, power management, and thermal management of computing systems.

ASF The Alert Standard Format specification is maintained by the Distributed Management Task Force (DMTF) and is used in concert with other technologies to enable remote system manageability.

321072 17 ® Implementing Firmware on Embedded Intel Architecture Designs

Feature Description

ATA/UDMA Interface standards for the connection of storage devices such as hard disks, solid state drives, and CD-ROM drives.

Binary Editors Binary utilities to change certain components of the BIOS or firmware image without the need for source code. Examples include splash screen and Option ROM swap, and CPU micro codes.

BIOS Setup Onboard BIOS setup interfaces for end user or administrator tuning of system parameters. Can also include redundant capability for user backup or persistent storage of factory defaults.

Built-in debug capability Diagnostics, tools and techniques for debugging and deploying BIOS/UEFI firmware. IBV products often include built in debug engines and diagnostic utilities.

Configuration settings Onboard BIOS setup interfaces for end user or administrator tuning of system parameters. Can also include redundant capability for user backup or persistent storage of factory defaults. Programmatic configuration parameters are also available to enable motherboard configuration options such as PIRQ routing and GPIO.

Crisis Recovery Provides methodology and tools to recover the BIOS or firmware in case of catastrophic failure.

Diagnostics Hardware diagnostics integrated into BIOS POST or diagnostic utilities which can run either pre-boot or as OS- present applications.

Disk Emulators (ROM, RAM, Creation of virtual drives which appear to the operating FLASH) system as an ordinary disk drive.

Downstream support tools for IBVs can provide re-distribution licenses for downstream binary configuration tool and utility distribution to VARs and System Integrators. Often useful for small configuration changes which do not require firmware architecture expertise nor access to source code.

Dynamic configuration Support for dynamically changing hardware configurations typical in client PC and server systems.

Experience and support IBVs have been in the business many years and have achieved a high-level of expertise and know how which can be leveraged to control design and deployment engineering costs.

Flash Flash utilities which can run natively, in pre-boot or OS- present applications. Used to update the BIOS or firmware or write data to specific regions of the Flash chip on board the platform without the need for special programming hardware.

Graphical Boot Menu (‘desktop’) GUI boot select menu.

18 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

Feature Description

Hot-Plug support Enables the insertion and removal of adapter cards without turning off the platform or rebooting the operating system.

HTML Browser Browser technology for setup and boot screens.

Hyper-Threading Hyper-Threading technology enables thread-level parallelism in multi-core systems.

Integrated TCP Protocol Stack The Internet Protocol Suite (commonly TCP/IP) is the set of communications protocols used for the Internet and other similar networks.

IPMI The Intelligent Platform Management Interface (for server management) defines a standardized abstracted, message-based interface to intelligent platform management hardware as well as standardized records for describing platform management devices and their characteristics.

Legacy Free A legacy-free hardware system is one that does not include ISA slots or devices, legacy floppy disk controller (FDC), PS/2, serial, parallel or game ports. BIOS must make provisions for legacy-free systems to be compatible in legacy software installations such as DOS.

Localization Integrated language translations.

Microsoft WHEA Windows Hardware Error Architecture provides a common infrastructure for handling hardware errors on Windows platforms.

Multiple Boot Options (SATA, IDE, Capability to boot from essentially any storage device USB, CDROM, LAN, Floppy) available.

NUMA Non-Uniform Memory Access In NUMA platforms, memory access time is not uniform across all the CPUs in the system and depends on the memory location relative to a processor. System software tries to minimize the access times, by allocating the process memory on the node that is closest to the CPU that the process is running on.

OS/RTOS loader All BIOS vendors typically support multiple Operating Systems and Real-Time Operating Systems and have built up expertise in this area.

PAE (>4GB RAM) Physical Address Extension is a technique used in IA32 systems to access up to 64GB of physical memory and x64 systems to access up to 1024GB of physical memory.

PCI-Sig BIOS products typically include algorithms to support robust PCI-Sig specification compliance including PCI, PCI- X, PCIe, ExpressCard and PCI OpROM.

Provisioning Side-band capability to provision bare-metal systems.

321072 19 ® Implementing Firmware on Embedded Intel Architecture Designs

Feature Description

PXE (Network Boot) The Preboot eXecution Environment (PXE) is an open industry standard developed by a number of software and hardware vendors. It allows the client system to boot from a network in order to access management and support features. PXE is part of the Wired for Management (WfM) specification. http://www.intel.com/design/archives/wfm/

Real Time System Monitor Error logging and reporting of system health which can be monitored remotely.

Serial Console Redirection Often used to access integrated debug engines and/or direct screen output of headless devices to a remote system.

SMBIOS The System Management BIOS specification is maintained by the DMTF and addresses how motherboard and system vendors present management information about their products in a standard format.

Splash Screen (animation and Splash screens and customization utilities for OEM sound) branding.

Splash Screen swap (LOGO Binary utilities to change the Splash screen. These are change) often distributed with motherboard products to downstream VARS and System Integrators to use for branding purposes.

TCG/TPM The Trusted Computing Group develops open standards for trusted computing building blocks and software interfaces. The Trusted Platform Module (TPM) is a microcontroller that stores keys, passwords and digital certificates. The TPM is typically is affixed to the motherboard.

Tools IBVs typically distribute a menu of tools and utilities which are useful in debugging, deployment maintenance and support or platform firmware images.

UEFI/PI Unified Extensible Firmware Interface Platform Initialization

User Level Security Security features integrated directly into the BIOS or firmware setup engine.

Visual programming tools Integrated Developer Environments to help reduce manual engineering tasks and enhance ease of use for IBV products.

20 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

Intel Advanced Firmware Features

Intel provides advanced BIOS or firmware features which cooperate with hardware and can be integrated into any BIOS or firmware solution. The following table lists a few examples of firmware feature components.

Table 2. Intel® Advanced BIOS/Firmware Features

Feature Description

VPro Techologies Hardware-assisted security and manageability capabilities. • AMT • Intel® Active Management VT • Technology (AMT) enables secure • TXT remote platform applications. • Intel® Virtualization Technology (VT) enables hardware-assisted virtualization.

• Intel® Trusted Execution Technology (TXT) is a set of hardware extensions to CPU and chipsets with software to enable platform security functions.

Intel SpeedStep® Technology and Enhanced Intel SpeedStep® Technologies enable Intel SpeedStep® Technology advanced thermal and power management control through dynamic switching of operating frequency and input voltage.

Industry Standards: Organizations and Specs

• Advanced Configuration and Power Interface • Distributed Management Task Force • PCI-SIG • Trusted Computing Group

The Trusted Computing Group (TCG) is a not-for-profit industry-standards organization with the aim of enhancing the security of the computing environment in disparate computer platforms. TCG was formed in spring 2003 and has adopted the specifications developed by the Trusted Computing

321072 21 ® Implementing Firmware on Embedded Intel Architecture Designs

Platform Alliance (TCPA). The distinguishing feature of TCG technology is arguably the incorporation of “roots of trust” into computer platforms.” – TCG Architecture Overview Specification Revision 1.4, August 2007

Trusted Computing as defined by TCG relies on establishing Trusted Building Blocks and creating a chain of trust through levels of software. Roots of Trust are components that must be trusted because misbehavior might not be detected. There are commonly three Roots of Trust in a trusted platform; aroot of trust for measurement (RTM), root of trust for storage (RTS) and root of trust for reporting (RTR).

Typically in platform implementations containing a Trusted Platform Module (TPM) the platform firmware is responsible for initializing the TPM and establishing a core root of trust for measurement (CRTM). The CRTM is the instructions executed by the platform when it acts as the RTM.

• T13 • Unified Extensible Firmware Interface Forum • Universal Serial Bus • Microsoft Debug Port Spec • Microsoft Simple Boot Flag Spec • Multiprocessor Specification • SMBIOS • SMBus Specifications Conclusion

There are many technologies to consider when implementing Embedded Intel® architecture firmware. The paper gives a high-level overview of several key technologies and references to go learn more about them.

Because of its inherent complexity and number of technologies to be considered and from an engineering cost perspective only very large OEM and ODMs find it practical to develop and maintain their own firmware. If your company falls in this category then you probably already have plenty of expertise, direct support from Intel and Operating System Vendors or perhaps you are running a proprietary RTOS.

A practical approach for most embedded projects is to begin by contracting firmware through an ODM if you are using one or directly through an IBV. This approach is generally cost effective and allows your engineering resources to focus on your own value add components.

22 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

Starting solutions are available from IBVs, ISVs and the Intel® ecosystem. Start there and build on the design to meet your particular product requirements.

Intel® Architecture Firmware Acronyms

ACPI Advanced Configuration and Power Interface APM Advanced Power Management ASL ACPI Source Language ATA Advanced Technology Attachment ATAPI Advanced Technology Attachment Packet Interface BBS BIOS Boot Specification BIOS Basic Input/Output System EFI Extensible Firmware Interface MASM Microsoft Macro Assembler PAE Physical Address Extension PCI Peripheral Component Interconnect PnP Plug and Play PXE Preboot eXecution Environment SATA Serial ATA SMBIOS System Management BIOS SMBus System Management Bus TCG Trusted Computing Group TPM Trusted Platform Module UDMA Ultra Direct Memory Access UEFI Unified Extensible Firmware Interface USB Universal Serial Bus

321072 23 ® Implementing Firmware on Embedded Intel Architecture Designs

Intel® architecture Firmware Terminology

EFI-BIOS: Used to refer to BIOS that is compatible with UEFI standard specifications.

Intel Framework: UEFI compliant codebase created by Intel.

CPU Micro Code/Micro Code Update: Small piece of code that runs internal to the CPU. The CPU micro code is typically loaded into the CPU during the system initialization sequence. Micro code updates can be stored on the system in FLASH ROM and be updated in the field.

Core System Software: A term for Intel® architecture firmware coined by Phoenix Technologies in response to marketing around EFI as a BIOS replacement.

Firmware: Software that is stored as part of the system typically in FLASH ROM often used for system initialization.

Assembly Language: Low level programming language typically used in legacy BIOS implementations.

Legacy Free: In the PC industry, the term ‘Legacy Free’ typically refers to systems built without a standard SIO (serial/parallel comm ports) or PS2 Keyboard controller.

Legacy Interrupts: Older operating systems relied on support from BIOS through soft interrupt calls such as Int10h, Int13h and Int15h.

El Torito: Bootable CD-ROM Format Specification.

Option ROM: Binary firmware module. They can be integrated into a BIOS or firmware solution as a stand-alone binary which does not need to be linked with main source code.

Boot Loader: Loads the main operating system.

Real Mode: For real mode the selector value (loaded into a segment register) represents the upper 16-bits of the 20-bit linear address.

24 321072 ® Implementing Firmware on Embedded Intel Architecture Designs

Big-Real Mode: Addressing mode in which code is executed in 16-bit segments but data is addressed in 32-bit mode.

32-bit Protected Mode: For 32-bit protected mode the selector is an index into a descriptor table. The referenced descriptor, pointed to by the selector, holds the full 32-bit base portion of the memory address, as well as other information. Until the segment register is loaded with a new value, all future memory references using that segment add to the base a 32-bit offset to determine the linear address. If the page unit is enabled, the 32-bit linear address is translated into a 32-bit physical address. If the page unit is not enabled, the 32-bit linear address is the physical address. Segments in 32-bit protected mode can be up to 4GB in size.

Intel® EM64T Architecture: Intel® Extended Memory 64 Technology extends Intel IA-32 from a 32-bit architecture to a 64-bit architecture. EM64T introduces a new mode (referred to as “long mode”) which supports running 32-bit or 64-bit applications.

Intel® IA-32 architecture features eight general purpose registers, each of them is a 32-bit register. Intel® EM64T architecture extends each of those registers to 64-bit, which are then referred to as RAX, RBX, RCX, RDX, RSP, RBP, RSI, and RDI. It also adds eight new registers, named R9 through R15. Each of the registers is addressable as a 64-bit register, a 32-bit register, a 16-bit register and an 8-bit register. For example, R11 is the 64-bit version, R11d is the lower 32-bit of the same register, R11w is the lower 16 bits of the register and R11l is the lower byte. The registers ESP, EBP, ESI and EDI, which are not 8-bit addressable in IA-32, are 8-bit addressable in EM64T. For example, SL is the lower 8 bits of ESI. The 8-bit registers AH, BH, CH and DH are available in EM64T. They cannot be used in the same instructions with the new 8-bit registers.

IA-32 features eight 128-bit XMM registers. EM64T doubles their number to 16, and their size remains unchanged—128 bits. Their names are XMM0 through XMM15.

The X87 registers are the same as they are in IA-32: ST(0) through ST(7).

The instruction pointer, EIP, changes from 32-bit to 64-bit and is renamed to RIP.

GMCH: Graphics & Memory Controller Hub

x86: Used synonymously with or to designate IA-32 architecture.

321072 25 ® Implementing Firmware on Embedded Intel Architecture Designs

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL’S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are not intended for use in medical, life saving, or life sustaining applications. Intel may make changes to specifications and product descriptions at any time, without notice. This paper is for informational purposes only. THIS DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Intel disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted herein.

Intel, the Intel logo, Intel. leap ahead. and Intel. Leap ahead. logo, Intel SpeedStep, and Enhanced Intel SpeedStep are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

*Other names and brands may be claimed as the property of others.

Copyright © 2008 Intel Corporation. All rights reserved.

26 321072