White Paper Fastboot BIOS - Intel

Fastboot BIOS4. Caching of PEI PhaseMany of the PEI modules in framework BIOS must be executed prior to platform memory beinginitialized. Once memory is initialized, the remaining portions of the BIOS are copied to systemmemory and executed out of memory. Because the framework BIOS uses cache-as-RAM (CAR) forpre-memory storage and stack, it runs all of the PEI modules in place directly from the flash partwithout caching. It is possible, however, on the Intel ® Atom processor to simultaneously enableCAR plus one 64kB region of normally cached address space. The BIOS must be arranged in such away to take full advantage of this one pre-memory cacheable region. This means having aseparate flash filesystem used exclusively by the PEI modules that are run prior to memoryinitialization and placing that filesystem in the region that will be cached. By employing thistechnique to cache the portion of the flash part that includes the PEI modules that will execute priorto initialization of memory, performance is increased. For this effort, the 64kB region was not ableto cover all of the PEI modules. Through further reduction in size of PEI, more improvement ispossible.5. Intel SpeedStep ® Technology Enabled EarlyIntel SpeedStep ® technology is a power savings technology that is used to limit the processorspeed based on current software demand on the system. When the system is in heavy use, theprocessor 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 IntelSpeedStep ® technology capabilities, initialization of the processor speed for all processor threads,and advertisement of speedstep capabilities to the operating system. The above “initialization of allprocessor threads” is typically to the “power on” speed which is normally equal to the lowestsupported speed. This is to potentially ensure increased stability during the boot process. Theoperating system will then enable the faster steps.To increase boot speed, the BIOS can, instead of enabling the “power on” feature of IntelSpeedStep ® technology, enable the highest speed setting. This not only increases the speed of theprocessor during BIOS post but also increases the speed of loading the operating system.6. BDS OptimizationThe 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 forboot 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 beingloaded from flash instead of hard disk, hard disk would be replaced with an optimized flash boot.7. Platform Memory SpeedNoticeable boot time improvement was realized by using the highest memory speed supported onthe platform. On platforms featuring the Intel ® Atom processor, this is determined by a set ofjumpers on the board. On other platforms this may be a setting in BIOS setup.8. Remove PS/2 Keyboard/MouseInitialization of the PS/2 Keyboard and Mouse in BIOS takes a considerable amount of time due tothe specification of these devices. This eliminates the possibility of interacting with the BIOS duringBIOS 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 aretypically not needed and therefore do not need to be initialized. During device development anddebug this feature might be better left on until the device is operational.5 Document number 320497

Fastboot BIOS9. Remove BIOS SetupDuring the boot process, the BIOS provides an opportunity for the user to hit a hot key thatterminates 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, modifyingmedia parameters, etc. On an embedded device, BIOS setup (and any similar settings provided byan operating system loader) is more of a liability since it gives the end-user access to BIOSfeatures that are potentially untested on the device. It is better to have a set of setup options thatmay be chosen at BIOS build time. Removal of BIOS setup also saves significant BIOS post time.10. Remove Video Option ROMThe video option ROM on platforms featuring the Intel ® Atom processor and many other newerplatforms is quite slow due to the many different video interfaces that must be supported and thedisplay detection algorithms that must be employed. Replacement of a highly optimized DXE videodriver in place of the video option ROM saves significant boot time. The speed of this optimizedDXE video driver is highly dependent on the exact display chosen and video features required bythe platform prior to installation of the operating system graphics driver. On the investigationplatform, a fixed splash screen was displayed. The fixed splash screen was unchanged during theboot process until the operating system graphics driver initialized the display. To achieve this, thecapability to display text was removed from the DXE graphics driver. As a result, none of thenormal BIOS or operating system initialization messages is displayed. This yields additionalperformance and a cleaner boot appearance.11. Remove BIOS USB SupportSince USB boot and USB input devices (keyboard/mouse) were not requirements on theinvestigation platform, initialization of USB was completely removed from the BIOS. USB is stillavailable from the operating system once the driver is loaded but not during BIOS or OS loader.Discussion of ResultsFrom the investigation performed, the greatest improvement of BIOS boot time (more than 3seconds) is obtained by disabling debug. This step is appropriate for all BIOS implementations, notjust 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 thisinvestigation, replacing the video option ROM, and removal of BIOS setup and USB supporttogether resulted in a time savings of over 4.5 seconds.Next StepsThe following are additional considerations and possible areas for investigation for further reductionof framework BIOS boot times.Remove unnecessary microcode. In a typical BIOS microcode updates (processor patches) areincluded for many different processors that are supported on the platform. For a specificconfiguration of an embedded device, it is possible to remove most of these microcode updateswhich are each 2kB to 5kB in size.Investigate flash file system object compression. Compression results in fewer readsnecessary from the flash part resulting in faster boot. Conversely the processor must then performthe decompression which takes additional time. On faster processors, compression is likely toreduce boot time.6 Document number 320497

