Fastboot BIOS. An Investigation of BIOS Speed Enhancement Featuring the Intel Atom Processor

Transcription

1 White Paper Intel Corporation Embedded and Communications Group Fastboot BIOS An Investigation of BIOS Speed Enhancement Featuring the Intel Atom Processor Abstract: In order to meet the needs of today s embedded customers, faster BIOS boot times are required. This paper documents the investigation/poc involving enabling a sub 2-second EFI BIOS boot time on embedded platforms featuring the Intel Atom processor. This document discusses background, methods, data gathered, and next steps. Mike Kartoz, Pete Dice, and Gabe Hattaway, Intel Corporation Data Measurements coordinated by Wade Zehr, Intel Corporation September 2008 Document number

2 Contents Background... 2 Proof of Concept... 3 Data Collected Initial Configuration Turn Off Debugging Decrease Flash Size Caching of PEI Phase Intel SpeedStep Technology Enabled Early BDS Optimization Platform Memory Speed Remove PS/2 Keyboard/Mouse Remove BIOS Setup Remove Video Option ROM Remove BIOS USB Support... 6 Discussion of Results... 6 Next Steps...6 Conclusion... 7 Reference Documents... 7 Authors and Acronyms... 9 Background This document provides guidance on optimizing the boot flow for UEFI-compliant firmware and expands on ideas introduced in an Intel developer forum course of the same name. Although the document is tailored toward embedded markets, many of the concepts discussed are relevant to all Intel Corporation Markets that have a BIOS. Any platform can be a UEFI compliant device when UEFI-defined interfaces are exposed per HW feature. UEFI does not require PC features. Developers can use defined UEFI APIs to abstract standard subsystem, or create Platform Initialization Specification compliant drivers for nonstandard buses and devices. There is a stark contrast between embedded devices and standard PCs. An embedded device is a normally closed box system which does a specific function well. In embedded devices, there are often no expansion slots, proprietary operating systems, and a limited number of applications. The use case is singular: turn it on and use it. The standard PC is the definitive open box system, providing broadest possible solution. With multiple standard interfaces, host mainstream OS, and numerous applications, the PC BIOS has been designed to enable all components on the system, scan every interface, and be ready to run multiple applications simultaneously. Embedded devices have unique requirements which challenge one size fits all PC BIOS solutions, but the UEFI Frameworks can provide flexible solutions whose behaviors can be differentiated for embedded production solutions. That flexibility creates innovation opportunities for OEM, software vendors, system integrators, and end-users in the embedded space. Specifically in regards to firmware, embedded market customers have come to expect a very light weight firmware solution and very rapid firmware boot time on their processor architectures. The typical UEFI BIOS, on the other hand, has a boot time on the order of 15 to 45 seconds. Intel Corporation BIOS solutions have traditionally focused on meeting all customer needs with one solution. The Intel Atom processor was used as the starting point since it is a revolutionary new piece of silicon but the Fastboot BIOS can be adapted to other platforms as well. Intel s attempt to enter 2 Document number

3 new markets with this platform warranted the need for new software to meet customer needs. With the Fastboot, we have attempted to provide speed, reliability, and full functionality. This paper attempts to address how these results were achieved and how the results can be reproduced. It shows modules that were removed and the amount of time that each one saves from the boot sequence. It also provides some of the optimizations that were implemented in order to achieve that time. We hope that it is useful to those that would attempt to reproduce the same results. From a marketing standpoint, it also allows embedded customers to make an easier transition from a non-ia system architecture to an IA-based system since it meets more of the market demand for boot speed. It also enables BIOS vendors to support customer requirements for faster BIOS boot times. Proof of Concept Note that this paper assumes that the reader is already familiar with UEFI compliant BIOS terminology and concepts. See the list of references for further details on UEFI. Boot time is defined, in this paper, as the time between the CPU reset vector and transfer of control to the OS bootloader. This implies that the first sector of the bootloader has already been fetched into memory. It further implies that no additional sectors of the bootloader have been loaded nor has any portion of the actual OS kernel been loaded. During this investigation, early changes in boot time were measured using a wall clock. As boot time decreased, using the wall clock quickly became inadequate in getting the precision necessary. Another mechanism used during early investigation was the Intel Processor Time Stamp Counter (TSC). The TSC was good for early work to get a general idea of how much relative time each portion of the BIOS was taking. However, the TSC varies in speed depending on processor configurations such as Intel SpeedStep technology and turbo mode. Later effort centered on the use of hardware based measuring techniques. There are add-in cards that can be used for this purpose but our team opted to use a logic analyzer connected into the postcode display hardware present on the Crown Beach board in conjunction with additional calls to I/O port 0x80 added to the code. Specifically, a post code was added at the point at which the BIOS hands off control to the first sector of the Operating System bootloader. During early investigation, the TSC was added onto all of the framework BIOS serial print messages. While the use of these serial print messages takes quite a bit of time in itself, looking for larger time gaps was quite effective in tracking down areas that were taking a longer time to execute. Additional serial print messages were added to further narrow these down. Data Collected Table 1 depicts the results of the boot time investigation, followed by in-depth discussion of each change. Table 1. Boot Time Results Change Boot Time (in sec) Incremental boot time improvement (in sec) Discussion Paragraph Initial Configuration Turn off debugging Decrease flash size Caching of PEI phase Document number

