Implementing Firmware on Embedded Intel

8/2/2019 Implementing Firmware on Embedded Intel

1/26

321072

Implementing

Firmware on

Embedded Intel

Architecture

Designs

Intel Architecture

Firmware Design

Guidelines

January 2009

White Paper

John MacInnis

Intel Corporation ECG

Technical Marketing Engineer


2/26

Implementing Firmware on Embedded Intel Architecture Designs

2 321072

Executive SummaryEmbedded 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 considerstarting 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.


3/26


321072 3

Contents

Business Challenge .................................................................................................4Solution ................................................................................................................4Essentials of Embedded Intel architecture (Boot Loader) Firmware...............................5Intel Architecture Functional Block Diagram ..............................................................6The History and Evolution of BIOS.............................................................................7

A brief history.......................................................................................7Limitations of legacy BIOS......................................................................8The Birth of the Intel Platform Innovation Framework for EFI.....................8

What is UEFI? ........................................................................................................9UEFI PI Firmware Phases .....................................................................11UEFI Interoperability Validation Activities................................................12

Advanced Configuration and Power Interface (ACPI) ..................................................13System Management Mode (SMM) ..........................................................................15Independent BIOS Vendors (IBVs) ..........................................................................15Embedded Independent Software Vendors (ISVs)......................................................16Boot Time Optimization .........................................................................................16Legacy Free .........................................................................................................17Advanced IBV BIOS Features..................................................................................17Intel Advanced Firmware Features ..........................................................................21Industry Standards: Organizations and Specs...........................................................21Conclusion...........................................................................................................22Intel Architecture Firmware Acronyms....................................................................23Intel architecture Firmware Terminology ................................................................24


4/26


4 321072

Business Challenge

A firmware solution is essential for embedded Intel architecture designs. Forcustomers migrating to Intel architecture from non-Intel architecturedesigns, the first business challenge is the decision to make or buy.

Customers must also decide if their requirements include a full-BIOS solutionor a simpler Boot Loader.

Embedded Intel architecture designs must include a firmware stack which

initializes the platform hardware and provides support for the OperatingSystem. Intel architecture-based desktop, notebook and server productstypically use a full BIOS implementation which is either provided by anIndependent BIOS Vendor (IBV) or an in-house BIOS development team.

Embedded system designs have significant cost versus feature requirementsand time to market considerations. For many embedded products (e.g.

KIOSK or Point of Sale) a full BIOS managed either through an ODM ordirectly with an IBV is the most effective solution. For more specializedsingle-purpose embedded products the benefits of full BIOS are reduced.

Design simplicity, faster boot times, optimized footprint and BOM costconsiderations are significant and requirements often dictate a minimalfirmware 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 solutionsversus a full BIOS implementation.

SolutionDetermine the cost-benefits of full BIOS on the design. Understand thebenefits of an IBV engagement. Understand the minimal requirements of aBoot Loader and development costs. Decide whether to purchase firmware as

an ODM BOM cost item, use an IBV, ISV develop or outsource a boot loaderfrom 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. Formost solutions it is advisable to leverage an existing solution and then apply

engineering resources to tune, optimize or integrate value-add componentsinto the design. Firmware or BIOS solutions are available through IBVs, ISVsand the Intel ecosystem.


5/26


321072 5

Essentials of Embedded Intel

architecture (Boot Loader) FirmwareEvery embedded Intel architecture design must include a firmware stackwhich initializes CPU cores, memory, IO, peripherals and graphics. A fully

featured PC compatible solution is engineered to perform complete discoveryand initialization algorithms which can be undesirable in an embedded

system. Unlike a PC, in an embedded design, the level of initialization is donein a closed system and therefore can be optimized for faster pre-bootexecution and smaller footprint.

In addition to pre-boot initialization, runtime support must be provided. Thelevel and architectural protocols of runtime support is determined by the

target OS or RTOS. Runtime support is typically handled by a combination ofAdvanced Configuration and Power Management Interface (ACPI), interruptservices 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


6/26


6 321072

Intel Architecture Functional Block