Fastboot BIOSSome 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. Notall decompression methods do this by default. This can be avoided by modifying thedecompression 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 ispossible by reordering the PEI modules in the flash part so they are executed in order and bymodifying the PEI dispatcher to remember where the last access came from and resume searchfrom that point. Currently, the dispatcher searches for each module starting from the beginning ofthe flash file system. In addition, module dependencies can result in multiple searches occurringfor each PEI modules executed.Make sure that recurring writes to the flash part are removed. While the writes themselvestake significant time, the biggest hit occurs when the flash file system requires garbage collectionto free space. The erases necessary can take seconds.Eliminate BIOS clearing of the first 640kB of memory. On the Intel ® Atom platform, someof this clearing was necessary to proper operation (probably due to the implementation of the 16bitlegacy core), however most could be eliminated. Clearing all of 640kB took over 100 msec on theIntel ® Atom processor.A mechanism is required for directly booting an operating system from flash instead offrom a hard drive. This is a more typical configuration for embedded devices. Furtheroptimization possible by removing hard drive and booting from an operating system embedded in aflash part. This capability is known to exist and just needs to be added here.ConclusionAchieving a sub-2 second boot time with EFI BIOS is not difficult. While many of the methods usedare specific to embedded markets (removal of features), several other methods are optimizationsuseful for all BIOS markets. From this investigation, it seems likely that sub-1second boot time isattainable 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 somepoint (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 DocumentsDocumentECG EFI/BIOS IndustrySurveyPlatform InitSpecificationUEFI SpecificationsLocationhttp://ifcollaborate.intel.com/ifc/getdoc.aspx?docbase=InfoFactoryKB&chronid=09005ffd8067578a&ver=CURRENT&qepop=falsehttp://www.uefi.org/specs/This is the PEI, DxE, and HoBs stuffhttp://www.uefi.org/specs/This is the OS interface and runtime EFI stuff.Tiano Core Features youwant to know about, toadoptEDK II – open source framework portions of TianoEFI Shell – basics about building a shellEFI SCT - self compliance testing for UEFI specEFI Toolkit - contains source code and documentation that enables rapid7 Document number 320497

Fastboot BIOSDocumentLocationdevelopment of EFI based applications, protocols, device drivers, EFIshells, and OS loaders.UEFI and WindowsBIOS Boot Specificationv1.01System ManagementBIOSReference SpecificationApple Universal BinaryACPI SpecificationPCI SpecificationsUSB SpecificationCompact FlashSpecifictionSerial ATAONFI Nand Specificationshttp://www.microsoft.com/whdc/system/platform/firmware/UEFI_Windows.mspx;Microsoft’s view of a BIOS, a bootloader and UEFIhttp://www.phoenix.com/en/Customer+Services/White+Papers-Specs/PC+Industry+Specifications.htmThis is a lot of miscellaneous stuff we shouldn’t have to do any morehttp://www.phoenix.com/en/Customer+Services/White+Papers-Specs/PC+Industry+Specifications.htmThis is a nice to have for any client controlled by IThttp://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary.pdf ;http://en.wikipedia.org/wiki/Universal_binaryOS X is a consideration, good ideas about PPC to Intel x86 conversionAdvanced Configuration and Power Interface. http://www.acpi.info/http://www.pcisig.com/specifications/ (PCI conventional, IOVirtualization, PCI Express)http://www.usb.org/developers/docs/http://www.compactflash.org/spec_download.htmwww.sata-io.org/specifications.asphttp://www.onfi.org/documentation.htmlPlug-and-PlaySpecificationHPET Specificationhttp://www.microsoft.com/whdc/default.mspxhttp://www.intel.com/hardwaredesign/hpetspec.htmAuthors and AcronymsAuthorsMichael Kartoz is a BIOS Architect with the Embedded and Communications Group at IntelCorporation.Pete Dice is an Architecture Manager with the Embedded and Communications Group at IntelCorporation.J. Gabriel Hattaway is a Software Program Manager with the Embedded and CommunicationsGroup at Intel Corporation.Wade Zehr is a BIOS Engineer with the Embedded and Communications Group at IntelCorporation.8 Document number 320497

Fastboot BIOSAcronymsACPI: Advanced Configuration and Power Interface. See http://www.acpi.info/AL: Afterlife phase. Power down phaseAML: ACPI Machine LanguageAPI: Application Program Interface. Programmatic interfaces for the firmware (as opposed toWin32-type OS-level APIs).a priori file: A file with a known GUID that contains the list of DXE drivers that are loaded andexecuted in the listed order before any other DXE drivers are discovered.Artifact: Something tracked in CEE Project TrackerASL: ACPI Source LanguageAttribute: A field of something tracked in CEE Project TrackerBA: Boot AuthorizationBBS: BIOS Boot SpecificationBDS: Boot Device Selection phaseBFV: Boot Firmware Volume. Code (i.e., PEI and PEIM code) that appears in the memory addressspace of the system without prior firmware intervention. See also FV.BIS: Boot Integrity ServicesBIST: Built-in Self TestBLT: Block Transfer (pronounced "blit " as in "slit" or "flit"). A series of functions that form the basisof 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 programminglanguages, command sets, and the likeBoot Device: The device handle that corresponds to the device from which the currently executingimage was loadedBoot Manager: The part of the firmware implementation that is responsible for implementingsystem boot policy. Although a particular boot manager implementation is not specified in thisdocument, such code is generally expected to be able to enumerate and handle transfers of controlto the available OS loaders as well as EFI applications and drivers on a given system. The bootmanager would typically be responsible for interacting with the system user, where applicable, todetermine what to load during system startup. In cases where user interaction is not indicated, theboot manager would determine what to load and, if multiple items are to be loaded, what thesequencing 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 tocomplete OS boot. Services are also available to drivers and applications that need access toplatform capability. Boot services are terminated once the OS takes control of the platform.BSD: Berkeley Software DistributionCEE: CollabNet Enterprise EditionCOFF: Common Object File Format. An (originally) Unix *-based file format that is now recognizedunder several OSs . The format uses one or more header fields followed by the section data for thefileCompatibility16: A traditional legacy BIOS with the POST and BIOS Setup code removed.Compatibility16 BIOS code executes in real mode9 Document number 320497

Fastboot BIOSCompatibility BIOS: The combination of both EfiCompatibility and Compatibility16CompatibilitySmm: Any IBV-provided SMM code to perform traditional functions that are notprovided by EFICPU: Central Processing Unit (or Processor).CRC: Cyclic Redundancy Check. A fixed-size error checking code appended to the end of a block ofdata (file) that is based on the content of the fileCRTM: Core Root-of-Trust ModuleCSM: Compatibility Support Module. The combination of EfiCompatibility , CompatibilitySmm , andCompatibility16. Portion of the Framework that allows compatibility with non-EFI compliantoperating systems to run on Framework firmwareCVDR: Configuration Values Driven through ResetDepex: Dependency expression. Code associated with each Framework driver that describes thedependencies that must be satisfied in order for that driver to run. Controls order of execution in aFramework dispatch of PEIM and DXE driversDispatch Entry Point: The entry point that the dispatcher invokesDriver: Modular chunk of firmware code that supports chipset or platform features. Reusable inmultiple system contextsDXE: Driver Execution Environment phaseDXE Foundation: A set of intrinsic services and an execution mechanism for sequenced control ofdriver modulesDXE Services: Services, such as security services and driver services, that are usable by DXEdriversEfiCompatibility: EFI code that corresponds to EFI compatibility drivers, code that generates datafor compatibility interfaces, or code that invokes compatibility services.Enhanced Intel SpeedStep® Technology: allows the system to dynamically adjust processorvoltage and core frequency, which results in decreased power consumptionEDK: EFI Developer KitEPL: Eclipse Public LicenseFAT: File Allocation TableFAT32: FAT32 File System DriverFD: Firmware Device. A persistent physical repository that contains firmware code and/or data andthat may provide NVS. For the purposes of this architecture specification, the topology of FDsshould be abstracted via FVs .FFS: Firmware File System. A binary storage format that is well suited to firmware volumes. Theabstracted model of the FFS is a flat file systemFirmware 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 fontsFoundation Code: The core interoperability interfaces between modules and in the FrameworkFPSWA: Floating Point Software Assist. (Itanium systems only)10 Document number 320497

Fastboot BIOSFramework: short for Intel® Platform Innovation Framework for EFIFS: Firmware Store. The abstracted model of the FS is a flat "file system" where individual files areSUMsFV: 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. Itconsists of both system memory and I/O spaceGlyph: The graphical representation of a single Unicode weightGUID: Globally Unique Identifier. A 128-bit value used to differentiate services and structures inthe boot services environmentHII: Human Interface Infrastructure. A repository of configuration and translation information forlocalization. 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 VendorIFR: Internal Forms Representation. A binary encoding of forms-based display content andconfiguration informationIHV: Independent Hardware VendorIME: Input Method EditorIntrinsic Services: Services, such as security services and driver services, that remain availableafter the phase during which they are instantiatedIP: Intellectual PropertyIPL: Initial Program Load. An architectural PEIM to PEIM interface that starts the DXE phaseIPMI: Intelligent Platform Management InterfaceISO 3166: An association between a country or region and a two or three character ASCII stringISO 639-2: An association between a language or dialect and a three character ASCII stringLocalization: Concepts by which an interface is made useful to users speaking different languagesand 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 andmay be local to the country the keyboard is localized for. For example, a French keyboard inFrance is different from a French keyboard in Canada .LPC: Low Pin Count Bus. Replaced the ISA bus.MCA: Machine Check ArchitectureNMI: Non-maskable interruptNRAM: Nonvolatile Random Access MemoryNVS: Nonvolatile storage. Flash, EPROM, ROM, or other persistent store that will not go away oncesystem power is removedODM: Original Device ManufacturerOEM: Original Equipment ManufacturerOpROM: Option ROMOS: Operating System11 Document number 320497

Fastboot BIOSPAL: Processor Abstraction Layer. A binary distributed by Intel that is used by the 64 bit Itaniumprocessor familyPCI: Peripheral Component Interconnect. See http://www.pcisig.com/ for more information.PCR: Platform Configuration RegisterPE/COFF: PE32, PE32+, or Common Object File Format. A defined standard file format for binaryimagesPEI: Pre-EFI Initialization phase. Set of drivers usually designed to initialize memory and the cpu sothat 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 ofPEIMsPEIM: Pre-EFI Initialization Module. Modular chunk of firmware code running in PEI that supportschipset or platform features. Reusable in multiple system contexts.PEI Services: Common services that are usable by PEIMsPHIT: Phase Handoff Information Table. A HOB that describes the physical memory used by thePEI phase and the boot mode discovered during the PEI phase.PIC: Position-independent code. Code that can be executed at any address without relocationPOST: Power On Self TestPPI: PEIM-to-PEIM InterfaceReverse Thunk: The code to transition from 16-bit real mode to native execution modeRSD_PTR: ACPI definition: Root System Description PointerRT: Runtime phase. For EFI and the Framework this is after exit boot services has executed andthe OS is in control of the system.Runtime Services: Interfaces that provide access to underlying platform-specific hardware that maybe useful during OS runtime, such as time and date services. These services become active duringthe 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 InterruptSMM: System Management ModeSOR: Schedule on RequestSSE: Streaming SIMD ExtensionsSUM: Separately Updateable Module. A portion of the BFV that is treated as a separate modulethat can be updated without affecting the other SUMs in the BFV.Tiano: Codename for the Intel Project to develop the FrameworkTE 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 ofspace 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 mode12 Document number 320497

Fastboot BIOSUNDI: Universal Network Driver Interface. Silicon specific driver in the preboot LAN stack thatinterfaces to SNP and PXEBCUnicode: A standard defining an association between numeric values known as "weights" andcharacters from the majority of the worlds currently used languages. See the Unicode specificationfor more information.USB: Universal Serial Bus. See http://www.usb.org/ for more informationVFR: Visual Forms Representation. A high-level language representation of IFRVM: Virtual MachineVTF: Volume Top File. A file in a firmware volume that must be located such that the last byte ofthe file is also the last byte of the firmware volumeVT-UTF8: A serial protocol definition that extends VT-100 to support UnicodeWatchdog Timer: An alarm timer that may be set to go off. This can be used to regain control incases where a code path in the boot services environment fails to or is unable to return control bythe expected path.XIP: Execute In Place. PEI code that is executed from its storage location in a firmware volumeThis 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 ANYWARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Intel disclaims all liability, including liabilityfor infringement of any proprietary rights, relating to use of information in this specification. No license, express or implied, byestoppel 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 orregistered 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 320497