From the AMI Archives: AMIBIOS 8 and the Transition to EFI

Share on linkedin
Share on facebook
Share on twitter

In today’s Tech Blog post, we will focus on one of AMI’s best-known and most beloved products, the one that helped the company to an enormous degree in building our name and establishing our legacy as a technology innovator. In fact, at one point in its history, this product was installed in over 65% of the worlds computers! Many readers will immediately know that we are talking about AMIBIOS®, the legacy BIOS firmware that powered a generation of desktops, servers, notebook computers and embedded devices.

However, many readers will also know that legacy BIOS products like AMIBIOS are no longer in use, eventually replaced by firmware based on Extensible Firmware Interface (EFI) and UEFI technology. To help explain how this transition occurred, we will set the stage by describing the key features and limitations of AMIBIOS, as well as some background information on EFI and the state of technology in the period in which AMI and the industry at large made this transition. We will cover precisely how and why this happened, and the chain of events that led to the development of Aptio®, our current UEFI BIOS firmware solution, still widely used by leading OEMs and ODMs today.

What was AMIBIOS 8, and why was it so important for AMI?

AMIBIOS 8 was the final embodiment of AMI legacy BIOS product development within the AMIBIOS family. It built on over 25 years of AMIBIOS experience, leveraging the superior engineering that was the cornerstone of AMIBIOS since 1986. AMIBIOS 8 extended this experience into another generation of x86 platforms, as an innovative solution anchored on robust development tools like Visual eBIOS (VeB), originally released in 2001, and widely recognized industry standards.

AMIBIOS 8 also featured a heavy emphasis on modularity in its design, with modular code components called eModules™ that were easily integrated into project source code. This flexibility allows developers to readily customize a BIOS project using AMIBIOS8 components, or create custom reusable feature modules – and still exists in AMI UEFI BIOS firmware to this day.

The eModules in AMIBIOS greatly simplified porting to new platforms, including BIOS maintenance and component upgrades. AMIBIOS8 also featured a smaller footprint, faster boot times and more efficient power management features compared to previous versions of the product. Due to its flexible architecture, AMIBIOS8 was also ideal for embedded platforms, easily blending features from different PC market segments.

Despite its widespread adoption and positive reviews, the computing landscape continued its ever-shifting and accelerating ways, and eventually it was time to close the curtain on AMIBIOS. Specific trends hastened this process; key among them was the seismic shift from 32-bit to 64-bit architecture, and the emergence of the Extensible Firmware Interface (EFI) standard that accompanied this move.

Why Did AMI move from (Legacy) BIOS to EFI? What was EFI?

Multiple blog posts could be written about the rise of IA-64 architecture and its connection to the emergence of EFI. However, we will focus on some of the limitations in legacy BIOS firmware like AMIBIOS 8 that were exposed as 64-bit architecture became more widespread. To do so, first we need to understand a little more about the EFI specification itself.

The Extensible Firmware Interface (EFI): A brief introduction

Like legacy BIOS, the Extensible Firmware Interface (EFI) specification, originally introduced by Intel Corporation, defines an interface between the operating system (OS) and system firmware consisting of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Most importantly, these tables compose a standard environment for system booting and running pre-OS services. As such, EFI defines a standard driver execution model to initialize and manage each platform component, which allows independent hardware vendors to develop EFI drivers that initialize and manage their hardware.

In short, the EFI specification defined a way for the OS and platform firmware to communicate all the information necessary to support the OS boot process. This was accomplished through a formal and complete abstract description of the software-visible interface presented to the OS by the platform and firmware. The EFI specification simply defined the interface implemented by platform firmware, as well as the interface used by the OS loader; how the firmware implements this interface is up to the firmware manufacturer.

In this way, an EFI code base, such as AMI’s Aptio firmware, could allow drop-in integration of any third-party drivers with minimal effort. The EFI specification outlined a platform-agnostic firmware interface, but did not dictate how that interface should be implemented on a specific platform. In later years, the effort to advance the definition of a standard environment for system booting and pre-OS services was taken on by the Unified EFI (UEFI) Forum, which subsequently released the UEFI Specification 2.0, aimed at improving interoperability between system components and cards.

How did EFI relate to BIOS? What were some of the issues encountered?