DiagramIn addition to a firmware flow chart, it is useful for the firmware designer torefer to functional block diagrams. Firmware components are responsible forinitializing each of the block functions seen in the figure below. Firmware will

generally perform basic and advanced initialization/configuration of thefunctional blocks during boot. During runtime, firmware components work incooperation with the OS to manage dynamic configuration changes and

power management of each functional block.

CPU support includes micro-code upload, CPU register configurationand power management

The Graphics and Memory Controller Hub (GMCH) sometimes referredto as the north-bridge, controls main system memory and integratedgraphics 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 supportfunctions of the I/O Controller Hub are designed to conform to

industry specifications such as PCI-Sig and USB.


7/26


321072 7

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 ofthat day was probably more like a boot loader than the full featured BIOS oftoday. 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 theadoption and integration of new industry-standard configuration and powermanagement technologies.


8/26


8 321072

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 certainlimitations 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 beganto have need for methods to ensure quality of individual firmware modules as

well as the ability to quickly integrate libraries of third party firmwaremodules into a single platform solution across multiple product lines. Theseinherent limitations and existing market demands opened the opportunity for

a fresh BIOS architecture to be developed and introduced to the market. TheUEFI specifications and resulting implementations have begun to effectivelyaddress these persisting market needs.

One of the critical maintenance challenges for BIOS is that eachimplementation has tended to be highly customized for the specific

motherboard on which it is deployed. Moving component modules acrossdesigns typically requires significant porting, integration, testing and debugwork. This is one of the market challenges the UEFI architecture promises to

address.

The Birth of the Intel Platform Innovation Frameworkfor 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. Itincluded 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 nowresponsible for its development and promotion. EFI was renamed to Unified

EFI (UEFI) to reflect this. Most documentation uses both termsinterchangeably.

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. Itadded and improved cryptography, network authentication, and the User
http://en.wikipedia.org/wiki/Itaniumhttp://en.wikipedia.org/wiki/PC_AThttp://www.uefi.org/http://en.wikipedia.org/wiki/Cryptographyhttp://en.wikipedia.org/wiki/Cryptographyhttp://www.uefi.org/http://en.wikipedia.org/wiki/PC_AThttp://en.wikipedia.org/wiki/Itanium


9/26


321072 9

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 projectwhich promotes and encourages adoption of UEFI technology for Intel basedplatforms.

A presentation on optimizing Framework boot times is available at the

following link:

I ntel Framew ork Customization for Optim ized Platform Boot I niti alization

San Francisco 2008 IDF Presentation Session ID: EFIS002

What is UEFI?

Formed in 2005, the Unified EFI Forum, Inc. is a Washington non-profitcorporation whose goal is to forward the technical advancement of the ITindustry through the development and promotion of a set of Unified

Extensible Firmware Interface (UEFI) standard specifications. The Forum isgoverned by a board of directors from eleven promoter companies: AMD*,AMI*, Apple*, Dell*, HP*, IBM*, Insyde*, Intel*, Lenovo*, Microsoft* and

Phoenix*. In addition, there are over 120 contributor and adopter members.UEFI specifications include advances in Intel

architecture firmware overpreviously existing BIOS technologies and remove some technical barriers. Itis important to note that not all pre-existing BIOS technology has beenabandoned or replaced. UEFI specifications include and build on many pre-

existing BIOS technologies such as ACPI, and SMBIOS as only two of manyexamples.

Today, over 130 companies have joined the UEFI forum and have integrated

UEFI capability into their products including all the major BIOS vendors. Froma market perspective, it is best to view the adoption of UEFI technology as amajor 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 driversand system firmware.
http://en.wikipedia.org/wiki/User_Interfacehttp://www.logic.nl/Products/Technology/BIOS-and-EFI.aspxhttp://intelstudios.edgesuite.net/fall_idf/sessions/IDF_EFIS002/index.htmhttp://www.uefi.org/homehttp://www.uefi.org/specs/http://en.wikipedia.org/wiki/User_Interfacehttp://www.uefi.org/specs/http://www.uefi.org/homehttp://intelstudios.edgesuite.net/fall_idf/sessions/IDF_EFIS002/index.htmhttp://www.logic.nl/Products/Technology/BIOS-and-EFI.aspxhttp://en.wikipedia.org/wiki/User_Interfacehttp://en.wikipedia.org/wiki/User_Interface