4 Change Intel SpeedStep technology enabled early Boot Time (in sec) Incremental boot time improvement (in sec) Discussion Paragraph BDS Optimization (boot devices) Platform memory speed Remove PS/2 Keyboard/Mouse Remove BIOS setup Remove video Option ROM Remove BIOS USB support Initial Configuration Measurements were taken starting from a configuration based on the original AMI Aptio Intel Atom processor BIOS leveraged from UMG. In its original configuration, the boot time was 12 seconds. This was done on a Fab F UMG Intel Atom Processor Z5XX Series and Intel System Controller Hub US15W Development Kit board with stepping D1 of Intel System Controller Hub US15W chipset, C0 of Intel Atom Processor Z530/Z510, 2MB ST flash part, and 512MB memory module running at 400MHz. 2. Turn Off Debugging Turning off debugging removes the serial debugging information and turns on C Compiler optimizations. Because Framework BIOS is almost entirely written in C instead of previous BIOS which was written in assembly language, enabling compiler optimizations is particularly useful. Note: Some latent bugs were found that only show up when optimizations are enabled. Rigorous validation is recommended after enabling optimizations. EFI BIOS makes extensive use of spewing debugging information over a serial port to aid development and debug of the BIOS. While this debugging information is valuable in a development environment, it can be eliminated in a production environment. In addition to the boot time improvements realized, there are also IP considerations to shipping a higher level language developed BIOS that has debugging information enabled. Likewise, compiler optimizations must be disabled when it is desired to perform source level debug of the C language BIOS code. However, in production this can be eliminated. 3. Decrease Flash Size This step represents modifying the BIOS build process to use a 1MB flash part instead of the original 2MB flash part. This includes decreasing the number of flash blocks used in the board process. The framework BIOS uses a flash file system to store PEI and DXE modules as well as other entities. Decreasing the number of blocks in this file system improves the access time each time that a module is accessed. Note: Should the platform permit, additional time could be saved beyond what was collected in this effort by further decreasing the number of flash blocks as components (modules) are removed or reduced in size. It is likely, though, that the additional possible savings here are negligible. 4 Document number

