IBM/PC/Intel Based computers, like all other computing systems, need to boot when they are powered on. The computer's various parts and in and out devices need to be defined in order to allow access to resources. In order to facilitate booting, PC based systems have a variety of ROM like storage systems to read the program that begins the booting process. When a computer starts, it has no knowledge of itself. It is a blank slate. All the information that the system needs to know about itself, in order to process user programs and to do useful tasks, requires an increasingly complex task of making resources available and known. In order to do this, systems are hard wired to look for the starting instructions at fixed locations on the system. These locations are specific for different hardware types. For example on Intel x86 processors, memory location FFFF:0000 is always the first instruction that the CPU is begin executing with. Other systems have different locations, and even different addressing schemes. Intel x86 based system include ROM based firmware called a BIOS. The BIOS (Basic Input/Ouptput System), has exacting specifications. Although they can vary, for a specific x86 type of architecture, they can only vary within the confines of the specification. A BIOS relies on the x86 architecture’s 16-bit real mode which is a long was of saying that it works in the environment of a 16 bit CPU of the x86 type. Since all the intel chips have been backwardly compatible to this standard, up until now, BIOS, and CMOS software that accesses the BIOS has been at the core of system start ups for intel based hardware for a generation. Over time, there has been increasing demands on hardware booting. Even early in the history of the PC, there was a need to use PCs as thin clients and for network booting. This required that network cards, and networking protocols to be active prior to the booting and implementation of the operating system. There was the creation of the BOOTP and TFTP (trivial FTP) and a slowly a whole alphabet soup of acronyms have been introduced into the ligo of booting system. In addition to this, more than one operating system are now installed on system, and hard drive capacities have grown further that the 16 BIOS addressing scheme can read. Hard Drives have had master boot records, but over time, booting information has moved off the master boot record and onto various partitions. Additionally, modern Free Software and proprietary systems can run on a variety of hardware outside of the world of the x86 architecture. Bios and CMOS can now also be flashed, to be updated and allow for more flexible configurations. Tablets, micro-tables(phones), and new laptop designs with touch screen are standard input devices have become population. All this has put pressure to redesign the booting system for commodity hardware. "In the end, the BIOS is still here and still does what it has been doing for the last 25 years: making sure your operating system can boot. It was never designed for today’s massive diversity of hardware. It’s still stuck with 16-bit interfaces and software interrupts, interrupt routing and maximum precision timers, limited ROM execution space (1 MB) and image size, a limited number of initializeable devices (which is critical in the server space), proprietary extensions, and missing modularity—just to name a few issues." 1 This has been a blessing and a curse. Efforts to remove the BIOS functionality have always been targeted to take away the flexibility of run anything, clean and simple interface. IBM's MicroChannel architecture is but one an example. Intel finally took the bull by the horns with the introduction of the Itanium’s IA64 architecture (along with HP) in 2003. This was a PC like server architecture that needed around some of the BIOS limitations. The created the EFI standards (adding more acronyms to the soup), and handed off its future to the industrial consortium called Unified Extensible Firmware Interface Forum which is an acronym for AMD, Insyde Software, American Megatrends, Inc.. Intel, Apple Inc, Lenovo, Dell, Microsoft, Hewlett Packard, Phoenix Technologies and IBM. There is a SINGLE non-profit engineering or standards group represented on UEFI forum. The result is some very useful specifications a washed in some game changing lock down mechanism designed to do what IBM could never accomplish with microchannel. UEFI, in fct, is nearly an operating system sitting between your firmware and your operating system. "It not only offers driver support, interfaces, and services, but it also has a shell that allows users to execute applications on a command line interface." 1 The generalized process of UEFI booting is as follows: 1- UEFI Firmware: Performs CPU and Chipset initialization and loads drivers 2- UEFI Boot Manager - Loads device drivers and the boot application 3- Loads the OS boot manager selected by the user 4- Loads the OS 5- Runs the OS Kernel EFI (the Intel Child of UEFI) has tables and offers run level services to the operatings. This is similar to the runtime services that unix-like operating systems have had for decades. Boot Services include file services, text and graphic user consoles, and the run services can offer access to Non-volatile random-access memory (NVRAM), date and time, etc. EFI drivers have specific communication protocols that all components can use. The EFI device driver environment s a virtual drive, like what Java uses, called the EBC, which provides a CPU independent development target for UEFI module development. Overall Boot Time line Part 1: Power On Secure Boot Pre EFI Initialization (PEI) PIE Core CPU Init Chipset Init Board Iniit EFI Driver Dispatcher Architecture Protocols Driver Execution Environment Device, Bus and Service Driver Utilization of the EFI Driver Dispatcher Boot Device Selection Boot Manager Transition System Load OS Absent Application UEFI Shell Transient OS Boot Loader Final OS Boot Loader Run Time OS environment applications 1 http://www.tomshardware.com/reviews/intel-uefi-firmware,2486.html