windows access to firmware settings

Firmware Enhancements for PCs Running Windows 7September 22, 2009

Abstract

To meet the expectations of Windows® 7 users, the firmware of PCs running Windows 7 must both be fast and present an attractive boot UI by improving graphics resolution. This paper documents the investigation and proof of concept enabling “fast and pretty” firmware. The document provides background, methods, and data.

This information applies to the following operating systems:Windows 7

References and resources discussed here are listed at the end of this paper.

The current version of this paper is maintained on the Web at:

http://www.microsoft.com/whdc/system/platform/firmware/FirmwareEnhance_Win7.mspx



Firmware Enhancements for PCs Running Windows 7 - 2

Disclaimer: This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2009 Microsoft Corporation. All rights reserved.

Microsoft, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Document HistoryDate ChangeSeptember 21, 2009 First publication

ContentsBackground....................................................................................................................4

Proof of Concept.......................................................................................................4Boot Performance Improvements.................................................................................5

Overview of the Boot Process...................................................................................5High-Level Boot Improvement Timing Results..........................................................5BIOS Boot Performance Improvements.....................................................................6

SEC Phase..............................................................................................................6PEI Phase...............................................................................................................7DXE Phase.............................................................................................................7BDS Phase.............................................................................................................9Other Performance Improvements.....................................................................10

User Experience Improvements...................................................................................12Visual Improvements...............................................................................................12

Boot Graphics Timing..........................................................................................12Boot Graphics Improvements.............................................................................12Performance Impacts of Visual Improvements...................................................13

Fan Noise.................................................................................................................13Windows Access to Firmware Settings........................................................................14

Problem Overview...................................................................................................14

September 21, 2009© 2009 Microsoft Corporation. All rights reserved.


Windows Interfaces to Firmware............................................................................14Accessing Firmware from Windows........................................................................14

Appendix 1: Cost Impacts............................................................................................15BOM Impacts...........................................................................................................15Engineering Process Impacts...................................................................................16

Appendix 2: UEFI-Only Firmware.................................................................................16Appendix 3: References...............................................................................................16



BackgroundThe boot user experience (UX) for Windows Vista® rated poorly compared to other products because the experience was slow, fragmented, and included multiple graphics-mode transitions with a low-resolution boot progress indicator. One of the vision areas of Windows® 7 was to improve upon that experience by shortening and refining the graphics experience that users see during the interval between when the system power is turned on and when the logon screen is displayed.

To meet this goal, Windows 7 enhances the boot UX by initializing the graphics device in high resolution, which eliminates most of the mode transitions. Also, Windows 7 uses a high-resolution background with some animation to indicate smooth, continuous progress while the Windows 7 kernel is initialized. The boot speed of Windows 7 was also improved by other new features that tuned the bootloader and prefetcher.

Nevertheless, both the speed and appearance of the boot experience remain dependent on firmware because the percentage of boot experience dependent on firmware has increased. Apple Macintosh computers demonstrated that modern Unified Extensible Firmware Interface (UEFI) firmware could be optimized to deliver fast Power-On Self-Test (POST) times with streamlined user interface (UI). This has increased expectations for PCs running Windows 7.

However, modern PC manufacturers have challenges that do not apply to Apple Macintosh, most specifically the need to manage a large number of configurations and price points, sometimes at narrow profit margins. The impact of these requirements on performance and appearance goals is addressed in this paper.

This paper documents the creation of proofs of concept to investigate these topics and describes the results that were achieved and how those results can be reproduced.

Proof of ConceptThis paper assumes some familiarity with Advanced Configuration and Power Interface (ACPI)–compliant and UEFI-compliant basic input/output system (BIOS) technology and concepts. See the “Appendix 3: References” section for more details on ACPI and UEFI.