10/26


10 321072

Operating systems and other high-level software should ONLY interactwith 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 fromdifferent 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 TrustedComputing Group. The TCG EFI specifications define a standard interface to

the Trusted Platform Module (TPM) on an EFI/UEFI platform and therequirements for measuring boot events into TPM Platform ConfigurationRegisters (PCRs) and adding boot event entries into the TCG Event Log.
http://www.uefi.org/specs/http://www.uefi.org/specs/https://www.trustedcomputinggroup.org/homehttps://www.trustedcomputinggroup.org/homehttps://www.trustedcomputinggroup.org/homehttps://www.trustedcomputinggroup.org/homehttp://www.uefi.org/specs/http://www.uefi.org/specs/


11/26


321072 11

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 InitializationModules (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 processingshould 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 ispassed to and consumed by the DXE phase.

The Driver Execution Environment (DXE) phase is where most of thesystem initialization is performed. Pre-EFI Initialization (PEI), the phase priorto DXE, is responsible for initializing permanent memory in the platform so

that the DXE phase can be loaded and executed.
http://www.uefi.org/http://www.uefi.org/


12/26


12 321072

Figure 4. UEFI Firmware Phases

In the Boot Device Select (BDS) phase, the Boot Dispatcher isresponsible for determining what to load and any interactions with the userthat 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, integratedplatform 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 containapplications 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, thatcan be defined and used by various OS or system firmware components.

The primary purpose ofRuntime phase services is to abstract minor parts ofthe hardware implementation of the platform from the OS. Runtime servicefunctions 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 andODMs get together to verify that independently designed components allwork together in order to build comprehensive computer systems. UEFI.org


13/26


321072 13

and its sponsor members have held many plug-fest or interoperability events.

These events will continue to occur until the technology is fully mature. Formore 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 motherboarddevice configuration and power management of both devices and entiresystems. 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 oninto a well-defined power management and configuration interfacespecification. ACPI is a key component of UEFI specifications.

ACPI specifications define ACPI hardware interfaces, ACPI software interfacesand ACPI data structures. The specifications also define the semantics ofthese interfaces. Although it addresses both software and hardware and how

they must behave, ACPI is nota software specification and it is notahardware specification. Instead, ACPI is an interface specification comprisedof both software and hardware elements.
http://www.uefi.org/http://www.hp.com/hpinfo/index.html?mtxs=corp&mtxb=3&mtxl=1http://www.intel.com/http://www.microsoft.com/about/default.mspxhttp://htp/www.phoenix.com/http://www.toshiba.com/tai/about_us/about_ov.jsphttp://www.toshiba.com/tai/about_us/about_ov.jsphttp://htp/www.phoenix.com/http://www.microsoft.com/about/default.mspxhttp://www.intel.com/http://www.hp.com/hpinfo/index.html?mtxs=corp&mtxb=3&mtxl=1http://www.uefi.org/


14/26


14 321072

Figure 5. ACPI System Architecture

ACPI Driver / AMLInterpreter

OS-directed Power

Management

ACPIRegisters

ACPI Tables

Operating System Kernel

Platform Hardware

Firmware

Firmware providers write definition blocks using the ACPI Control MethodSource language (ASL) and operating systems use an ACPI Control Method

Language (AML) interpreter to produce byte stream encoding.

// ASL ExampleDefinitionBlock (

"forbook.aml", // Output Filename"DSDT", // Signature0x02, // DSDT Compliance Revision"OEM", // OEMID

"forbook", // TABLE ID0x1000 // 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 devicePowerResource(FET0, 0, 0) { // start of pwr

Method (_ON) {Store (Ones, CT01) // assert powerSleep (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


15/26


321072 15

System Management Mode (SMM)

System Management Mode (SMM) provides the firmware designer with avery powerful capability especially when noted that ACPI control methods can

be used to trigger SMIs during system runtime. Intels SMM provides thesystem designer with means of building software-controlled features into asystem at the hardware/firmware level, making them transparent to

operating system and application software. The SMM architecture includesthe 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 thesystem 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 handlersand code and data storage. This memory resource is protected and normally

hidden from the system OS so that the processor has immediate access tothis memory space upon entry to SMM.

Independent BIOS Vendors (IBVs)

From an engineering cost perspective, only very large OEMs and ODMs find itpractical to develop and maintain their own firmware. A practical approach formost embedded projects is to begin by contracting firmware through an ODM

if you are using one or directly through an IBV. This approach is generallycost effective and allows your engineering resources to focus on your ownvalue add components.

Below are companies with specific expertise developing and deploying Intel

architecture firmware technology commonly referred to as BIOS. The value ofworking with these companies is leveraging their many years of expertise.Despite the industrys 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 anderror the IBVs have built up a wealth of knowledge which is stored in theircode bases, engineers heads and sometimes their documentation. The IBVsknow from experience how to bring up Intel architecture platforms andsupport multiple operating systems. All of them have direct relationships

with Intel and multiple operating system vendors and can save a lot of timeotherwise spent in the lab figuring out basic undocumented OS-BIOSinteraction.


16/26


16 321072

The following vendors are participants in uefi.org activities and offer legacy

BIOS products, UEFI compliance and boot loaders.

American Megatrends Inc.* Insyde Software Corp.* Nanjing Byosoft Co.,Ltd.* Phoenix Technologies, 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 withone of these companies is that the technical and business model should befamiliar 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 forIntel Architecture applications

Lynuxworks offers custom and pre-configured BSPs for Intelarchitecture 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 orUEFI 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 ofeliminating or restricting configuration, enumeration and discovery algorithmsflexibility. 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 BootLoader with BSP.
http://www.ami.com/http://www.insydesw.com/http://byosoft.com.cn/en_about.asphttp://www.phoenix.com/http://www.ghs.com/products/x86_development.htmlhttp://www.lynuxworks.com/board-support/x86-develop.phphttp://www.mvista.com/boards.php?vendorsearch=Intel&boardname=&archgroup=X86&processor=&edition=All&v=All&a0=1http://www.qnx.com/support/training/special.htmlhttp://www.windriver.com/portal/server.pt/gateway/PTARGS_0_80302_389259_0_0_18/6151_WP_Intel_SMP_1008.pdf?http://www.windriver.com/portal/server.pt/gateway/PTARGS_0_80302_389259_0_0_18/6151_WP_Intel_SMP_1008.pdf?http://www.qnx.com/support/training/special.htmlhttp://www.mvista.com/boards.php?vendorsearch=Intel&boardname=&archgroup=X86&processor=&edition=All&v=All&a0=1http://www.lynuxworks.com/board-support/x86-develop.phphttp://www.ghs.com/products/x86_development.htmlhttp://www.phoenix.com/http://byosoft.com.cn/en_about.asphttp://www.insydesw.com/http://www.ami.com/


17/26


321072 17

A presentation on optimizing Framework boot times is available at the

following link.

I ntel Framew ork Customization for Optim ized Platform Boot I niti alization

San Francisco 2008 IDF Presentation Session ID: EFIS002

Legacy Free

In the PC industry, the term Legacy Freetypically refers to systems builtwithout a standard SIO (serial/parallel comm ports, floppy drive) or PS2Keyboard controller. Building Legacy Free systems is not always a trivial

matter because market demand often includes hard requirements that legacyfree systems operate in legacy software environments. For example, an

operating system such as DOS relies on Port 60/64h legacy keyboard mousecontroller which is not present in a legacy-free system using a USBkeyboard/mouse. In this case legacy emulation must be performed at thefirmware 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 BIOSimplementation. The combined feature set offers system flexibility,

manageability and compatibility with a wide range of open architecturehardware 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

support

IBVs can provide standard methods for integrating 3rd

party driver support.

ACPI The Advanced Configuration & Power Interface establishes

industry-standard interfaces enabling OS-directed

configuration, power management, and thermalmanagement 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.
http://intelstudios.edgesuite.net/fall_idf/sessions/IDF_EFIS002/index.htmhttp://www.1394ta.org/index.htmlhttp://www.acpi.info/http://www.dmtf.org/standards/asf/http://www.dmtf.org/standards/asf/http://www.acpi.info/http://www.1394ta.org/index.htmlhttp://intelstudios.edgesuite.net/fall_idf/sessions/IDF_EFIS002/index.htm


18/26


18 321072

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 alsoinclude 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,

FLASH)

Creation of virtual drives which appear to the operating

system as an ordinary disk drive.

Downstream support tools for

binary configuration

IBVs can provide re-distribution licenses for downstream

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 firmwareor 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.
http://www.t13.org/http://www.t13.org/


19/26


321072 19

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,

USB, CDROM, LAN, Floppy)