5 4. Caching of PEI Phase Many of the PEI modules in framework BIOS must be executed prior to platform memory being initialized. Once memory is initialized, the remaining portions of the BIOS are copied to system memory and executed out of memory. Because the framework BIOS uses cache-as-ram (CAR) for pre-memory storage and stack, it runs all of the PEI modules in place directly from the flash part without caching. It is possible, however, on the Intel Atom processor to simultaneously enable CAR plus one 64kB region of normally cached address space. The BIOS must be arranged in such a way to take full advantage of this one pre-memory cacheable region. This means having a separate flash filesystem used exclusively by the PEI modules that are run prior to memory initialization and placing that filesystem in the region that will be cached. By employing this technique to cache the portion of the flash part that includes the PEI modules that will execute prior to initialization of memory, performance is increased. For this effort, the 64kB region was not able to cover all of the PEI modules. Through further reduction in size of PEI, more improvement is possible. 5. Intel SpeedStep Technology Enabled Early Intel SpeedStep technology is a power savings technology that is used to limit the processor speed based on current software demand on the system. When the system is in heavy use, the processor is run at full speed. At idle and near idle, the system is run at slower speed steps. The BIOS role in initialization of Intel SpeedStep technology includes detection of Intel SpeedStep technology capabilities, initialization of the processor speed for all processor threads, and advertisement of speedstep capabilities to the operating system. The above initialization of all processor threads is typically to the power on speed which is normally equal to the lowest supported speed. This is to potentially ensure increased stability during the boot process. The operating system will then enable the faster steps. To increase boot speed, the BIOS can, instead of enabling the power on feature of Intel SpeedStep technology, enable the highest speed setting. This not only increases the speed of the processor during BIOS post but also increases the speed of loading the operating system. 6. BDS Optimization The framework BIOS BDS phase normally looks for potential boot devices from hard drives, CD- ROM drives, floppy drives, and network. On the investigation platform, the requirements were for boot from hard disk. This optimization removes the BDS checks for boot devices on CD-ROM, floppy, and network since they are not supported on this platform. If the operating system is being loaded from flash instead of hard disk, hard disk would be replaced with an optimized flash boot. 7. Platform Memory Speed Noticeable boot time improvement was realized by using the highest memory speed supported on the platform. On platforms featuring the Intel Atom processor, this is determined by a set of jumpers on the board. On other platforms this may be a setting in BIOS setup. 8. Remove PS/2 Keyboard/Mouse Initialization of the PS/2 Keyboard and Mouse in BIOS takes a considerable amount of time due to the specification of these devices. This eliminates the possibility of interacting with the BIOS during BIOS post and operating system loader. If BIOS setup has been removed as discussed below, user input is not needed during BIOS. On a fielded embedded device, keyboard and mouse are typically not needed and therefore do not need to be initialized. During device development and debug this feature might be better left on until the device is operational. 5 Document number

6 9. Remove BIOS Setup During the boot process, the BIOS provides an opportunity for the user to hit a hot key that terminates the boot process and instead displays a menu used to modify various platform settings. This includes settings such as boot order, disabling various processor or chipset features, modifying media parameters, etc. On an embedded device, BIOS setup (and any similar settings provided by an operating system loader) is more of a liability since it gives the end-user access to BIOS features that are potentially untested on the device. It is better to have a set of setup options that may be chosen at BIOS build time. Removal of BIOS setup also saves significant BIOS post time. 10. Remove Video Option ROM The video option ROM on platforms featuring the Intel Atom processor and many other newer platforms is quite slow due to the many different video interfaces that must be supported and the display detection algorithms that must be employed. Replacement of a highly optimized DXE video driver in place of the video option ROM saves significant boot time. The speed of this optimized DXE video driver is highly dependent on the exact display chosen and video features required by the platform prior to installation of the operating system graphics driver. On the investigation platform, a fixed splash screen was displayed. The fixed splash screen was unchanged during the boot process until the operating system graphics driver initialized the display. To achieve this, the capability to display text was removed from the DXE graphics driver. As a result, none of the normal BIOS or operating system initialization messages is displayed. This yields additional performance and a cleaner boot appearance. 11. Remove BIOS USB Support Since USB boot and USB input devices (keyboard/mouse) were not requirements on the investigation platform, initialization of USB was completely removed from the BIOS. USB is still available from the operating system once the driver is loaded but not during BIOS or OS loader. Discussion of Results From the investigation performed, the greatest improvement of BIOS boot time (more than 3 seconds) is obtained by disabling debug. This step is appropriate for all BIOS implementations, not just embedded. Not only does this optimize boot times but it also aids in IP protection. In general, removal of unneeded functionality is an easy way to achieve faster boot times. In this investigation, replacing the video option ROM, and removal of BIOS setup and USB support together resulted in a time savings of over 4.5 seconds. Next Steps The following are additional considerations and possible areas for investigation for further reduction of framework BIOS boot times. Remove unnecessary microcode. In a typical BIOS microcode updates (processor patches) are included for many different processors that are supported on the platform. For a specific configuration of an embedded device, it is possible to remove most of these microcode updates which are each 2kB to 5kB in size. Investigate flash file system object compression. Compression results in fewer reads necessary from the flash part resulting in faster boot. Conversely the processor must then perform the decompression which takes additional time. On faster processors, compression is likely to reduce boot time. 6 Document number

