Firmware Enhancements for PCsRunning Windows 7

最新推荐文章于 2024-03-26 17:05:00 发布

ymzhou117

最新推荐文章于 2024-03-26 17:05:00 发布

阅读量2.3k

点赞数

文章标签： windows initialization system microsoft prototype compression

本文探讨了如何通过改进固件来提升Windows 7系统的启动速度及用户体验，特别是在图形分辨率和引导过程方面进行了优化。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Abstract

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

This information applies to the followingoperating systems:
Windows 7

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

The current version of this paper ismaintained on the Web at:
http://www.microsoft.com/whdc/system/platform/firmware/FirmwareEnhance_Win7.mspx

Disclaimer: This is a preliminarydocument and may be changed substantially prior to final commercial release ofthe software described herein.

The information contained in thisdocument represents the current view of Microsoft Corporation on the issuesdiscussed as of the date of publication. Because Microsoft must respond tochanging market conditions, it should not be interpreted to be a commitment onthe part of Microsoft, and Microsoft cannot guarantee the accuracy of anyinformation presented after the date of publication.

This White Paper is for informationalpurposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, ASTO THE INFORMATION IN THIS DOCUMENT.

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

Microsoft may have patents, patentapplications, trademarks, copyrights, or other intellectual property rightscovering subject matter in this document. Except as expressly provided in anywritten license agreement from Microsoft, the furnishing of this document doesnot give you any license to these patents, trademarks, copyrights, or otherintellectual property.

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

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

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

Document History

Date	Change
September 21, 2009	First publication

Contents

Background. 4

Proof of Concept. 4

Boot PerformanceImprovements. 5

Overview of the BootProcess. 5

High-Level BootImprovement Timing Results. 5

BIOS BootPerformance Improvements. 6

Other PerformanceImprovements. 10

User ExperienceImprovements. 12

Visual Improvements. 12

Boot Graphics Timing. 12

Boot GraphicsImprovements. 12

Performance Impactsof Visual Improvements. 13

Fan Noise. 13

Windows Access to FirmwareSettings. 14

Problem Overview.. 14

Windows Interfacesto Firmware. 14

Accessing Firmwarefrom Windows. 14

Appendix 1: CostImpacts. 15

BOM Impacts. 15

Engineering ProcessImpacts. 16

Appendix 2:UEFI-Only Firmware. 16

Appendix 3:References. 16

Background

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

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

Nevertheless, both the speed andappearance of the boot experience remain dependent on firmware because thepercentage of boot experience dependent on firmware has increased. AppleMacintosh computers demonstrated that modern Unified Extensible FirmwareInterface (UEFI) firmware could be optimized to deliver fast Power-On Self-Test(POST) times with streamlined user interface (UI). This has increasedexpectations for PCs running Windows 7.

However, modern PC manufacturers havechallenges that do not apply to Apple Macintosh, most specifically the need tomanage a large number of configurations and price points, sometimes at narrowprofit margins. The impact of these requirements on performance and appearancegoals is addressed in this paper.

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

Proof of Concept

This paper assumes some familiarity with AdvancedConfiguration and Power Interface (ACPI)–compliant andUEFI-compliant basic input/output system (BIOS) technology and concepts. Seethe “Appendix 3: References” section for more details on ACPI and UEFI.

In 2008, Microsoft® worked closely with theHewlett-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 Bladefirmware, hardware, and drivers. Based on that knowledge, we selected the Bladeconfiguration (typically DV4-1145go, although we also used otherconfigurations) as the target for the creation of proofs of concept. We alsoselected Insyde Software Corporation as a prototyping partner. HP’s originaldevice manufacturers (ODMs) had licensed InsydeH20 firmware to create the DV4design.

Microsoft and Insyde implemented timemeasurements of UEFI firmware run times by using Insyde’s benchmarkingsubroutines. We also measured circuit timing and embedded controller firmwaretiming with external instruments. The latter measurements were critical becausethe Montevina chipset used in Blade optionally supports a slower, lower-costcircuit configuration that significantly increased Blade’s time from power onto UEFI initialization, although we did not know this at the beginning of theproject.

BootPerformance Improvements

