UEFI启动流程图.pdf-资料库

johanhsu-3676261-4744300845402652350.pdf-第1页.png

第1页 / 共25页

johanhsu-3676261-4744300845402652350.pdf-第2页.png

第2页 / 共25页

johanhsu-3676261-4744300845402652350.pdf-第3页.png

第3页 / 共25页

johanhsu-3676261-4744300845402652350.pdf-第4页.png

第4页 / 共25页

johanhsu-3676261-4744300845402652350.pdf-第5页.png

第5页 / 共25页

johanhsu-3676261-4744300845402652350.pdf-第6页.png

第6页 / 共25页

johanhsu-3676261-4744300845402652350.pdf-第7页.png

第7页 / 共25页

johanhsu-3676261-4744300845402652350.pdf-第8页.png

第8页 / 共25页

White Paper Michael A. Rothman BIOS Architect Intel Corporation Reducing Platform Boot Times UEFI-based Performance Optimization June 2009 4 322253

Reducing Platform Boot Times Executive Summary This document presents a series of methods that should enable a BIOS engineer to optimize the underlying platform BIOS so that it can reduce a platform’s boot speed. However, it should be noted that the intent of this whitepaper is to illustrate how various, seemingly unrelated, product requirements can greatly affect the resulting platform boot performance. That being said, this whitepaper discusses how the platform design, based on marketing requirements and coupled with a properly constructed UEFI-compliant BIOS, can greatly affect the performance characteristics of a platform. Some of the key points in this white paper:  How specific marketing requirements affect boot performance  Suggestions on what BIOS engineering choices can be made to optimize for a given platform requirement.  Provide a realistic view of what performance enhancements can be done in a production BIOS.  Establish viable next steps. The Intel® Embedded Design Center provides qualified developers with web-based access to technical resources. Access Intel Confidential design materials, step-by step guidance, application reference solutions, training, Intel’s tool loaner program, and connect with an e-help desk and the embedded community. Design Fast. Design Smart. Get started today. www.intel.com/embedded/edc. § 2 322253

Reducing Platform Boot Times Contents Background ............................................................................................................................4 Proof of Concept .....................................................................................................................7 Marketing Requirements ..........................................................................................................8 Additional Details .................................................................................................................. 13 Conclusion ........................................................................................................................... 16 Reference Documents ........................................................................................................... 19 322253 3

Background This document will focus on specific aspects of a platform’s pre-OS boot behavior and leverage concepts that are based on the UEFI BIOS architecture for which details can be found at www.uefi.org. Some of the fundamental concepts that need to be understood are different phases of platform initialization and how they are exercised as part of the platform boot process. Figure 1, Figure 2, and Figure 3 illustrate the evolution of the platform initialization from the first moment that power is applied until the point where the BIOS hands-off to the target OS: Figure 1. SEC Phase 4 322253 Switch to protected modeTransition to a non-paged flat-model protected modeInitialize MTRRs for BSPSet cache states for various memory ranges to a known state.Microcode Patch UpdateExecute Microcode Patch Update for all of the present CPUs. (Common process, but an optional behavior in closed-box controlled configuration systems)Initialize No-Eviction Mode (NEM)Prior to the discovery of memory on the platform, a data area will be established within the CPU cache so that a stack-based programming language can be used early in the initialization.Various early BSP/AP interactionsA series of standard steps which contain some fixed delay events such as:Send INIT IPI to all APsSend Start-up IPI (SIPI) to all ApsCollect BIST data from the APsHand-off to PEI entry pointReset VectorFlush cache and jump into main initialization routine in the ROM.

Reducing Platform Boot Times Figure 2. PEI Phase 322253 5