7 Some improvement of boot time appears to be possible by optimization of flash access. One area for optimization is ensuring that decompression only reads each flash byte one time. Not all decompression methods do this by default. This can be avoided by modifying the decompression algorithm or by simply buffering the object to memory prior to decompression. Improve flash access by reordering the PEI modules. A bigger improvement to flash access is possible by reordering the PEI modules in the flash part so they are executed in order and by modifying the PEI dispatcher to remember where the last access came from and resume search from that point. Currently, the dispatcher searches for each module starting from the beginning of the flash file system. In addition, module dependencies can result in multiple searches occurring for each PEI modules executed. Make sure that recurring writes to the flash part are removed. While the writes themselves take significant time, the biggest hit occurs when the flash file system requires garbage collection to free space. The erases necessary can take seconds. Eliminate BIOS clearing of the first 640kB of memory. On the Intel Atom platform, some of this clearing was necessary to proper operation (probably due to the implementation of the 16bit legacy core), however most could be eliminated. Clearing all of 640kB took over 100 msec on the Intel Atom processor. A mechanism is required for directly booting an operating system from flash instead of from a hard drive. This is a more typical configuration for embedded devices. Further optimization possible by removing hard drive and booting from an operating system embedded in a flash part. This capability is known to exist and just needs to be added here. Conclusion Achieving a sub-2 second boot time with EFI BIOS is not difficult. While many of the methods used are specific to embedded markets (removal of features), several other methods are optimizations useful for all BIOS markets. From this investigation, it seems likely that sub-1second boot time is attainable without changing the overall architecture or features of the BIOS. In general, space equals time. Every byte that is included in the BIOS image will be read at some point (in some cases more than once). More reads from the flash part results in longer boot time. Caching or the flash part helps but does not negate this affect. Reference Documents Document ECG EFI/BIOS Industry Survey Platform Init Specification UEFI Specifications Location hronid=09005ffd a&ver=current&qepop=false This is the PEI, DxE, and HoBs stuff This is the OS interface and runtime EFI stuff. Tiano Core Features you want to know about, to adopt EDK II open source framework portions of Tiano EFI Shell basics about building a shell EFI SCT - self compliance testing for UEFI spec EFI Toolkit - contains source code and documentation that enables rapid 7 Document number

8 Document Location development of EFI based applications, protocols, device drivers, EFI shells, and OS loaders. UEFI and Windows BIOS Boot Specification v1.01 System Management BIOS Reference Specification Apple Universal Binary ACPI Specification PCI Specifications USB Specification Compact Flash Specifiction Serial ATA ONFI Nand Specifications ws.mspx; Microsoft s view of a BIOS, a bootloader and UEFI Specs/PC+Industry+Specifications.htm This is a lot of miscellaneous stuff we shouldn t have to do any more Specs/PC+Industry+Specifications.htm This is a nice to have for any client controlled by IT al_binary/universal_binary.pdf ; OS X is a consideration, good ideas about PPC to Intel x86 conversion Advanced Configuration and Power Interface. (PCI conventional, IO Virtualization, PCI Express) Plug-and-Play Specification HPET Specification Authors and Acronyms Authors Michael Kartoz is a BIOS Architect with the Embedded and Communications Group at Intel Corporation. Pete Dice is an Architecture Manager with the Embedded and Communications Group at Intel Corporation. J. Gabriel Hattaway is a Software Program Manager with the Embedded and Communications Group at Intel Corporation. Wade Zehr is a BIOS Engineer with the Embedded and Communications Group at Intel Corporation. 8 Document number

9 Acronyms ACPI: Advanced Configuration and Power Interface. See AL: Afterlife phase. Power down phase AML: ACPI Machine Language API: Application Program Interface. Programmatic interfaces for the firmware (as opposed to Win32-type OS-level APIs). a priori file: A file with a known GUID that contains the list of DXE drivers that are loaded and executed in the listed order before any other DXE drivers are discovered. Artifact: Something tracked in CEE Project Tracker ASL: ACPI Source Language Attribute: A field of something tracked in CEE Project Tracker BA: Boot Authorization BBS: BIOS Boot Specification BDS: Boot Device Selection phase BFV: Boot Firmware Volume. Code (i.e., PEI and PEIM code) that appears in the memory address space of the system without prior firmware intervention. See also FV. BIS: Boot Integrity Services BIST: Built-in Self Test BLT: Block Transfer (pronounced "blit " as in "slit" or "flit"). A series of functions that form the basis of manipulation graphical data. The operation used to draw a rectangle of pixels on the screen. BNF: Backus-Naur Form. A metasyntactic notation used to specify the syntax of programming languages, command sets, and the like Boot Device: The device handle that corresponds to the device from which the currently executing image was loaded Boot Manager: The part of the firmware implementation that is responsible for implementing system boot policy. Although a particular boot manager implementation is not specified in this document, such code is generally expected to be able to enumerate and handle transfers of control to the available OS loaders as well as EFI applications and drivers on a given system. The boot manager would typically be responsible for interacting with the system user, where applicable, to determine what to load during system startup. In cases where user interaction is not indicated, the boot manager would determine what to load and, if multiple items are to be loaded, what the sequencing of such loads would be. Boot Services: The collection of interfaces and protocols that are present in the boot environment. The services minimally provide an OS loader with access to platform capabilities required to complete OS boot. Services are also available to drivers and applications that need access to platform capability. Boot services are terminated once the OS takes control of the platform. BSD: Berkeley Software Distribution CEE: CollabNet Enterprise Edition COFF: Common Object File Format. An (originally) Unix *-based file format that is now recognized under several OSs. The format uses one or more header fields followed by the section data for the file Compatibility16: A traditional legacy BIOS with the POST and BIOS Setup code removed. Compatibility16 BIOS code executes in real mode 9 Document number