Overview of the Boot Process

The boot process consists of foursections: Pre-BIOS, BIOS POST, Boot Loader, and operating system Boot. Thispaper is concerned with only the first two sections, and primarily with BIOSPOST.

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 makestemporary RAM available for stack and data storage.

· PEI. The Pre-EFI Initialization (PEI) phase finishes initializing theCPU, makes permanent RAM (such as normal DRAM) available, and then determinesthe 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 ofthe system hardware (HW).

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

High-Level Boot Improvement TimingResults

Phase	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 Improvements

Each phase offered opportunity forperformance tuning, but some phases were simpler or more significant to tunethan others.

SEC Phase

· Code decompression. Code is largelycompressed on ROM and is decompressed during POST. Compression anddecompression are ideally asymmetric, because longer compression times are doneonly once at compile time, whereas faster decompression times benefit everyboot.

· InsydeH2O firmware already hasan optimized decompression algorithm, so no further improvement was seen inthis area of performance. Although no change was required for our proof ofconcept, this topic is listed here for completeness.

· Cache. L1 cache as RAM is the fastestRAM available in the system, so early initialization of cache and use of cachefor stacks and variable storage is critical for fast firmware initialization.Writing to NVRAM during SEC is strongly discouraged.

· InsydeH2O firmware already madeextensive use of system cache memory during SEC, so no further improvement wasseen in this area of performance. Although no change was required for our proofof concept, this topic is listed here for completeness.

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

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

· Microcode. Most ODMs manage many designssimultaneously for their original equipment manufacturer (OEM) partners. Thesedesigns may have significant overlap. As a result, ODMs may seek to manageconfiguration complexity by including a small number of firmware images thatdynamically adapt to the specific hardware configuration. Typically thisinvolves maintaining a large number of CPU microcode variations within the ROMand forcing firmware to search for the correct microcode during SEC. The numberof CPU microcode variations must be kept as small as possible and the searchalgorithm must be optimized.

· Our prototype contained only asingle microcode version. The time savings was about 100 msec.

PEI Phase

· Memory initialization. In a typicalpower-on POST, the system memory is dynamically detected, tested for errors,and then cleared to zero. Dynamic detection is performed in case the user hasphysically changed the memory configuration since the last boot. Memory testingand clearing is performed mainly for historical reasons and is not required atevery boot for modern memory technology.

· This project skipped the memorytesting and did not clear memory to zero. Memory testing can take as long as 10seconds per gigabyte of DRAM. However, the original Blade firmware was notperforming a complete memory test so we were only able to achieve a 500-msecimprovement. Note that a comprehensive system memory test can also be run inthe BIOS setup menu environment, giving a user the ability to run such a checkon demand without impact on every boot.

· This project skipped dynamicdetection of memory configuration by hard coding memory DIMM attributes. Thismight not be practical for many real-world system designs. However, wheneverRAM is soldered to the system board, rather than populated into DIMMs, thismethod should be used to improve performance. In our case the time savings was100 msec.

DXE Phase

· USB topology exploration. In a typical POST, the USB host controllers are reset by firmwareand their endpoint devices detected. Some of these endpoint devices can be USBhubs, which also need to have their endpoint devices discovered. Some of theendpoint devices that are USB hubs may have additional devices attached. EachUSB 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 ofthe device.

· This project supporteddiscovery of USB hubs only on the motherboard. No USB devices or hubs pluggedinto the USB ports were discovered. Nested hubs on the motherboard were notdiscovered.

· Blade hardware did not includenested USB hubs on the motherboard, so the restriction above did not apply. Inorder to support this methodology, the system design should always avoid nestedUSB hubs on the motherboard.

· Laptops theoretically couldavoid the restriction above because they always include an integrated pointingdevice and an integrated keyboard. Desktop designers would need to includekeyboard and mouse detection but may still elect to eliminate discovery ofexternal hubs and devices connected to external hubs. Likewise, laptopdesigners may decide to provide discovery of devices plugged into dockingstations, but must be careful not to affect typical laptop performance insupport of the docking station scenario.

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

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

· The time savings for USB setupwas only 55 msec. Given the many tradeoffs listed above, limiting USB topologyexploration is not a good choice for most OEM designs.