Capability to boot from essentially any storage device

available.

NUMA Non-Uniform Memory Access

In NUMA platforms, memory access time is not uniformacross 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.
http://www.pcisig.com/specifications/conventional/pci_hot_plug/http://www.intel.com/technology/platform-technology/hyper-threading/http://en.wikipedia.org/wiki/TCP/IPhttp://developer.intel.com/design/servers/ipmi/http://www.microsoft.com/whdc/archive/lf.mspxhttp://www.microsoft.com/whdc/system/pnppwr/whea/default.mspxhttp://www.intel.com/technology/itj/2007/v11i4/9-process/3-scheduler.htmhttp://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspxhttp://www.pcisig.com/homehttp://www.pcisig.com/homehttp://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspxhttp://www.intel.com/technology/itj/2007/v11i4/9-process/3-scheduler.htmhttp://www.microsoft.com/whdc/system/pnppwr/whea/default.mspxhttp://www.microsoft.com/whdc/archive/lf.mspxhttp://developer.intel.com/design/servers/ipmi/http://en.wikipedia.org/wiki/TCP/IPhttp://www.intel.com/technology/platform-technology/hyper-threading/http://www.pcisig.com/specifications/conventional/pci_hot_plug/


20/26


20 321072

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

sound)

Splash screens and customization utilities for OEM