In 2008, Microsoft® worked closely with the Hewlett-Packard (HP) Consumer Notebook Division to tune several DV3 (“Diablo”) and DV4 (“Blade”) configurations running Windows Vista with Service Pack 1. As a result, we had access to many units and were knowledgeable about Blade firmware, hardware, and drivers. Based on that knowledge, we selected the Blade configuration (typically DV4-1145go, although we also used other configurations) as the target for the creation of proofs of concept. We also selected Insyde Software Corporation as a prototyping partner. HP’s original device manufacturers (ODMs) had licensed InsydeH20 firmware to create the DV4 design.

Microsoft and Insyde implemented time measurements of UEFI firmware run times by using Insyde’s benchmarking subroutines. We also measured circuit timing and



embedded controller firmware timing with external instruments. The latter measurements were critical because the Montevina chipset used in Blade optionally supports a slower, lower-cost circuit configuration that significantly increased Blade’s time from power on to UEFI initialization, although we did not know this at the beginning of the project.

Boot Performance Improvements

Overview of the Boot ProcessThe boot process consists of four sections: Pre-BIOS, BIOS POST, Boot Loader, and operating system Boot. This paper is concerned with only the first two sections, and primarily with BIOS POST.

Blade’s InsydeH2O BIOS is based on UEFI, and consists of four main phases:

SEC. The Security (SEC) phase brings the system from CPU reset and makes temporary RAM available for stack and data storage.

PEI. The Pre-EFI Initialization (PEI) phase finishes initializing the CPU, makes permanent RAM (such as normal DRAM) available, and then determines the boot mode (such as normal boot, ACPI “S3” resume from sleep, or ACPI “S4” resume from hibernation).

DXE. The Driver Execution Environment (DXE) phase initializes the rest of the system hardware (HW).

BDS. The Boot Device Selection (BDS) phase selects a boot device and then boots an operating system from it.

High-Level Boot Improvement Timing ResultsPhase Initial

Timing (sec)

Final Timing (sec)

Improvement (sec)

Improvement (%)

Non-BIOS Circuit & Embedded Controller 2.0 0.5 1.5 75%

Total BIOS 9.8 6.1 3.7 38%

BIOS SEC 0.3 0.2 0.1 35%

BIOS PEI 3.4 2.8 0.6 19%

BIOS DXE 0.8 0.8 0.0 4%

BIOS BDS 5.3 2.4 2.9 55%

Total Duration 11.8 6.6 5.2 44%



BIOS Boot Performance ImprovementsEach phase offered opportunity for performance tuning, but some phases were simpler or more significant to tune than others.

SEC Phase Code decompression. Code is largely compressed on ROM and is decompressed

during POST. Compression and decompression are ideally asymmetric, because longer compression times are done only once at compile time, whereas faster decompression times benefit every boot. InsydeH2O firmware already has an optimized decompression algorithm, so

no further improvement was seen in this area of performance. Although no change was required for our proof of concept, this topic is listed here for completeness.

Cache. L1 cache as RAM is the fastest RAM available in the system, so early initialization of cache and use of cache for stacks and variable storage is critical for fast firmware initialization. Writing to NVRAM during SEC is strongly discouraged. InsydeH2O firmware already made extensive use of system cache memory

during SEC, so no further improvement was seen in this area of performance. Although no change was required for our proof of concept, this topic is listed here for completeness.

Throttling. CPU vendors provide mechanisms (such as Intel SpeedStep and AMD Powernow!) to adjust CPU voltage and throttle CPU clocking in order to manage power consumption and system heat. It is common for original design manufacturers (ODMs) to adjust these mechanisms to a low level during firmware initialization when adapting firmware to a new chipset or new chassis thermal design. It is critical that the settings be reset as high as possible and as early as possible during SEC after the chipset is known to be stable and the thermal characteristics of the chassis are established. Although the operating system will take control of these settings after boot, needlessly low settings during firmware initialization can have a significant negative impact on boot performance.