· Other HW configuration. In addition toCPU microcode, other firmware support for hardware variations must be held inROM and applied during firmware initialization. Unlike CPU microcode, thesevariant initializations change frequently. In order to maintain a single BIOSimage, these configurations are typically held in an external, electricallyerasable programmable read-only memory (EEPROM) and accessed through a serialinterface. It is common for firmware to treat the EEPROM as if it were RAM andto access variables in it as needed throughout POST.

· Since the EEPROM access is muchslower than RAM, configuration data should be read all at once, and then cachedin memory.

· The time savings for HWconfiguration was 100 msec.

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

· Our prototype did notinvestigate the impact of multi-threading, but subsequent investigations willdo so.

· Note that synchronizationprimitives are not available and UEFI protocols are not guaranteed to runproperly across multiple threads or processors (“ MP-safe”), so the burden ofbuilding multi-threaded firmware would largely fall on firmware writers toredesign their code in implementation-specific ways until the UEFI PlatformInitialization Specification is modified to support this.

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

· PS/2 devices. Many chipsets includesupport for a pair of PS/2 devices, this being intended for keyboard andpointing devices. However, PS/2 initialization is slower than USBinitialization.

· Blade included PS/2 devices forthe internal keyboard matrix and for the touchpad. This investigation did notimplement a keyboard or touchpad without PS/2 support. The time savings for sucha system is estimated to be about 50 msec.

· Although PS/2 devices have slowinitialization, USB devices that support PS/2 are disruptive to developersbecause the emulation is usually driven by system management interrupts (SMIs),which interfere with proper operation of debuggers. The ideal implementation isone in which PS/2 support in a USB device is implemented by native UEFI driverswithout any dependency on System Management Mode (SMM).

· Option ROMs. Video, Universal NetworkDevice Interface during PXE (PXE UNDI), and storage controller devices ofteninclude their own ROM with BIOS extensions. These usually are in the option ROMform. Option ROMs are a de facto standard but in practice have wide variationsof form and performance. For best performance, PXE UNDI, SATA, and videodrivers should be provided as UEFI drivers, not as option ROMs.

· Blade included option ROMs forvideo and SATA. This investigation did not implement native UEFI video or SATAROM. The time savings for a native UEFI system is estimated to be between 0.5sec and 1.0 sec.

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

· Blade did not include excessinitialized SATA channels. If it had, the time savings is estimated to be about800 msec in firmware and 2.0 sec in Windows boot time.

· Blade has its optical diskdrive (ODD) on SATA port 4/5. This was done by design because the firmwaretakes 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 whetherit is bootable. It takes 2–4 seconds for DVD/CD devices that have long latency times to spin upthe rotating media.

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

· Some OEMs prefer to set the DVDdrive as the default boot device because users who are unable to boot from aDVD might not know how to change the default boot settings and might generate asupport call. To avoid this, our prototype includes a predefined hotkey thatprovides the option to boot from DVD. If the user presses the hotkey duringPOST, the DVD is selected as the boot device. The hotkey should be displayed asearly as possible and the time-out value kept short, or the hotkey featureitself will contribute boot delay.

· Booting from USB requires thatthe USB boot device be detected during DXE, which is a timing trade off. Wesuggest that detection of a USB boot device be performed only if USB boot isselected by the user.

· During all on and offtransitions (such as power on, resume from S3 sleep, and resume from S4hibernate), boot media should be spun up as early as possible duringinitialization to reduce I/O latencies.

· SSD to replace HDD.

· All on and off transitions canbenefit from solid-state memory to store the system volume, rather than arotating storage device, to avoid spin-up latency.

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

Other Performance Improvements

· Compiler optimizations. Carefullyexamine the impacts of any compiler optimizations when building a productionBIOS. 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 andcharger, checks the initial thermal state, and can also implement otherfeatures such as the power button, lid button, and CD drive. The spec of thiscontroller is generally proprietary to an ODM. The features of the controllerand its firmware are not exposed to the BIOS firmware or to the operatingsystem.

· 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 microcontrollerinstructions.