The Basic Input /Output System (BIOS) of any PC-compatible computer provides an interface between the OS and system firmware based on standards established for the original IBM-PC/AT. Since PC architecture had evolved greatly in the twenty years leading up to the introduction of EFI and IA-64 architecture, the existing BIOS interface gradually fell out of step with current processor technology.

In response, the original BIOS architecture was extended to support the latest computing features, but remained reliant on something called “real mode” operation, which was essentially how modern processors emulated the original Intel® 8086 and 8088 processors. In fact, the original Microsoft® MS-DOS® was designed around real mode and could not function without it. Over time, MS-DOS-compatible software like Microsoft® Windows® XP continued to utilize real mode for many purposes and most BIOS runtime services continued to be provided as real mode functions. In fact, even the fastest IA-32 processors of the time continued to support real mode to maintain software compatibility.

However, modern operating systems like Linux and newer versions of Microsoft® Windows® such as NT, 2000 and XP were known to operate in a “protected mode” that would allow a program to access extended memory and perform multitasking operations. Since most BIOS services were provided in real mode, processors were forced to switch back out of protected mode to perform many operations. EFI, which was originally created by Intel for its IA-64 architecture, operated fully in protected mode. Furthermore, the EFI development model was based on hardware drivers that could connect to the lowest level of the PC structure: the hardware itself.

With EFI, manufacturers were free to write their own OS-independent hardware drivers which could be included within the device itself and used directly by more modern operating systems. Such EFI drivers could also be used, for example, to allow the PC to connect to the Internet and retrieve updated drivers even before an OS is installed – something that is common place today but quite revolutionary at the time. All of these advantages paved the way for the slow “demise” of legacy BIOS as it was known. However, the creation of new firmware solutions based on EFI to fill this gap and complete the transition was not something that could happen overnight, so BIOS vendors and silicon manufacturers adopted a measured, gradual approach, by finding creative ways of adding EFI support to legacy BIOS before a full-fledged EFI firmware solution emerged.

How was EFI added to AMIBIOS 8 before the transition to UEFI BIOS firmware like Aptio?

As the need to support the EFI standard became a clear requirement, this support for IA-32 platforms was added through a unique AMIBIOS 8 eModule called “EFI32”. The modular architecture of AMIBIOS 8 easily allowed support for new technologies like EA32 to be added to any project by separating hardware support from technology support. This also had the added benefit of allowing more code to be reused from project to project, since the EFI32 eModule did not contain any code specific to a particular processor or chipset type. This meant that the eModule could work on essentially any IA-32 platform without major modifications.

Hitting a wall: The need to fully transition to EFI-based firmware

As mentioned above, as operating systems like Linux and Microsoft® Windows® were modernized, they used protected mode as their preferred operational mode, switching back to real mode to access BIOS services and other operations. But things eventually came to a final juncture when Intel introduced the 64-bit Itanium™ processor family, which no longer featured support for real mode. Without this support, the traditional BIOS interface could not be used by operating systems designed for that processor family. A new firmware interface was required for this 64-bit architecture, one which could operate consistently in protected mode.

In this way, EFI was originally designed for Itanium™ processors, but was ultimately extended to also work with IA-32 architecture processors of that time – establishing it as a firmware interface for the next generation of computer systems. AMI’s implementation of EFI on IA-32 platforms through eModules in AMIBIOS was designed to facilitate the transition from BIOS runtime services. For a time, the AMIBIOS 8 implementation of EFI sat side-by-side with the legacy BIOS, allowing users and system integrators to support both firmware interfaces.

In the meantime, AMI was fully engaged in the development of a new firmware solution that would natively support 64-bit architectures, and became deeply engaged in industry-wide activities to promote EFI such as the UEFI Forum that was mentioned earlier in this post. Once AMI introduced Aptio, its EFI-based firmware platform, the transition was complete. From that point forward, AMI could provide full support to next generation platforms with a product that is still going strong today: Aptio V UEFI BIOS Firmware.

Thanks for reading today’s Tech Blog! What are your thoughts and recollections of AMIBIOS 8 and the transition to EFI (and UEFI) based firmware solutions? Feel free to drop us a line via social media or our Contact Us form and let us know – and what you might like to see in future posts!