BROWSE BY TECHNOLOGY




RTC SUPPLEMENTS


TECHNOLOGY IN SYSTEMS

Better Booting for Embedded Designs

Open Source Firmware - Coreboot for x86 Architecture Boards

The traditional commercial BIOS, while very useful for PCs, does not ideally serve the needs of embedded applications both in terms of functionality and pricing/licensing. The open source community has developed an alternative aimed at the needs of embedded developers.

CLARENCE PECKHAM, SENIOR EDITOR

  • Page 1 of 1
    Bookmark and Share

Article Media

Without a doubt, one of the key changes in software development has been the growth of open source software projects. The news is full of Linux- and Android-based systems, with Android being the largest installed base of open source software (also the best example of a Linux-based system used on a smartphone). In the time since Linux started the public awareness of open source software, there have been other efforts that have laid the foundation for the open effort.

One of the challenges of developing software has been the availability of tools such as compilers, assemblers, linkers, debuggers and integrated development environments. On top of this, the proliferation of processors has made tools availability even more critical.

The number of available processor solutions based on MIPS, x86 PowerPC and ARM architectures has increased almost daily. On top of that are the 8- and 16-bit processor solutions such as those from Microchip, Freescale and others. How do the tools keep up? The solution has been the development of a base set of development tools based on the GNU toolset shown in Table 1. Each of the manufacturers, or open source developers, provide a set of tools based on the GNU toolset. It is possible to use a set of open source tools for almost all of the popular processers available for embedded designs.

Table 1
Open Source tools for S/W development - available for multiple processor architectures.

Availability of inexpensive, or even free tools has opened up the use of many processors that might not have been used if an expensive toolset were the only solution. After all, it is an uphill road to convince your boss that trying the latest HAL2014 processor is a good idea if it is going to cost $10K to get a set of tools. To be fair, I should mention that the HAL2014 vendor will, in most cases, provide an evaluation set of tools with limited functionality for a limited time—but free and unlimited is better.

One issue of the open source tools is the lack of defined support. In a lot of cases the large number of developers means that bug reports get immediate attention. If that is not enough, a support ecosystem has built up around companies that will provide support for a toolset for the cost of a support contract. This makes a lot of embedded system developers more comfortable using an open software tool solution.

With the tools and open source operating system solutions, the user can develop an embedded solution. However, there is still a hole in the open software offerings for embedded applications—the boot firmware, or in the case of x86 architecture, the Basic Input/Output System (BIOS) used to start the application. For processor solutions other than x86 there is an open source solution called U-Boot, which started as a solution for the PowerPC processor and has migrated to the MIPS and ARM architecture, and System on Chip (SoC) solutions based on MIPS and ARM. For the x86-based architecture, the standard has been to use a traditional BIOS developed for the PC architecture such as the offerings from Phoenix or AMI. This is a workable solution but not one that is ideal for the embedded market since it involves an upfront cost as well as royalties for each unit shipped.

Embedded Systems Firmware Requirements

The firmware, or BIOS, used in x86 architecture systems was developed to provide a means to test and initialize hardware and boot the operating system from a disc drive. For embedded systems, the firmware has requirements that go beyond the normal BIOS features—in most cases requirements that are much simpler than what is offered in the typical BIOS.

First for an embedded system is the ability to boot from cold to the application as fast as possible. In some cases an embedded system must be up and running in less than a second for critical applications. This requires the ability to utilize the smallest amount of code to execute the minimal operations required.

Another requirement is the flexibility to handle anything from a small system to a large multiprocessor computing system. Flexibility also requires the ability to easily customize the firmware and have open source for most of the software. And if binary-only modules are used, you need the ability to locate the binary modules as required. The advantage of allowing the use of binary modules in open source software is that it enables chip manufacturers such as AMD and Intel to provide proprietary software for their advanced chips without having to release the source code. As we will see in the following sections, Coreboot provides the fast, flexible and cost-effective solution to providing a firmware solution for embedded systems.

Atomic Research Spawns the Coreboot Initiative

The birth of LinuxBIOS began in 1999 with a handful of researchers at Los Alamos Labs lead by Ron Minnich. The objective was to improve computing performance through faster BIOS startup and better error handling in large computer clusters. “From that start, LinuxBIOS was renamed Coreboot in 2008 and migrated into commercial high-performance computing (HPC) and began capturing the attention of industry leaders such as AMD and Intel,” stated Kerry Brown, VP/COO of Sage Electronic Engineering.

Also a number of manufacturers such as Gigabyte, Micro-Star International (MSI) and Acer are supporting Coreboot development on their motherboard and laptop designs. Recognizing Coreboot’s advantages, Google is now on board as a project sponsor. “Several Google Summer of Code (GSOC) projects have been based on Coreboot development and enhancements,” added Kerry.

As an open source project the Coreboot community continues to grow, attracting developers from all parts of the globe. Members work for technology companies, conduct research at universities, and take part in government-funded programs. “With support from both AMD, as a source code provider, and Intel, providing the Firmware Support Package (FSP), access to low-level chip functions has also helped Coreboot become successful,” commented Kerry.     

Coreboot Features and Embedded Use

