As today’s processing platforms assume more and more architecture functions of data centers in a predominantly software-defined networking scenario, questions arise regarding how best to maximize networking abilities of processors, as well as maximizing potential savings in power, heat and hardware costs. For x86 processors, one clear area of optimization is the replacement of legacy BIOS (basic input/output systems), the proprietary and usually royalty-based firmware that has controlled basic initialization of almost all computers and servers for the last three decades. Importantly, these BIOS solutions were inherently limited to 16-bit processing, even if systems are running on 32- and 64-bit processors, and the limited disk space accessible to the boot initialization.
Today, more common solutions for initializing x86 chip architectures in a server environment are the Unified Extensible Firmware Interface (UEFI) and coreboot, the name of both the open-source community and the firmware developed by that community. UEFI and coreboot actually represent the two ends of a spectrum of firmware solutions: the former is a very robust firmware solution that easily integrates a wide range of products in the traditional PC and server market, and the latter is a minimalist solution well suited to a range of embedded systems, low-power solutions, and single-purpose or application-specific computing.
Both technologies were specifically created to overcome server limitations created by legacy BIOS. UEFI technology was initiated by Intel as EFI in the late 1990s and handed off in 2005 to the Unified EFI Forum, a consortium of hardware and software manufacturers that includes Apple and Microsoft.
The coreboot project began in the winter of 1999 in the Advanced Computing Laboratory at Los Alamos National Laboratory, as engineers already using Linux operating systems sought to create a BIOS that would start fast and handle errors intelligently, using open-source code to develop an early boot system for powering up, initializing memory and setting up hardware for subsequent stages.
Specifications and Deployment
UEFI is a proprietary package that can easily be deployed by software engineers without having to address much of what has typically been known as firmware or embedded development. As of version 2.4, UEFI supports Itanium, x86, x86-64, ARM (Aarch32) and ARM64 (Aarch64).
Coreboot is a classic open-source solution that supports most Intel and AMD processors. The coreboot community currently enables more than 230 reference boards, including most of the newer x86 family of chips produced by Intel and AMD, as well as many ARM processors. The open-source code for specific processors is free, but there can be substantial in-house costs for embedded development when tuning the code for specific board implementations.
Accessing the highly protected x86 architecture was initially problematic for open-source firmware developers. Recently, however, x86 chip manufacturers have taken steps to ensure that open-source firmware developers have access to this architecture. AMD’s AGESA (AMD Generic Encapsulated Software Architecture) and Intel’s Firmware Support Package (FSP) are examples of this commitment.
Although hardware costs are forever decreasing, dedicated flash memory for boot initialization can become significant in a server array. In general, UEFI will require 3.5 megabytes of flash memory on each board, compared with 512 kilobytes for a coreboot solution employing a SeaBIOS bootloader. In addition, a classic server configuration of coreboot, SeaBIOS and a Linux shell operating system can be completed using 4.5 megabytes of flash memory, eliminating the need for more dedicated OS memory.
UEFI is very much like an underlying operating system and will remain in some powered state once the actual OS has begun initiation. Coreboot has no power requirements once it has initialized the system. In a PC environment this is hardly a concern, but, again, once spread across a data center, UEFI’s powered-state requirement will constitute a significant increase in energy use and heat production.
UEFI is particularly well suited to applications that require dynamic discovery of components during the startup, such as RAM upgrades, replacement of physical devices like DVD writers, addition of PCI cards and so on. For many original equipment manufacturers (OEMs), this situation makes UEFI a highly desirable system, as it already supplies all the needed firmware needed for adding hard drives, USB elements, drivers and additional software.
In an optimized setting, however, the robust nature of the UEFI boot can slow a server system. Although the UEFI boot can be refined—essentially, slimmed down—doing so usually involves more firmware work than building the boot from the ground up, as is commonly done with coreboot.
Coreboot is designed to perform the minimum amount of 16-bit processing, needing only 10 commands to get to 32-bit processing and proceed to 32- or 64-bit operating systems as quickly as possible. It is usually employed in a highly optimized state for the initial boot sequence, allowing embedded developers to add payloads they are familiar with and maximize capability in either the chosen operating system or application.
Google Chromebooks, which now require coreboot, are a good example of how quickly the firmware can load an operating system—in some instances in about two seconds. Another measure would be that coreboot can load a Linux shell from a powered-off state in about the same amount of time that a UEFI system would require to power back to the operating system from an S3 hibernation, or suspend-to-disc, state.
Downtime for routine maintenance or unforeseen glitches has always been important for the reliability statistics of data centers, but boot speed becomes more significant as server arrays transfer to SDN optimization. In an automated scenario, the ability to power off boards not in use can result in tremendous savings for data centers. Boards can also be reconfigured on the fly as data needs change during any given day, making boot speed even more important.
UEFI is entrenched in the traditional x86 server markets, where its support from Microsoft helps its acceptance as an industry norm. Reduced hardware costs, in comparison with power and cooling costs, have probably also helped this acceptance, as has the low cost of deployment.
But in the quickly evolving SDN environment, widespread use of UEFI is less certain. And boot-initialization times will become far more important in an SDN world. The reduced power usage and heat generation achieved with open-source solutions such as coreboot will also have a measured effect—one that may very well be turning heads in the data center world in days to come.
Leading article image courtesy of IntelFreePress
About the Author
Scott Hoot is president and CEO of Sage Electronic Engineering, a full-service engineering-design, product-development, and training firm specializing in open-source firmware development for embedded, COTS, and custom hardware platforms. He can be reached at firstname.lastname@example.org.