· 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-costoption, which requires fewer memory devices. However, because BIOS is mappedinto the LPC bus, the early stages (before decompression and caching) are morecomplex and run more slowly. Figure 2 shows the higher-performing, higher-costoption.

· For our investigations, Insydeasked 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 sectiming improvement with option two.

· This improvement was specificto Montevina, but in the future chipsets designers must also examine thetradeoff of performance for cost based on the product segment, and not simplychoose the lowest cost option for all designs.

UserExperience Improvements

In addition to performance improvements,our goal was to align the appearance of the firmware to support OEMcustomization and better match the Windows 7 boot experience. We alsoinvestigated the impact of fan noise on experience.

Visual Improvements

Boot Graphics Timing

The Windows 7 boot experienceprovides a much smoother transition from the initial POST screen to the desktopand improves graphics fidelity during boot by eliminating the unnecessarytransitions in display modes that were part of the Windows Vista bootexperience.

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

· T1. Firmware initializes the graphicsdevice, sets the device to a graphics mode, and then displays the initial POSTsplash screen.

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

· T3. (optional)Option ROM initializes various devices, such as network boot or RAID storagecontroller, 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 thecontrol of the graphics device transitions to the kernel.

· T6. The native kernel driverre-initializes the graphics device to native mode before displaying the logonUI or desktop.

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

Boot Graphics Improvements

· Graphics initialization. Desktopfirmware typically assumes that the display type is unknown, option ROMs willbe in the system, and text mode output will be required. As a result, firmwareusually initializes in a low-resolution mode, and then makes transitions in andout of text mode, resulting in flashing screens, blank screens, or flashingcursors. These assumptions generally do not apply to laptops or all-in-onedesktop designs.

· Blade has a native panelresolution of 1280 × 800 pixels and supports 32-bit color. Because we did notyet 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 panelresolution (1280 × 800 × 32) and also 1024 × 768 × 32 resolution.

· In both cases the operating system screenresolution was set to a maximum of 1280 × 800 × 32. In both cases screen imageswere deemed to be superior to the factory default.

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

· High-resolution boot image. Firmwaretypically displays a low-fidelity image (usually a logo) at boot. Ahigh-fidelity image is not usually an option due to the low resolution of thegraphics system during boot.

· Initially we sought to displaya boot image at full native screen resolution (1280 × 800 × 32 bit) but we hadlimitations of ROM space. Rather than rewrite more of the BIOS to allow forgreater image storage, we experimented with greater JPEG compression ratios. Wediscovered that higher compression sometimes looked worse than lowerresolution, and that the best tradeoff was image dependent (some images lookedgood only at low compression and high resolution, whereas others were moreflexible).

· Ultimately we decided to use1024 × 768 × 24 bit as our standard image setting.

Performance Impacts of Visual Improvements

· Graphics overhead. Initialization of thegraphics in high-resolution mode early in boot requires changes to PEI and DXE.If initialization is not early enough, the user cannot discern the highfidelity of the boot image. Initialization of the graphics also adds someprocessing overhead to detect which graphics configuration to use, to set upthe graphics modes, and to send the image to the controller, all of which arenormally deferred until the operating system boots.

· In our prototype graphics,overhead added 800 msec. It is likely that this time can be improved withfurther optimization of the firmware.

Fan Noise

· Default fan settings. Many systems havethe fan on all the time as a default setting. Users who cannot find the fanfeature in the BIOS menu may complain about the fan noise.

· In our prototype we did notchange 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 shouldnot exceed 22 dB.

Windows Access to FirmwareSettings

Problem Overview

Typical firmware allows the user tochange BIOS settings by pressing a hotkey during BDS to access a special BIOSboot menu. This is a vestige of the PC’s history as a scientific andengineering instrument, but should be considered an advanced featureimpractical for most consumers to use.

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

Windows Interfaces to Firmware

· WMI. Windows already maintains limitedaccess to ACPI firmware via Windows Management Instrumentation (WMI). Thisallows Windows to see BIOS events and Advanced Configuration and PowerInterface (ACPI) settings.

· In our prototype we addedadditional capability to manipulate the WMI MOF object withGet_NV_RAM_Variables and Set_NV_RAM_Variables to change the boot ordersettings.

