Quick Boot

Pete Dice

• Publisher: De|G Press
• Year: 2017
• ISBN:
  9781501506727
• Edition: 1
• Topic: Computer Science
• Subtopic: Systems Architecture
• Index: Computer Science

Quick Boot is designed to give developers a background in the basic architecture and details of a typical boot sequence. More specifically, this book describes the basic initialization sequence that allows developers the freedom to boot an OS without a fully featured system BIOS. Various specifications provide the basics of both the code bases and the standards. This book also provides insights into optimization techniques for more advanced developers. With proper background information, the required specifications on hand, and diligence, many developers can create quality boot solutions using this text.

Pete Dice is Engineering Director of Verifone, where he manages OS Engineering teams in Dublin, Ireland and Riga Latvia. Dice successfully launched Intel® Quark™, Intel's first generation SoC as well as invented the Intel® Galileo™ development board and developed a freemium SW strategy to scale Intel IoT gateway features across product lines. He is also credited with architecting the "Moon Island" software stack and business model.

Chapter 1
System Firmware’s Missing Link

Hardware: the parts of a computer that can be kicked.

—Jeff Pesis

Booting an Intel architecture platform should be easy. Anyone who thinks that writing an all-purpose Intel® architecture Basic Input Output System (BIOS) and/or an operating system (OS) boot loader from scratch is easy has yet to try it. The complexity and sheer number of documents and undocumented details about the motherboard and hardware components, operating system requirements, industry standards and exceptions, silicon-specific eccentricities beyond the standards, little-known tribal knowledge, basic configuration, compiler nuances, linker details, and variety of applicable debug tools are enormous. While it can be difficult, it doesn’t have to be.

This book is designed to give a background in the basic architecture and details of a typical boot sequence to the beginner firmware developer. Various specifications provide the basics of both the code bases and the standards. While a summary is provided in the chapters below, there is no substitute for reading and comprehending the specifications and developer’s manuals first-hand. This book also provides insights into optimization techniques to the more advanced developers. With the background information, the required specifications on hand, and diligence, many developers can create quality boot solutions. Even if they choose not to create, but to purchase the solution from a vendor, the right information about boot options makes the decision making easier.

Start by Gathering Data

First you must ‘know the ground’; obtaining and using the right data are essential to success. To begin to gather the appropriate documents at the start of the project requires research. Full system initialization is like a large puzzle where someone has hidden some of the pieces:

–Motherboard schematics are an absolute must. If you are designing the board, then that is not a problem. If you are reusing an off-the-shelf solution, there is a high likelihood that the vendor who created the board is unwilling to release schematics readily. You can reverse-engineer some of the data, like system management bus addresses, but things like IRQs and GPIOs will be very difficult. If there is an embedded controller in the picture, the number of unknowns increases.

–A standard system BIOS today covers at least 70 industry standard specifications alone that can apply to the mainstream client and server boxes commercially available. For application specifications, there could be dozens for a given market segment. If it is a new or emerging type of system, there will be no mature standard and you will be chasing a moving target. Obtaining the list of industry standards that apply is a daunting task and may require some registering and joining to gain access to specifications and/or forums to get your questions answered. Some older specifications are not published and not available today on the Internet.

–There are many long-in-the-tooth legacy devices that may need to be initialized, and finding documentation on them is challenging. They may exist only in the dusty drawers of a senior engineer who retired five years ago.

–In some cases, nondisclosure agreements (NDAs) must be signed with the various silicon, BIOS, or motherboard vendors. The NDAs can take precious time to obtain and will require some level of legal advice.

–UEFI provides a handy API for interfacing to the OS. It has a modular framework and is a viable starting place supporting many industry standards such as ACPI and PCI.

–Until now, no single reference manual has documented the required steps needed to boot an Intel architecture system in one place. Nor has anyone detailed the order of initialization to get someone started.

Those who have been exposed to system firmware at a coding level and the inner workings of the black art that is system BIOS understand that it is difficult to explain everything it does, how it does it, or why it should be done in exactly that way. Not many people in the world would have all theanswers to every step in the sequence. Most people who work in the code will want to know just enough to make necessary changes and press on with development or call up their BIOS vendor.

Fortunately, there are many options available when choosing a firmware solution, which we will examine in the next few pages. The more you know about the options, the key players, their history, and the variables, the better decision you can make for your design. The decision will be a combination of arbitrary thought, low-hanging fruit, economies of scale, technical politics, and, of course, money vs. time.

Intel has created an open-source-based system, known as Intel® Boot Loader Development Kit (Intel® BLDK), which provides a turnkey solution without a huge learning curve. Developers can go to www.intel.com and download Intel BLDK for various embedded platforms.

Intel® Quark processor also has a UEFI implementation that is entirely open source and is built using the UEFI framework. This can be found online by searching for Galileo UEFI firmware.

Initialization Roles and Responsibilities

First, let’s get our definitions straight; understand what the industry has been up to, and how we can move forward to make the best decision we can make. Traditionally, a platform based on Intel architecture boots in three steps: system firmware, OS loader, and finally the operating system itself.

System Firmware

The system firmware is a layer between the hardware and the OS that maintains data for the OS about the hardware. As part of the power on self-test (POST), the system firmware begins to execute out of flash to initialize all the necessary silicon components, including the CPU itself and the memory subsystem. Once main memory is initialized, the system firmware is shadowed from ROM into the RAM and the initialization continues. As part of the advanced initialization stages, the system firmware creates tables of hardware information in main memory for the operating system to utilization during its installation, loading, and runtime execution. During POST, hardware workarounds are often implemented to avoid changing silicon or hardware during later design phases. There may be an element of the system firmware that remains active during latter stages to allow for responses to various operating system function calls. The system firmware is customized for the specific hardware needs of the platform and perhaps for a given application. The last thing the system firmware does is hand off control to the OS loader.