10 Compatibility BIOS: The combination of both EfiCompatibility and Compatibility16 CompatibilitySmm: Any IBV-provided SMM code to perform traditional functions that are not provided by EFI CPU: Central Processing Unit (or Processor). CRC: Cyclic Redundancy Check. A fixed-size error checking code appended to the end of a block of data (file) that is based on the content of the file CRTM: Core Root-of-Trust Module CSM: Compatibility Support Module. The combination of EfiCompatibility, CompatibilitySmm, and Compatibility16. Portion of the Framework that allows compatibility with non-efi compliant operating systems to run on Framework firmware CVDR: Configuration Values Driven through Reset Depex: Dependency expression. Code associated with each Framework driver that describes the dependencies that must be satisfied in order for that driver to run. Controls order of execution in a Framework dispatch of PEIM and DXE drivers Dispatch Entry Point: The entry point that the dispatcher invokes Driver: Modular chunk of firmware code that supports chipset or platform features. Reusable in multiple system contexts DXE: Driver Execution Environment phase DXE Foundation: A set of intrinsic services and an execution mechanism for sequenced control of driver modules DXE Services: Services, such as security services and driver services, that are usable by DXE drivers EfiCompatibility: EFI code that corresponds to EFI compatibility drivers, code that generates data for compatibility interfaces, or code that invokes compatibility services. Enhanced Intel SpeedStep Technology: allows the system to dynamically adjust processor voltage and core frequency, which results in decreased power consumption EDK: EFI Developer Kit EPL: Eclipse Public License FAT: File Allocation Table FAT32: FAT32 File System Driver FD: Firmware Device. A persistent physical repository that contains firmware code and/or data and that may provide NVS. For the purposes of this architecture specification, the topology of FDs should be abstracted via FVs. FFS: Firmware File System. A binary storage format that is well suited to firmware volumes. The abstracted model of the FFS is a flat file system Firmware Device: See FD. Firmware Volume: See FV. FIT: Firmware Interface Table.( Itanium systems only) Font: A translation between Unicode weights and glyphs. This "M" and this "M" and this "M" represent the same weight but in different fonts Foundation Code: The core interoperability interfaces between modules and in the Framework FPSWA: Floating Point Software Assist. (Itanium systems only) 10 Document number