InsydeH2O firmware set SpeedStep to a high level early in SEC, so no further improvement was seen in this area of performance. Although no change was required for our proof of concept, this topic is listed here for completeness.

Microcode. Most ODMs manage many designs simultaneously for their original equipment manufacturer (OEM) partners. These designs may have significant overlap. As a result, ODMs may seek to manage configuration complexity by including a small number of firmware images that dynamically adapt to the specific hardware configuration. Typically this involves maintaining a large number of CPU microcode variations within the ROM and forcing firmware to search for the correct microcode during SEC. The number of CPU microcode variations must be kept as small as possible and the search algorithm must be optimized.



Our prototype contained only a single microcode version. The time savings was about 100 msec.

PEI Phase Memory initialization. In a typical power-on POST, the system memory is

dynamically detected, tested for errors, and then cleared to zero. Dynamic detection is performed in case the user has physically changed the memory configuration since the last boot. Memory testing and clearing is performed mainly for historical reasons and is not required at every boot for modern memory technology. This project skipped the memory testing and did not clear memory to zero.

Memory testing can take as long as 10 seconds per gigabyte of DRAM. However, the original Blade firmware was not performing a complete memory test so we were only able to achieve a 500-msec improvement. Note that a comprehensive system memory test can also be run in the BIOS setup menu environment, giving a user the ability to run such a check on demand without impact on every boot.

This project skipped dynamic detection of memory configuration by hard coding memory DIMM attributes. This might not be practical for many real-world system designs. However, whenever RAM is soldered to the system board, rather than populated into DIMMs, this method should be used to improve performance. In our case the time savings was 100 msec.

DXE Phase USB topology exploration. In a typical POST, the USB host controllers are reset by

firmware and their endpoint devices detected. Some of these endpoint devices can be USB hubs, which also need to have their endpoint devices discovered. Some of the endpoint devices that are USB hubs may have additional devices attached. Each USB hub requires a reset operation and a detection of the endpoint devices. This can take three or more seconds for each device, depending on the speed of the device.

This project supported discovery of USB hubs only on the motherboard. No USB devices or hubs plugged into the USB ports were discovered. Nested hubs on the motherboard were not discovered.

Blade hardware did not include nested USB hubs on the motherboard, so the restriction above did not apply. In order to support this methodology, the system design should always avoid nested USB hubs on the motherboard.

Laptops theoretically could avoid the restriction above because they always include an integrated pointing device and an integrated keyboard. Desktop designers would need to include keyboard and mouse detection but may still elect to eliminate discovery of external hubs and devices connected to external hubs. Likewise, laptop designers may decide to provide discovery of devices plugged into docking stations, but must be careful not to affect typical laptop performance in support of the docking station scenario.



To support Bitlocker (a volume encryption feature available in some versions of Windows Vista and Windows 7 that requires the ability to load an encryption key from a USB thumb drive at boot time), the Windows Logo Program requires enumeration of the topology.

USB topology exploration also affects boot device selection if booting from USB is enabled. DXE can check whether USB boot is selected, and then explore the full topology only if USB boot is enabled. See the “BDS Phase” section later in this document for more information.

The time savings for USB setup was only 55 msec. Given the many tradeoffs listed above, limiting USB topology exploration is not a good choice for most OEM designs.

Other HW configuration. In addition to CPU microcode, other firmware support for hardware variations must be held in ROM and applied during firmware initialization. Unlike CPU microcode, these variant initializations change frequently. In order to maintain a single BIOS image, these configurations are typically held in an external, electrically erasable programmable read-only memory (EEPROM) and accessed through a serial interface. It is common for firmware to treat the EEPROM as if it were RAM and to access variables in it as needed throughout POST.

Since the EEPROM access is much slower than RAM, configuration data should be read all at once, and then cached in memory.

The time savings for HW configuration was 100 msec.

Multi-threading. All modern CPUs support multi-threaded operation. Wherever operations may be performed in parallel, they should be written to run as multiple threads. Typical firmware is single threaded.