System firmware can be constructed in a proprietary legacy code base and/or in a Unified Extensible Firmware Interface (UEFI) framework. Legacy BIOS incorporates a legacy OS interface and follows legacy software interrupt protocols that have been evolving organically since the IBM PC (circa 1981). UEFI is a specification detailing an interface that helps hand off control of the system for the preboot environment—that is, after the system is powered on, but before the operating system starts—to an operating system, such as Microsoft Windows or Linux. UEFI provides an interface between operating systems and platform firmware at boot time, and supports an architecture-independent mechanism for initializing add-in cards (option ROM). We will dig in to the story of how and why legacy BIOS has been converted to UEFI in a minute. A key takeaway is that the system initialization code is either going to be UEFI-based, or legacy-based, or try to support elements of both depending on the operating system requirements.

OS Loader

The OS loader does exactly what its name implies. It is customized with knowledge about the specific operating system, how it is ordered, and what blocks of the OS to pull from the OS storage location. A long list of OS loaders is available in the market today for Linux. We will examine a few of these in later chapters. Microsoft Windows and real-time custom operating systems also have their own flavors. It is possible that the OS loader may be enabled or configured to extend the platform initialization beyond the system firmware’s scope to allow for more boot options than was originally planned.

It is possible, depending on the system architecture and the firmware solutions that you work on, that the OS loader and the system firmware are part of the same binary image located in the same component on the system, or it may be separated.

Operating System

The operating system completes, or in some cases repeats, the initialization of the hardware as it loads and executes the software kernel, services, and device drivers. It potentially loads the human/machine interface (HMI) and finally begins to run the applications. Depending on the application, there are various ways that the OS can be initiated. We will dig into this more in future chapters.

Care should be taken when considering combining elements of various components together as proprietary, and public licenses may prohibit linking the objects together in various ways.

Legacy BIOS Interface, UEFI, and the Conversion

For the three elements to communicate effectively, they share a common set of interfaces. The interfaces have undergone a dramatic change in the past decade. This conversion from legacy BIOS interfaces to UEFI interfaces has not been without some major challenges. During the past ten years, much has been said in industry forums about the platform innovation Framework for EFI, also known as the Tiano code base. When selecting a starting point for development it is important to know the legacy, limitations, and benefits of various solutions.

Tiano Benefits

There are several benefits to UEFI over legacy BIOS:

–Location of option ROMs. Legacy option ROMs have been constrained for many years by having to reside below the 1-MB boundary of 16- bit code. Between C0000h and FFFFFh in system memory, all option ROMs including required components like Video BIOS, LAN, SCSI/RAID, manageability, and the system firmware runtime code all had to coexist. In server platforms, this limited the number of add-in cards that could be plugged in. Each of the legacy option ROMs had to do unnatural things to keep their code sizes minimized. A native UEFI system can move the option ROMs above 1 MB, enhancing their capabilities and size. The benefit has real value, especially in larger systems with many add-in devices.

–UEFI option ROMs themselves have many benefits over legacy option ROMs. They can be created without the 16-bit code interface, which adds substantial overhead to a legacy option ROM. There is also a UEFI-defined interface to allow for a cohesive user interface instead of creating and maintaining a unique/proprietary command line UI or inventing a GUI, which saves a great deal of size and development overhead in UEFI option ROMs.

Lastly, UEFI option ROMs can also utilize EFI Byte Code (EBC), which allows a single binary to be executed by 64-bit or 32-bit system firmware, thereby reducing validation and inventory issues.

–Potential for faster boot. Another advantage of UEFI option ROMs is the ability to initialize only those needed to boot the OS and load the rest later through UEFI function calls from the OS, which speeds the boot process. It requires that the OS utilize a native UEFI interface and that the OS loaders used are also UEFI capable. This benefit has been proved on complex systems between legacy and UEFI solutions, taking the boot speeds from 40 seconds down to 15 seconds in one case.

–The modularity of the PEI and DXE modules allows for faster integration of differing code modules. In some cases, this allows for the faster adoption of the code bases’ newer technologies into the platform. It is believed that legacy system BIOS would be unable to integrate new and complex concepts such as Intel® Trusted Execution Technology (Intel® TXT) without extended time in development and validation. Quickly integrating new bus support and in turn new system firmware and OS storage solutions are also a benefit of UEFI. It has been proved that legacy code bases can have difficulty integrating newer technologies.

–UEFI Shell. The shell was designed to support features from DOS or UNIX environments in order to be a potential replacement for these older OS. Many of the same comma...

Table of contents

• Cover
• Title Page
• Copyright
• Contents
• Chapter 1: System Firmware’s Missing Link
• Chapter 2: Intel Architecture Basics
• Chapter 3: System Firmware Terms and Concepts
• Chapter 4: Silicon-Specific Initialization
• Chapter 5: Industry Standard Initialization
• Chapter 6: System Firmware Debug Techniques
• Chapter 7: Shells and Native Applications
• Chapter 8: Loading an Operating System
• Chapter 9: The Intel ® Architecture Boot Flow
• Chapter 10: Bootstrapping Embedded
• Chapter 11: Intel’s Fast Boot Technology
• Chapter 12: Collaborative Roles in Quick Boot
• Chapter 13: Legal Decisions
• Appendix A: Generating Serial Presence Detection Data for Down Memory Configurations
• Index