Rather than set up an experimental new BIOS prototype in a closed laboratory, Intel implemented a way to demonstrate 32 bit firmware on a 32 bit platform. In 2000, the company published its first complete, formal specification for the Extensible Firmware Interface , intended for deployment on Itanium systems. EFI's principal objective is to specify the format of the terms and instructions used for operating systems to request data and services from their local firmware.

To help EFI catch on, Intel engineered an extremely clever strategy to demonstrate to the industry that it had no interest in securing a proprietary future BIOS for itself. Intel's EFI documentation was written to only specify how the OS and firmware communicated with one another - literally, the interface only. Exactly how firmware should implement that interface, was a decision left to BIOS vendors and OEMs to solve for themselves. So EFI would not replace the BIOS, but instead provide platform engineers with the incentive to do this for themselves.

"The role of firmware," states Mike Richmond, Intel's Manager of Platform Software, "is primarily to initialize the chipset, and to initialize the platform so that the OS can load. It doesn't necessarily have a runtime role. Unified EFI [is] an interface specification between firmware and the operating system, and between cards that want to do power-on-self-test [POST] and the underlying platform. EFI by itself doesn't 'fix the BIOS problem,' because you could layer an EFI implementation on top of a BIOS. What it does do, though, is unhook the OS from BIOS dependencies, so that you can do some innovation and, in fact, go about the job of renovating the firmware underneath EFI."

To show that EFI actually worked, Intel would develop a working "preferred implementation" of EFI for Itanium and IA-32, called the Platform Innovation Framework , or just "the Framework" (often referred to by its code name, "Tiano.") While the Framework would be implemented in shipping editions of Itanium systems, other companies would be free to model their own derivatives of the Framework for their own products, including EFI implementations for x86 (x64). Two product lines, AMI's Aptio and InsydeH2O, have both been produced since 2003 with direct support and cooperation from Intel.

Here is an example of a graphical setup screens for Aptio, AMI's current EFI-based firmware product. Note the full-color photos, denoting not only non-VGA video mode, but liberal memory use.  Future versions of Aptio will support the new UEFI standard. (Courtesy American Megatrends, Inc.)

Intel enticed platform developers with a big payoff for giving the Framework a try. The EFI 1.1 specification stated Intel's further intention to "allow for platform innovation to introduce new features and functionality that enhance platform capability without requiring new code to be written in the OS boot sequence." In other words, to remove the barrier preventing platform developers from doing whatever they feel like doing. And in late 2004, in a further sign of good will, Intel made Tiano's Foundation code officially open source, under the GPL license, through TianoCore.org.

Richmond tells Tom's Hardware Guide that his company's marketing strategy has three key objectives: first, to entice BIOS vendors to add new, viable technologies to firmware beyond what Intel could create for the Framework itself; second, to enable the creation of "multi-vendor-capable firmware implementations;" and third, to give someone else the responsibility for supporting those implementations. "It's impossible for Intel," says Richmond, "to support all of these companies doing all of these designs directly. We just don't have the capacity."

"I have outstanding relationships with all of the BIOS companies," stated Richmond, just before adding, "It took them a while to realize that we had no interest and no intention of being in their business."