Our prototype did not investigate the impact of multi-threading, but subsequent investigations will do so.

Note that synchronization primitives are not available and UEFI protocols are not guaranteed to run properly across multiple threads or processors (“ MP-safe”), so the burden of building multi-threaded firmware would largely fall on firmware writers to redesign their code in implementation-specific ways until the UEFI Platform Initialization Specification is modified to support this.

On the other hand, UEFI drivers are required to be re-entrant, so parallelization during DXE should be practical and provide the best return on engineering effort.

PS/2 devices. Many chipsets include support for a pair of PS/2 devices, this being intended for keyboard and pointing devices. However, PS/2 initialization is slower than USB initialization. Blade included PS/2 devices for the internal keyboard matrix and for the

touchpad. This investigation did not implement a keyboard or touchpad without PS/2 support. The time savings for such a system is estimated to be about 50 msec.

Although PS/2 devices have slow initialization, USB devices that support PS/2 are disruptive to developers because the emulation is usually driven by



system management interrupts (SMIs), which interfere with proper operation of debuggers. The ideal implementation is one in which PS/2 support in a USB device is implemented by native UEFI drivers without any dependency on System Management Mode (SMM).

Option ROMs. Video, Universal Network Device Interface during PXE (PXE UNDI), and storage controller devices often include their own ROM with BIOS extensions. These usually are in the option ROM form. Option ROMs are a de facto standard but in practice have wide variations of form and performance. For best performance, PXE UNDI, SATA, and video drivers should be provided as UEFI drivers, not as option ROMs. Blade included option ROMs for video and SATA. This investigation did not

implement native UEFI video or SATA ROM. The time savings for a native UEFI system is estimated to be between 0.5 sec and 1.0 sec.

Excess SATA channels. Chipsets often offer more channels of SATA than are utilized in the final design. Because ODMs often use the same BIOS image on many systems, these channels may be erroneously initialized during DXE, and then enumerated to Windows, leading to further delays during boot as Windows configures this redundant hardware. Excess hardware should not be initialized or enumerated to Windows.

Blade did not include excess initialized SATA channels. If it had, the time savings is estimated to be about 800 msec in firmware and 2.0 sec in Windows boot time.

Blade has its optical disk drive (ODD) on SATA port 4/5. This was done by design because the firmware takes longer to enumerate than if the ODD were on SATA port 2/3 or on port 0/1.

BDS Phase HDD as single boot device. Normally during POST, each bootable device is

dynamically detected and the media examined to see whether it is bootable. It takes 2–4 seconds for DVD/CD devices that have long latency times to spin up the rotating media.

Our prototype attempted only to improve time booting from the primary hard disk drive (HDD). The internal HDD was first in the boot order by default. The time savings was 2.9 sec.

Some OEMs prefer to set the DVD drive as the default boot device because users who are unable to boot from a DVD might not know how to change the default boot settings and might generate a support call. To avoid this, our prototype includes a predefined hotkey that provides the option to boot from DVD. If the user presses the hotkey during POST, the DVD is selected as the boot device. The hotkey should be displayed as early as possible and the time-out value kept short, or the hotkey feature itself will contribute boot delay.

Booting from USB requires that the USB boot device be detected during DXE, which is a timing trade off. We suggest that detection of a USB boot device be performed only if USB boot is selected by the user.



During all on and off transitions (such as power on, resume from S3 sleep, and resume from S4 hibernate), boot media should be spun up as early as possible during initialization to reduce I/O latencies.

SSD to replace HDD. All on and off transitions can benefit from solid-state memory to store the

system volume, rather than a rotating storage device, to avoid spin-up latency.

We did not test this impact. The degree of improvement depends on other factors (bus speed and bus enumeration cost, for instance), so system timing analysis is required to determine the best boot device selection. Obviously, some price points cannot support SSDs in place of HDDs.