· This capability can be extendedto manipulate other firmware settings. Because we now support high-fidelityboot 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 fullUSB discovery) might be another option.

· Win32. Windows Server® 2008 and 64-bitversions of Windows Vista can access UEFI firmware directly with the Win32calls to EFI services such as GetVariable()and Set Variable().

· In our prototype we initiallyintended to use these Win32 calls rather than WMI but determined that thefirmware rewrite would be significant and the result would be a proprietary APIbecause there is no industry standardization for this yet, whereas the WMIinterface is already available. As a result we have deferred this effort.

Accessing Firmware from Windows

· Windows Control Panel. Windows ControlPanel is easily extensible and already many users are aware that they should goto Control Panel to change PC settings. As such, Windows Control Panel is alogical place to give users control over firmware settings such as boot orderand boot image.

· We did not prototype a WindowsControl Panel extension to expose this functionality. We cannot guarantee thatfuture versions of Windows will continue to support such extensions.

· The Windows Advanced System Properties page orMSconfig.exe might also be candidates for hosting this configuration UX, butthese choices would need to be supported by the Windows team as part of a majorrelease, and could not be selectively added by an OEM.

· Windows-based application. OEMs commonlyship software with their hardware to add value. An OEM-branded application thatallows the user to change firmware settings might be more discoverable andusable for a typical user than a custom control panel extension.

· Insyde wrote a test applicationto verify the WMI interfaces to change the boot order and boot image. We mayfurther 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 devicesattached to PCs. Although intended for identifying and managing devices, DeviceStage may also be an appropriate discoverable point for adding firmwareconfiguration UI due to OEM familiarity with customization capabilities.

· We did not prototype a WindowsDevice Stage experience to expose this functionality.

· Windows PE. OEMs sometimes boot intoWindows Preinstallation Environment (Windows PE) in order to applyconfiguration data and bug patches to a Windows image without performing a fullboot. Both WMI and Win32 interfaces can be accessed from Windows PE in order toallow factory-floor configuration of firmware settings. This can be done tomake boot images model-specific and to reduce the amount of configuration datathat must be maintained in the generic ROM images.

· We did not prototype with WindowsPE 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 systemsoffer ODMs a cost reduction option if the embedded controller and BIOS sharethe same ROM. The timing impact is substantial (0.5 sec in one case and 2.0 secin the other) as is the cost savings (about US$0.25 per unit in the sloweroption). Other chipsets may offer different tradeoffs than shared ROM. It’simportant that when systems are specified that ODMs know which tradeoff to takeand not let the ODMs simply take the lower cost option by default.

· ROM size. Storing high-resolution imagesin ROM may become costly if the same firmware is used across multiple SKUs anda larger ROM is required to store multiple images for the various SKUs. See “EngineeringProcess Impacts,” below.

Engineering Process Impacts

· Managing a single firmware version for multiple SKUs. Limiting the number of CPU microcode and video driver options thatare stored in the ROM may expose manufacturers to increased versioning. This isalso true for storing multiple boot graphics. The tradeoffs are multipleversions versus larger ROM versus accessing firmware interfaces via Windows PEduring an additional manufacturing step. Each manufacturer will need todetermine which trade off is appropriate for each product family.

Appendix 2: UEFI-OnlyFirmware

Today’s firmware is typically a mix of UEFIwith earlier components. As Windows operating systems that support native UEFIbecome pervasive, this will give way to UEFI-only firmware implementations.Today only Windows Server 2008 and 64-bit editions of Windows Vista with ServicePack 1 support native UEFI; 32-bit versions of Windows 7 also do notsupport native UEFI.

A mixed firmware implementation includesa Compatibility Support Module (CSM). Because the CSM adds I/O overhead duringboot, a UEFI-only implementation will save 1–2 additionalseconds.

A UEFI-only firmware code base wouldallow creation of a single EFI Byte Code (EBC) driver for each piece ofhardware, regardless of CPU architecture. Other advantages include the modulardesign of UEFI, which would allow OEMs to more easily mix and match offeringsfrom multiple vendors while porting enhancements and bug fixes to newplatforms.