A simple definition of Coreboot is that it is a replacement for the traditional BIOS, but it is a boot loader and not a BIOS. The purpose of Coreboot is to initialize the hardware and then load a payload. Figure 1 shows the basic architecture of the Coreboot firmware. The payload is the module that decides what the hardware is going to be used for. A payload can be the end application, or as in most cases, it is a path to booting the final application. The major features of Coreboot are:

Figure 1
Coreboot architecture including payloads. User payload can be proprietary code that does note have to be leased under the open source license. The Vendor Reference Code is provided by the processor vendor as either source or binary files.

Smaller Binary Images: By generating smaller binary images, you’ll be able to use less flash memory, or incorporate additional features with the available memory.

Boot Flexibility: With Coreboot you can boot from NAND Flash and other nonstandard media. The majority of existing proprietary BIOS software does not support this capability.

Customization: Coreboot enables you to customize your firmware even at the most basic level. Structurally, Coreboot is based around the requirements of the x86 PCI device tree and is designed to do minimal hardware initialization before passing control to a payload. Coreboot initialization contains no BIOS services and does not stay resident in memory.

Runs in 32-Bit Protected Mode: In Coreboot, the boot block contains the jump instruction to the initialization code—the first instruction fetch—and an immediate change to 32-bit protected flat mode. After the switch to protected mode, the boot block does minimal northbridge and southbridge setup required to jump to the RAMstage.

Code Written in C: Moving away from assembly code toward a high-level language saves developers considerable time in coding, debugging and documenting.

Loading Application Software: Coreboot supports multiple booting choices, including loading software without an OS, as with certain standalone programs (memory testers, games, etc.).

Multiple Debug Features: Coreboot enables a number of functions including remote flash firmware, embedded software development via serial ports, systems administration of remote computers, and booting from a network. 

Coreboot Payloads

The concept of payloads is the key feature of Coreboot. By using a payload, embedded developers can define the exact features they need and not have to include any features they do not require. This makes for an efficient and fast solution. Although the payload can be completely developed by the user, there are several developed payloads that can be used if desired.

An example is the seaBIOS payload, which provides normal BIOS calls so that standard OSs, such as Windows and Linux, can be booted. Another example is the iPXE payload, which provides for loading over the network. Or both payloads can be used in a Coreboot implementation. 

The modularity of the Coreboot project provides segregation of your IP from the publicly available GPL code base. Since IP is delivered in a payload called from the Coreboot initialization firmware, it can be developed on a proprietary basis or leveraged from a code base that doesn’t have a publication requirement. In other words, you can fully use Coreboot to your advantage and participate in the global Coreboot community without sharing your intellectual property

Coreboot Software Development

Developing software for Coreboot requires the use of development tools such as GCC and GDB for debugging. All of the source code can be accessed via www.coreboot.org, and in addition to the source code, a full set of documentation is available to help speed the learning curve. As with any open source project, a company that wants to utilize the code has to be willing to contribute to the support of the code as well as keep track of the changes so that they can decide when to roll their internal code revisions. This can be a large task that can consume a lot of development time.

An alternative is to work with a vendor that supports commercial use of Coreboot. Sage Electronic Engineering is a company that supports Coreboot for commercial use. Sage can provide any level Coreboot support. Their key products are SageBIOS, Sage EDK and SmartProbe.

SageBIOS is an integrated version of Coreboot that can be configured to support any payload required. Sage EDK, shown in Figure 2, is an integrated development environment based on the Eclipse platform and open tools. When used with SageBIOS, Sage EDK provides a complete development package for Coreboot applications. For debugging, SmartProbe can be used with AMD-based platforms to control firmware updates and debugging.

Figure 2
SageEDK Eclipse Development Environment debug page. (courtesy Sage Electronic Engineering)

Both Intel and AMD provide code to support Coreboot applications on their respective chip sets. AMD provides source code via their AMD Generic Encapsulated Software Architecture (AGESA), and Intel provides binaries of their Firmware Support Package. “Both Intel and AMD are key supporters of the Coreboot project with the AGESA and FRP software packages. In the case of Intel’s FRP, Sage is a source code licensee, so any changes required can be made,” commented Kerry. 

Coreboot has gained a lot of support in the past few years, and with the trend to consider open source solutions in embedded applications, replacement of the traditional BIOS with a royalty-free open source solution seems to make good sense. Also, just as Linux started gaining better acceptance with releases from RedHat and Ubuntu, support for Coreboot from companies like Sage Engineering should help gain embedded developers.

Another plus is Google’s use of Coreboot for their Chromebook laptops. Google’s major objective is to give more support to Coreboot development not only by developing the code base, but also through testing and quality control, including developing a Coreboot version for the ARM processor. Coreboot meets all of the objectives of an embedded application, and with support provided by many companies and individual developers, it is a realistic alternative to a traditional commercial BIOS.  

AMD
Sunnyvale, CA
(408) 749-4000
www.amd.com

Coreboot
www.coreboot.org

Intel
Santa Clara, CA
(408) 765-8080
www.intel.com

Sage Electronic Engineering
Longmont, CO
(303) 495-5499
www.se-eng.com