Other Performance Improvements Compiler optimizations. Carefully examine the impacts of any compiler

optimizations when building a production BIOS. This gives you the most control over timing and code size.

Montevina embedded controller circuit options. Typically, a separate microcontroller integrated circuit (IC) performs keyboard matrix scanning and decoding, monitors the laptop battery and charger, checks the initial thermal state, and can also implement other features such as the power button, lid button, and CD drive. The spec of this controller is generally proprietary to an ODM. The features of the controller and its firmware are not exposed to the BIOS firmware or to the operating system.

Some embedded controllers (ECs) such as Renesas H8, maintain electrically programmable read-only memory (EPROM) on chip, but others require external ROM storage for its own microcontroller instructions.

For ECs with external ROM, Montevina offers two options, shown in figures 1 and 2, below.



Figure 1. Shared ROM for EC and BIOS

Figure 2. Separate ROM for EC and BIOS

Figure 1 shows the lower-cost option, which requires fewer memory devices. However, because BIOS is mapped into the LPC bus, the early stages (before decompression and caching) are more complex and run more slowly. Figure 2 shows the higher-performing, higher-cost option.

For our investigations, Insyde asked HP’s ODM to modify a Blade system (which was factory-built as option one) to measure the performance improvement of option two. We achieved a 1.5 sec timing improvement with option two.

This improvement was specific to Montevina, but in the future chipsets designers must also examine the tradeoff of performance for cost based on the product segment, and not simply choose the lowest cost option for all designs.

User Experience ImprovementsIn addition to performance improvements, our goal was to align the appearance of the firmware to support OEM customization and better match the Windows 7 boot experience. We also investigated the impact of fan noise on experience.



Visual Improvements

Boot Graphics TimingThe Windows 7 boot experience provides a much smoother transition from the initial POST screen to the desktop and improves graphics fidelity during boot by eliminating the unnecessary transitions in display modes that were part of the Windows Vista boot experience.

The following are the transitions Windows 7 makes from power-on to the desktop:

T1. Firmware initializes the graphics device, sets the device to a graphics mode, and then displays the initial POST splash screen.

T2. (optional) Prior to loading option ROMs or the Windows boot application, the firmware changes the device mode to text.

T3. (optional) Option ROM initializes various devices, such as network boot or RAID storage controller, and may display text output.

T4. Windows boot application (Bootmgr.exe) starts, changes the device mode to 1024 × 768 graphics mode, and then begins boot animation.

T5. Boot animation fades, and the control of the graphics device transitions to the kernel.

T6. The native kernel driver re-initializes the graphics device to native mode before displaying the logon UI or desktop.

Ideally, there would be no changes in graphics mode from the POST screen to the desktop (between T1 and T4). A smooth experience is presented to the user by eliminating the transition into text mode, which requires the operating system boot application to change the display mode a second time to high resolution.

Boot Graphics Improvements Graphics initialization. Desktop firmware typically assumes that the display type

is unknown, option ROMs will be in the system, and text mode output will be required. As a result, firmware usually initializes in a low-resolution mode, and then makes transitions in and out of text mode, resulting in flashing screens, blank screens, or flashing cursors. These assumptions generally do not apply to laptops or all-in-one desktop designs.

Blade has a native panel resolution of 1280 × 800 pixels and supports 32-bit color. Because we did not yet know of the decision to freeze Windows 7 T4 resolution at 1024 × 768, we built proofs of concept that initialized the graphics into both native panel resolution (1280 × 800 × 32) and also 1024 × 768 × 32 resolution.

In both cases the operating system screen resolution was set to a maximum of 1280 × 800 × 32. In both cases screen images were deemed to be superior to the factory default.

Due to the “fade and fireflies” animation during Windows 7 boot, the difference between 1024 × 768 and 1280 × 800 was not noticeable, and in both cases transitions to 1280 × 800 during operating system loading were considered satisfactory.