Figure 3. DXE and BDS Phase Reducing Platform Boot Times The remainder of the document focuses on the important elements when considering how to best optimize some of the aforementioned behavior so a platform meets both its technical and marketing requirements yet achieves an optimal boot speed. 6 322253 Establish DXE infrastructureThe Driver eXecution Environment (DXE) is established based on the discovered resources described by the prior PEI phase of operations. This includes DXE core callable interfaces, event services, and the eventual launch of the DXE dispatcher.Hand-off from PEI to DXE CoreDashed Boxes or lines are informational.DXE DispatcherThe dispatcher is tasked with the job of discovering the FV (firmware volume) components that are available and processing them. Each of the discovered drivers within the FV is scheduled to be launched if and when their dependencies are met. Once a driver is scheduled to run, the dispatcher will proceed to launch the scheduled drivers and continue to do so until there are no more scheduled drivers.Boot Device Select PhaseBased on the programmed boot variable, the Boot Device Select (BDS) phase ultimately will attempt to connect the boot devices required to load and invoke the selected boot target (e.g. O/S). This usually encompasses a recursive search for additional FVs and content to dispatch from them. Can the boot target be loaded?Architectural ProtocolsSome of the key drivers needed for the core to operate. Some of these are the BDS, CPU, Timer, etc.Discovered ComponentsDuring the search for FVs, various drivers can be discovered and potentially launched. Some of these drivers are components such as network drivers, I/O drivers (e.g. USB/PCI), and any OEM or platform specific drivers.Dispatch new DXE driversDispatch content from discovered FVs.Are there more boot options to try?NoYesYesHand-off to the Boot TargetLoad new boot optionYesHave we made progress since last attempt?NoYesPlatform PolicyWhen no viable boot options exist, the platform will have some built-in boot behavior that is specific to the manufacturer of that platform.

Reducing Platform Boot Times Proof of Concept In the proof of concept for this paper, the overall performance numbers used are measured in microseconds and the total boot time is described in seconds. Total boot time is measured as the time between the CPU first having power applied and the transferring of control to the boot target (which is typically the OS). This particular white paper does not focus on the specifics of the hardware design itself since the steps that are described are intended to improve boot time regardless of what platform is being used. For the purposes of this white paper, we used a system with these components:  1.8Ghz Intel® Atom™-based netbook design  1GB DDR2 memory  2MB Flash  Western Digital* 80GB Scorpio Blue 5400RPM drive (standard configuration)  Intel® Solid State Drive X25-E (Intel® X25E SSD) (in performance configuration) It should also be noted that this proof of concept was intended to emulate real-world expectations of a BIOS, meaning that nothing was done to achieve results which could not reasonably be expected in a mass-market product design. The steps that were taken for this effort should be easily portable to other designs and should largely be codebase independent. Figure 4 provides the performance numbers achieved while maintaining all of the various platform/marketing requirements for this particular system. Figure 4. Performance Measurement Results – Before/After The next sections detail the various decisions that were made for this proof of concept and how they improved the boot performance. 322253 7 SEC Phase Duration : 26419 (us)PEI Phase Duration : 763315 (us)DXE Phase Duration : 443021 (us)BDS Phase Duration : 766778 (us)Total Duration : 1.999533 (s)SEC Phase Duration : 26342 (us)PEI Phase Duration : 1230905 (us)DXE Phase Duration : 998234 (us)BDS Phase Duration : 7396050 (us)Total Duration : 9.651531 (s)Normal BootOptimized Boot

Reducing Platform Boot Times Marketing Requirements Marketing requirements may not be the first thing that comes to mind when an engineer sits down to optimize a BIOS’s performance. However, the reality is that marketing requirements form the practical limits for how the technical solution can be adjusted. The highlighted requirements are the pivot points in which an engineer can make decisions which will ultimately affect performance characteristics of the system. Since this section details the engineering responses to marketing- oriented requirements, it does not provide a vast array of code optimization “tips”. Unless there is a serious set of implementation bugs in a given codebase, the majority of boot speed improvements are achieved from following the guidelines provided in this section. There are codebase- independent “tips” included in this document which provide additional help. What are the design goals? How does the user need to use the platform? Is it a “closed box” system? Is it a traditional desktop? Is it a server? How the platform is thought of will ultimately affect what the user expects. Making conscious design choices to either enable or limit some of these expectations is where the platform policy can greatly affect the resulting performance characteristics. Platform Policy One of the first considerations when looking at a BIOS and the corresponding requirements are whether or not an engineer can limit the number of variables associated with what the user can do “to” the system. For instance, it might be reasonable to presume that in a platform with no add-in slots, a user will not be able to boot from a RAID controller since the user cannot physically plug one in. This is where a designer enters the zone of platform policy. Even though a platform may not expose a slot, the platform might expose a USB connection. A conscious decision needs to be made for how and when these components are used. A good general performance optimization statement would be: “If you can put off doing something in BIOS that the OS can do – do it!” Since a user can connect anything from a record player to a RAID chassis via USB, the user might think that they would be able to boot from a USB- connected device if physically possible. Though this is physically possible, it 8 322253

资料库

UEFI启动流程图.pdf

相关推荐

开发技术

热门标签

最新资料