branding.

Splash Screen swap (LOGO

change)

Binary utilities to change the Splash screen. These are

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.
http://www.pxe.ca/http://www.intel.com/design/archives/wfm/http://www.dmtf.org/standards/smbios/https://www.trustedcomputinggroup.org/homehttp://www.uefi.org/homehttp://www.uefi.org/homehttps://www.trustedcomputinggroup.org/homehttp://www.dmtf.org/standards/smbios/http://www.intel.com/design/archives/wfm/http://www.pxe.ca/


21/26


321072 21

Intel Advanced Firmware Features

Intel provides advanced BIOS or firmware features which cooperate withhardware 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

AMTVTTXT

Hardware-assisted security and

manageability capabilities.

Intel Active ManagementTechnology (AMT) enables secure

remote platform applications.

Intel Virtualization Technology(VT) enables hardware-assisted

virtualization.

Intel Trusted ExecutionTechnology (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 Technology

Intel SpeedStep Technologies enable

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-standardsorganization with the aim of enhancing the security of the computingenvironment in disparate computer platforms. TCG was formed in spring

2003 and has adopted the specifications developed by the Trusted Computing
http://www.intel.com/technology/vpro/index.htmhttp://software.intel.com/en-us/articles/download-the-latest-intel-amt-software-development-kit-sdkhttp://software.intel.com/en-us/articles/download-the-latest-intel-amt-software-development-kit-sdkhttp://www.intel.com/technology/virtualization/index.htm?iid=tech_vpro_body_vthttp://www.intel.com/technology/virtualization/index.htm?iid=tech_vpro_body_vthttp://www.intel.com/technology/security/downloads/TrustedExec_Overview.pdfhttp://www.intel.com/technology/security/downloads/TrustedExec_Overview.pdfhttp://www.intel.com/design/intarch/papers/301174.htmhttp://www.intel.com/design/intarch/papers/301174.htmhttp://www.intel.com/design/intarch/papers/301174.htmhttp://www.intel.com/design/intarch/papers/301174.htmhttp://www.acpi.info/http://www.dmtf.org/homehttp://www.pcisig.com/homehttps://www.trustedcomputinggroup.org/homehttps://www.trustedcomputinggroup.org/homehttp://www.pcisig.com/homehttp://www.dmtf.org/homehttp://www.acpi.info/http://www.intel.com/design/intarch/papers/301174.htmhttp://www.intel.com/design/intarch/papers/301174.htmhttp://www.intel.com/design/intarch/papers/301174.htmhttp://www.intel.com/design/intarch/papers/301174.htmhttp://www.intel.com/technology/security/downloads/TrustedExec_Overview.pdfhttp://www.intel.com/technology/virtualization/index.htm?iid=tech_vpro_body_vthttp://software.intel.com/en-us/articles/download-the-latest-intel-amt-software-development-kit-sdkhttp://www.intel.com/technology/vpro/index.htm


22/26


22 321072

Platform Alliance (TCPA). The distinguishing feature of TCG technology is

arguably the incorporation of roots of trust into computer platforms. TCGArchitecture Overview Specification Revision 1.4, August 2007

Trusted Computing as defined by TCG relies on establishing Trusted BuildingBlocks and creating a chain of trust through levels of software. Roots ofTrust are components that must be trusted because misbehavior might notbe detected. There are commonly three Roots of Trust in a trusted platform;

aroot of trust for measurement (RTM), root of trust for storage (RTS) androot of trust for reporting (RTR).

Typically in platform implementations containing a Trusted Platform Module(TPM) the platform firmware is responsible for initializing the TPM andestablishing 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 EmbeddedIntel architecture firmware. The paper gives a high-level overview of severalkey technologies and references to go learn more about them.

Because of its inherent complexity and number of technologies to beconsidered and from an engineering cost perspective only very large OEM andODMs find it practical to develop and maintain their own firmware. If your

company falls in this category then you probably already have plenty ofexpertise, direct support from Intel and Operating System Vendors orperhaps you are running a proprietary RTOS.

A practical approach for most embedded projects is to begin by contractingfirmware through an ODM if you are using one or directly through an IBV.

This approach is generally cost effective and allows your engineeringresources to focus on your own value add components.
http://www.t13.org/http://www.uefi.org/http://www.usb.org/homehttp://developer.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdfhttp://www.microsoft.com/whdc/resources/respec/specs/simp_boot.mspxhttp://www.intel.com/design/archives/processors/pro/docs/242016.htmhttp://www.dmtf.org/standards/smbios/http://smbus.org/specs/http://smbus.org/specs/http://www.dmtf.org/standards/smbios/http://www.intel.com/design/archives/processors/pro/docs/242016.htmhttp://www.microsoft.com/whdc/resources/respec/specs/simp_boot.mspxhttp://developer.intel.com/technology/usb/download/DebugDeviceSpec_R090.pdfhttp://www.usb.org/homehttp://www.uefi.org/http://www.t13.org/


23/26


321072 23

Starting solutions are available from IBVs, ISVs and the Intel ecosystem.

Start there and build on the design to meet your particular productrequirements.

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
http://www.acpi.info/http://www.microsoft.com/whdc/archive/amp_12.mspxhttp://www.acpi.info/toolkit.htmhttp://t13.org/Default.aspxhttp://www.ata-atapi.com/http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdfhttp://en.wikipedia.org/wiki/BIOS#The_BIOS_businesshttp://www.intel.com/technology/efi/http://www.microsoft.com/downloads/details.aspx?familyid=7A1C9DA0-0510-44A2-B042-7EF370530C64&displaylang=enhttp://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspxhttp://www.pcisig.com/homehttp://en.wikipedia.org/wiki/Plug-and-playhttp://www.pxe.ca/http://www.serialata.org/http://www.dmtf.org/standards/smbios/http://smbus.org/specs/https://www.trustedcomputinggroup.org/homehttps://www.trustedcomputinggroup.org/groups/tpm/http://t13.org/Documents/MinutesDefault.aspx?keyword=UDMAhttp://www.uefi.org/homehttp://www.usb.org/homehttp://www.usb.org/homehttp://www.uefi.org/homehttp://t13.org/Documents/MinutesDefault.aspx?keyword=UDMAhttps://www.trustedcomputinggroup.org/groups/tpm/https://www.trustedcomputinggroup.org/homehttp://smbus.org/specs/http://www.dmtf.org/standards/smbios/http://www.serialata.org/http://www.pxe.ca/http://en.wikipedia.org/wiki/Plug-and-playhttp://www.pcisig.com/homehttp://msdn.microsoft.com/en-us/library/aa366796(VS.85).aspxhttp://www.microsoft.com/downloads/details.aspx?familyid=7A1C9DA0-0510-44A2-B042-7EF370530C64&displaylang=enhttp://www.intel.com/technology/efi/http://en.wikipedia.org/wiki/BIOS#The_BIOS_businesshttp://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdfhttp://www.ata-atapi.com/http://t13.org/Default.aspxhttp://www.acpi.info/toolkit.htmhttp://www.microsoft.com/whdc/archive/amp_12.mspxhttp://www.acpi.info/


24/26


24 321072

Intel architecture Firmware

TerminologyEFI-BIOS: Used to refer to BIOS that is compatible with UEFI standardspecifications.

Intel Framework: UEFI compliant codebase created by Intel.

CPU Micro Code/Micro Code Update: Small piece of code that runsinternal to the CPU. The CPU micro code is typically loaded into the CPUduring the system initialization sequence. Micro code updates can be stored

on the system in FLASH ROM and be updatedin the field.

Core System Software: A term for Intel architecture firmware coined byPhoenix Technologies in response to marketing around EFI as a BIOS

replacement.

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

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

Legacy Free: In the PC industry, the term Legacy Freetypically refers to

systems built without a standard SIO (serial/parallel comm ports) or PS2Keyboard 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 linkedwith main source code.

Boot Loader: Loads the main operating system.

Real Mode:For real mode the selector value (loaded into a segmentregister) represents the upper 16-bits of the 20-bit linear address.
https://www.tianocore.org/http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496-A286D893E36A/0/specscdrom.pdfhttp://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496-A286D893E36A/0/specscdrom.pdfhttps://www.tianocore.org/


25/26


321072 25

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 otherinformation. Until the segment register is loaded with a new value, all futurememory 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 linearaddress 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-bitprotected mode can be up to 4GB in size.

Intel EM64T Architecture: Intel Extended Memory 64 Technologyextends 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 thoseregisters 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, a16-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. Forexample, 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 withthe new 8-bit registers.

IA-32 features eight 128-bit XMM registers. EM64T doubles their number to16, and their size remains unchanged128 bits. Their names are XMM0through 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 toRIP.

GMCH: Graphics & Memory Controller Hub

x86: Used synonymously with or to designate IA-32 architecture.
http://download.intel.com/design/intarch/papers/exc_ia.pdfhttp://download.intel.com/design/intarch/papers/exc_ia.pdfhttp://software.intel.com/en-us/articles/porting-code-to-intel-em64t-based-platformshttp://software.intel.com/en-us/articles/porting-code-to-intel-em64t-based-platformshttp://software.intel.com/en-us/articles/porting-code-to-intel-em64t-based-platformshttp://www.intel.com/design/chipsets/embedded/915gme.htmhttp://www.intel.com/design/chipsets/embedded/915gme.htmhttp://software.intel.com/en-us/articles/porting-code-to-intel-em64t-based-platformshttp://software.intel.com/en-us/articles/porting-code-to-intel-em64t-based-platformshttp://software.intel.com/en-us/articles/porting-code-to-intel-em64t-based-platformshttp://download.intel.com/design/intarch/papers/exc_ia.pdf


26/26


26 321072

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO

LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUALPROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTELS TERMSAND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITYWHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TOSALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TOFITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT,COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are not intended for usein 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 SpeedStepare 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.