High-resolution boot image. Firmware typically displays a low-fidelity image (usually a logo) at boot. A high-fidelity image is not usually an option due to the low resolution of the graphics system during boot.

Initially we sought to display a boot image at full native screen resolution (1280 × 800 × 32 bit) but we had limitations of ROM space. Rather than rewrite more of the BIOS to allow for greater image storage, we experimented with greater JPEG compression ratios. We discovered that higher compression sometimes looked worse than lower resolution, and that the best tradeoff was image dependent (some images looked good only at low compression and high resolution, whereas others were more flexible).

Ultimately we decided to use 1024 × 768 × 24 bit as our standard image setting.

Performance Impacts of Visual Improvements Graphics overhead. Initialization of the graphics in high-resolution mode early in

boot requires changes to PEI and DXE. If initialization is not early enough, the user cannot discern the high fidelity of the boot image. Initialization of the graphics also adds some processing overhead to detect which graphics configuration to use, to set up the graphics modes, and to send the image to the controller, all of which are normally deferred until the operating system boots. In our prototype graphics, overhead added 800 msec. It is likely that this time

can be improved with further optimization of the firmware.

Fan Noise Default fan settings. Many systems have the fan on all the time as a default

setting. Users who cannot find the fan feature in the BIOS menu may complain about the fan noise.

In our prototype we did not change any of the fan settings, but we may investigate this in future projects. In general, the fan should not always be on by default and the fan noise should not exceed 22 dB.

Windows Access to Firmware Settings

Problem OverviewTypical firmware allows the user to change BIOS settings by pressing a hotkey during BDS to access a special BIOS boot menu. This is a vestige of the PC’s history as a scientific and engineering instrument, but should be considered an advanced feature impractical for most consumers to use.

Typical firmware is also rather generic, with multiple CPU microcodes, multiple video drivers, and multiple hardware configurations either combined into a single image or spread over multiple ROMs. The simplicity of managing the single BIOS image is traded off against longer boot times and higher bill of materials (BOM) costs.



Windows Interfaces to Firmware WMI. Windows already maintains limited access to ACPI firmware via Windows

Management Instrumentation (WMI). This allows Windows to see BIOS events and Advanced Configuration and Power Interface (ACPI) settings.

In our prototype we added additional capability to manipulate the WMI MOF object with Get_NV_RAM_Variables and Set_NV_RAM_Variables to change the boot order settings.

This capability can be extended to manipulate other firmware settings. Because we now support high-fidelity boot images, allowing the user to change the boot image might be popular. Allowing the user to select other fast boot settings (such as turning off full USB discovery) might be another option.

Win32. Windows Server® 2008 and 64-bit versions of Windows Vista can access UEFI firmware directly with the Win32 calls to EFI services such as GetVariable() and Set Variable(). In our prototype we initially intended to use these Win32 calls rather than

WMI but determined that the firmware rewrite would be significant and the result would be a proprietary API because there is no industry standardization for this yet, whereas the WMI interface is already available. As a result we have deferred this effort.

Accessing Firmware from Windows Windows Control Panel. Windows Control Panel is easily extensible and already

many users are aware that they should go to Control Panel to change PC settings. As such, Windows Control Panel is a logical place to give users control over firmware settings such as boot order and boot image.

We did not prototype a Windows Control Panel extension to expose this functionality. We cannot guarantee that future versions of Windows will continue to support such extensions.

The Windows Advanced System Properties page or MSconfig.exe might also be candidates for hosting this configuration UX, but these choices would need to be supported by the Windows team as part of a major release, and could not be selectively added by an OEM.

Windows-based application. OEMs commonly ship software with their hardware to add value. An OEM-branded application that allows the user to change firmware settings might be more discoverable and usable for a typical user than a custom control panel extension. Insyde wrote a test application to verify the WMI interfaces to change the

boot order and boot image. We may further develop this functionality in later investigations.