11 Framework: short for Intel Platform Innovation Framework for EFI FS: Firmware Store. The abstracted model of the FS is a flat "file system" where individual files are SUMs FV: Firmware volume. There are one or more FVs in the FS. The FV containing the "reset vector" is known as the Boot Firmware Volume (BFV) GCD: Global coherency domain. The address resources of a system as seen by a processor. It consists of both system memory and I/O space Glyph: The graphical representation of a single Unicode weight GUID: Globally Unique Identifier. A 128-bit value used to differentiate services and structures in the boot services environment HII: Human Interface Infrastructure. A repository of configuration and translation information for localization. Typically used with boot manager and shell to provide a localized user interface. HOB: Hand-Off Block. A structure used to pass information from one boot phase to another (i.e., from the PEI phase to the DXE phase) IBV: Independent BIOS Vendor IFR: Internal Forms Representation. A binary encoding of forms-based display content and configuration information IHV: Independent Hardware Vendor IME: Input Method Editor Intrinsic Services: Services, such as security services and driver services, that remain available after the phase during which they are instantiated IP: Intellectual Property IPL: Initial Program Load. An architectural PEIM to PEIM interface that starts the DXE phase IPMI: Intelligent Platform Management Interface ISO 3166: An association between a country or region and a two or three character ASCII string ISO 639-2: An association between a language or dialect and a three character ASCII string Localization: Concepts by which an interface is made useful to users speaking different languages and from various cultures by adapting the interfaces to the user. "STOP" in English would be "ALTO" in Spanish and "СТОП" in Russian. Alphabetic on keyboards are local to the language and may be local to the country the keyboard is localized for. For example, a French keyboard in France is different from a French keyboard in Canada. LPC: Low Pin Count Bus. Replaced the ISA bus. MCA: Machine Check Architecture NMI: Non-maskable interrupt NRAM: Nonvolatile Random Access Memory NVS: Nonvolatile storage. Flash, EPROM, ROM, or other persistent store that will not go away once system power is removed ODM: Original Device Manufacturer OEM: Original Equipment Manufacturer OpROM: Option ROM OS: Operating System 11 Document number

12 PAL: Processor Abstraction Layer. A binary distributed by Intel that is used by the 64 bit Itanium processor family PCI: Peripheral Component Interconnect. See for more information. PCR: Platform Configuration Register PE/COFF: PE32, PE32+, or Common Object File Format. A defined standard file format for binary images PEI: Pre-EFI Initialization phase. Set of drivers usually designed to initialize memory and the cpu so that DXE phase can run. Usually the first set of code run starting from reset. PEI Foundation: A set of intrinsic services and an execution mechanism for sequenced control of PEIMs PEIM: Pre-EFI Initialization Module. Modular chunk of firmware code running in PEI that supports chipset or platform features. Reusable in multiple system contexts. PEI Services: Common services that are usable by PEIMs PHIT: Phase Handoff Information Table. A HOB that describes the physical memory used by the PEI phase and the boot mode discovered during the PEI phase. PIC: Position-independent code. Code that can be executed at any address without relocation POST: Power On Self Test PPI: PEIM-to-PEIM Interface Reverse Thunk: The code to transition from 16-bit real mode to native execution mode RSD_PTR: ACPI definition: Root System Description Pointer RT: Runtime phase. For EFI and the Framework this is after exit boot services has executed and the OS is in control of the system. Runtime Services: Interfaces that provide access to underlying platform-specific hardware that may be useful during OS runtime, such as time and date services. These services become active during the boot process but also persist after the OS loader terminates boot services. SAL: System Abstraction Layer. (Itanium systems only) SALE_ENTRY: System Abstraction Layer entry point. (Itanium systems only) Sandbox: The common properties of a driver or preboot environment that allow applications to run. These properties include a defined load image format and services that can run in the sandbox. SMI: System Management Interrupt SMM: System Management Mode SOR: Schedule on Request SSE: Streaming SIMD Extensions SUM: Separately Updateable Module. A portion of the BFV that is treated as a separate module that can be updated without affecting the other SUMs in the BFV. Tiano: Codename for the Intel Project to develop the Framework TE Image: Terse Executable image. An executable image format that is specific to the Framework. This format is used only in PEI and is used for storing executable images in a smaller amount of space than would be required by a full PE32+ image. Is a smaller more compact version of PE32. Thunk: The code to transition from native execution mode to 16-bit real mode 12 Document number

13 UNDI: Universal Network Driver Interface. Silicon specific driver in the preboot LAN stack that interfaces to SNP and PXEBC Unicode: A standard defining an association between numeric values known as "weights" and characters from the majority of the worlds currently used languages. See the Unicode specification for more information. USB: Universal Serial Bus. See for more information VFR: Visual Forms Representation. A high-level language representation of IFR VM: Virtual Machine VTF: Volume Top File. A file in a firmware volume that must be located such that the last byte of the file is also the last byte of the firmware volume VT-UTF8: A serial protocol definition that extends VT-100 to support Unicode Watchdog Timer: An alarm timer that may be set to go off. This can be used to regain control in cases where a code path in the boot services environment fails to or is unable to return control by the expected path. XIP: Execute In Place. PEI code that is executed from its storage location in a firmware volume 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 Intel Atom are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. *Other names and brands may be claimed as the property of others. Copyright 2008 Intel Corporation. All rights reserved. 13 Document number