Windows Device Stage. New in Windows 7, Device Stage allows OEMs to associate custom feature lists with PCs and devices attached to PCs. Although intended for identifying and managing devices, Device Stage may also be an



appropriate discoverable point for adding firmware configuration UI due to OEM familiarity with customization capabilities. We did not prototype a Windows Device Stage experience to expose this

functionality.

Windows PE. OEMs sometimes boot into Windows Preinstallation Environment (Windows PE) in order to apply configuration data and bug patches to a Windows image without performing a full boot. Both WMI and Win32 interfaces can be accessed from Windows PE in order to allow factory-floor configuration of firmware settings. This can be done to make boot images model-specific and to reduce the amount of configuration data that must be maintained in the generic ROM images.

We did not prototype with Windows PE to expose this functionality.

Appendix 1: Cost Impacts

BOM Impacts Shared ROM and other circuit tradeoffs. Our investigation was performed on an

Intel Montevina system, and these systems offer ODMs a cost reduction option if the embedded controller and BIOS share the same ROM. The timing impact is substantial (0.5 sec in one case and 2.0 sec in the other) as is the cost savings (about US$0.25 per unit in the slower option). Other chipsets may offer different tradeoffs than shared ROM. It’s important that when systems are specified that ODMs know which tradeoff to take and not let the ODMs simply take the lower cost option by default.

ROM size. Storing high-resolution images in ROM may become costly if the same firmware is used across multiple SKUs and a larger ROM is required to store multiple images for the various SKUs. See “Engineering Process Impacts,” below.

Engineering Process Impacts Managing a single firmware version for multiple SKUs. Limiting the number of

CPU microcode and video driver options that are stored in the ROM may expose manufacturers to increased versioning. This is also true for storing multiple boot graphics. The tradeoffs are multiple versions versus larger ROM versus accessing firmware interfaces via Windows PE during an additional manufacturing step. Each manufacturer will need to determine which trade off is appropriate for each product family.

Appendix 2: UEFI-Only FirmwareToday’s firmware is typically a mix of UEFI with earlier components. As Windows operating systems that support native UEFI become pervasive, this will give way to UEFI-only firmware implementations. Today only Windows Server 2008 and 64-bit editions of Windows Vista with Service Pack 1 support native UEFI; 32-bit versions of Windows 7 also do not support native UEFI.



A mixed firmware implementation includes a Compatibility Support Module (CSM). Because the CSM adds I/O overhead during boot, a UEFI-only implementation will save 1–2 additional seconds.

A UEFI-only firmware code base would allow creation of a single EFI Byte Code (EBC) driver for each piece of hardware, regardless of CPU architecture. Other advantages include the modular design of UEFI, which would allow OEMs to more easily mix and match offerings from multiple vendors while porting enhancements and bug fixes to new platforms.

Appendix 3: ReferencesAdvanced Configuration and Power Interface (ACPI) specification v4.0

http://www.acpi.info/

Unified Extensible Firmware Interface Specification v2.3http://www.uefi.org/

UEFI Platform Initialization Specification v1.2http://www.uefi.org/

Beyond BIOS (Zimmer, Rothman, Hale)http://www.intel.com/intelpress/sum_efi.htm

Simple Boot Flag Specification v2.1http://www.microsoft.com/whdc/resources/respec/specs/simp_boot.mspx

Windows Preinstallation Environmenthttp://technet.microsoft.com/en-us/library/dd744548(WS.10).aspx

Insyde Software Corp.http://www.insydesw.com/


http://www.insydesw.com/

http://technet.microsoft.com/en-us/library/dd744548(WS.10).aspx

http://www.microsoft.com/whdc/resources/respec/specs/simp_boot.mspx

http://www.intel.com/intelpress/sum_efi.htm

http://www.uefi.org/

http://www.uefi.org/

http://www.acpi.info/

windows access to firmware settings

Documents