System Firmware
An Essential Guide to Open Source and Embedded Solutions
This Apress imprint is published by the registered company APress Media, LLC, part of Springer Nature.
The registered company address is: 1 New York Plaza, New York, NY 10004, U.S.A.
This book contains key aspects of an evolution that is about to happen for system firmware (a.k.a. the BIOS). The last similar scale change in system firmware happened in the late 90s, from BIOS to UEFI. While the birth of the BIOS (e.g., the separation of system firmware from the operating system) in the 70s led to the era of the PC, UEFI laid a solid foundation for the success of computer desktops and servers, which is the foundation of the modern Internet world.
Now, with the Internet moving toward cloud services and artificial intelligence, will the innovation of UEFI continue to meet needs or will there be an evolution in system firmware?
Thomas Khun described in his book The Structure of Science Revolutions the concepts of paradigms and revolutions. These concepts apply not only to scientific research but also to the computer industry. We normally operate in a paradigm. A well-established paradigm is very useful and powerful, and thus we tend to neglect stuff outside of the paradigm. As time goes by, the anomalies pile up and then a paradigm shift happens, which is called a revolution.
Silicon initialization binary. The silicon vendor owns this.
coreboot. It does platform initialization. It adopts the Linux kernel design philosophy and it has a Linux kernel style development community/process.
LinuxBoot. As the bootloader, its main responsibility is to find the target kernel/OS and jump-start it. LinuxBoot has the Linux kernel as-is, and u-root as its initramfs.
Deployed in the majority of servers
Supported by most modern operating systems
Worked on by the majority of the system firmware community
One anomaly is the shift to cloud computing. Hyperscalers need to manage servers at scale, and in the meantime they often have feature differentiation and shortened time to production (TTP) needs.
OSF allows hyperscalers to own the system firmware more easily, since a smaller engineering team will be capable of developing and managing it at scale, enabled by industry collaboration. With Linux playing an instrumental role in OSF, Linux engineers are turned into system firmware engineers, therefore system firmware can be managed at scale just like Linux. In addition, new feature support and bug fixes in Linux can be leveraged in system firmware directly, leading to improved stability and reduced security vulnerability.
Another anomaly is the arrival of the computer architecture golden age. David Patterson declared that, like the 1980s, the next decade will be exciting for computer architects in academia and in industries. Not only scientific research but also societal advancements (such as Web 3.0 and the metaverse) demand exponential growth in computational power. On top of that, the focus on computation is shifting from general purpose computing to artificial intelligence workloads. However, Moore’s Law is not supported by chip process technological improvements alone any longer. All of these changes require a new generation of server processors and server systems. New technologies and design philosophies beyond the von Neumann architecture have been springing up. Other examples include heterogeneous processor design enabled by chiplet and UCIe, and new interconnect technologies such as CXL, to name a few. All of these new technologies require timely development of system firmware as part of holistic solutions.
In the meantime, another event that happened in the industry was the maturation of Linux into the de-facto standard of the OS industry. Linux answers computer technology advancements gracefully and manages versatility effectively. Why should we develop software for the same technology twice–once for Linux, and another time for system firmware? Why should we stabilize and harden software for the same technology twice? Why should we require two vastly different skill sets for system firmware engineers and kernel/OS engineers?
You might ask whether OSF is mature enough for prime time. This is an important question. After all, technology alone is not good enough; we see too many cases where a good technology does not gain traction in the industry.
With over 10 years of technology accumulation, FSP (Firmware Support Package) technology, as Intel’s silicon initialization binary, matured. FSP is a Plan-Of-Record for Intel server processors, starting with Intel’s Sapphire Rapids Scalable Processor. In addition, as part of Intel’s OneAPI initiative, Vincent Zimmer coined Universal Scalable Firmware (USF) architecture, which supports OSF.
On the other hand, coreboot has been shipped in hundreds of millions of devices, notably chromebook, among other products. LinuxBoot has been running at-scale at some of the world’s largest data centers.
Those components together, as open system firmware for servers, have seen great progress in the last several years. In 2021, OCP (Open Compute Project) accepted OSF for OCP DeltaLake server (based on Intel Copper Lake Scalable Processor) and is available for the community. An OCP community lab is being built to enable access to OCP gears, with DeltaLake servers included, for the community. OSF is planned to be deployed in production in ByteDance’s data centers.
In addition to technology maturity, the OSF for servers also benefits from a growing ecosystem and open source community. Subsequently, a company can spend a minimum amount of resources to get OSF for servers into production. The majority of system firmware features are the same among the server developers, so why would they not work together? In other words, some server developers may not want to hire 30 system firmware engineers; instead, they want to have 3 system firmware engineers that work with partners and communities to achieve the results traditionally done by 30 engineers.
coreboot and LinuxBoot are fully open source, and each participant benefits from community resources for new features and bug fixes. Silicon vendor company binary blobs are not open source (yet), but silicon vendor companies have been allowing their customers to engineer the solutions together. Such a new collaboration model is actually one of the key factors that OSF for servers has been advancing at a fast pace in the last few years.
We are fortunate to have the firmware industry’s best minds to author and review this book, to enable the industry to rethink system firmware. Even though the groundwork has been going on for some years, the actual paradigm shift has just begun. The benefits of such a paradigm shift to the computer industry at large has just started to show up.
I hope you are as excited as we are to benefit from and contribute to this paradigm shift. Some years later, once we live in a world where a new processor (and/or technology) has system firmware support in a fraction of the time that it takes today, where system firmware is not a black box to owners and the computer industry at large, and where firmware engineers’ productivity has dramatically increased compared to today, we can proudly say that we did it together!
Firmware is capable of providing consistent behavior across different architectures.
It empowers the system integrator with its flexible nature to configure the hardware interface and also to communicate with the operating system.
It is the key to optimizing the platform resources to maximize power and performance efficiency.
We must try to avoid bugs or detects during product development but providing workarounds or fixing the bugs inside firmware is comparatively easier than other layers because changing hardware is costly and modifying operating systems is time consuming.
Firmware has the uniqueness to focus on security, both SoC-based security and platform security.
Also, this field is undergoing rapid changes as underlying hardware is more open now, more and more new computing devices are coming to market to reduce redundant tasks or manual efforts, security is concern, and cost is key in product development, thus device manufacturers (ODM/OEMs) are exploring opportunities to break the typical boundary of developing system firmware for their products in a closed environment. In this book, we ensure the fundamental concepts remain clear, so you can be market ready with such a migration in technology.
We wrote this book as a text for readers like you who want to explore the future of system firmware. The range of target audience could vary between grade school students, to recent college graduates working on developing firmware skill sets as per market needs, to embedded firmware/software engineers migrating product development from closed source firmware to open source firmware for product adaptation needs. This book will benefit engineers working on various bootloaders like open source firmware, UEFI, and Slim Bootloader development. As prerequisites, we assume that you are familiar with basic programming knowledge like assembly and C. The hardware topics required for understanding firmware/BIOS are included in Chapter 3. For code examples, we use predominantly C, with some pseudo code, but the idea here is that you can still understand the code logic without a thorough knowledge of a high-level programming language like UEFI.
The fundamental firmware design concepts covered in this book are mostly applicable for all SoC architectures (i.e., x86, ARM, RISC-V, etc.) with any platform design (i.e., personal computers, evaluation boards, servers, etc.). Our aim is to present these concepts and design principles in general without being tied to one particular architecture. We will present a majority of examples with widely used architecture and hardware references to make it a more real use case scenario. If a feature or functionality doesn’t exist in all architecture and thus is specific to a SoC architecture, we will state this explicitly.
“The only way to be truly satisfied is to do what you believe is great work.”
—Steve Jobs
The definition of system firmware changes over time. Typically, it starts with no boot firmware for underlying hardware to modern computing systems where system firmware is the product differentiator, due to the level of optimization being put inside system firmware to allow configuring hardware and establish the trusted communication between operating system and hardware, and also at the same time provide electrifying performance.
For example, the minimum expectation for an end user is to see that the device is operational almost instantly by pressing the power button or holding the device in hand or starting the ignition of the car engine. Keeping the configurability of accessing underlying hardware, or ensuring instant boot, the other key criteria for system firmware is that it’s trustworthy. With firmware being the closest entity in system design, it’s easy to affect the hardware functionality and make it compromised. A compromised system firmware is an ultimate risk for the entire system, regardless of how secure the operating system may be. In the history of system firmware or the boot firmware evolution process, only a small group of people understand the background scene prior to booting to the operating system.
ODM/OEMs had no control on their platform design and had to rely on a third party to bring up their platform.
CPU or SoC vendors “only” trusted a selective third party for sharing the key knowledge to bring up their processors or chipset.
They were unable to optimize the Bill of Material (BoM) cost, as a result of being dependent on third-party system firmware vendors, and they were unable to utilize engineering resources on the ODM/OEM side due to limited knowledge of the high-level proprietary closed source system firmware.
They were unaware of SoC and/or platform security because of third-party involvement and they had no means to review the boot firmware code due to its closed source nature.
To find an amicable way out here, the market looked for a transition to a simpler, robust, transparency-enabling model of system firmware. It’s not possible for SoC vendors to still be able to control the platform enabling model. In the present situation, there is more interest in knowing what’s happening behind the curtain of booting to the operating system to define a transparent process in order to build a trustworthy system. There is interest in knowing how to optimize the boot firmware flow, reduce its boundaries, and make it more scalable for the operating system to leverage the privileged mode that the system firmware belongs to while talking to the hardware. This process might help to reduce the system boot time requirement for exclusive hardware/firmware-centric communication.
This is quite an attractive period for system firmware developers and companies who want to migrate their firmware development from a closed source solution to open source, to minimize their development costs, to bring transparency into product development process, and at the same time, to ensure time to market for their new products. Therefore, the key part here is choosing the right firmware solution as per their product needs.
This introduction explains the general challenge of system firmware migration and also describes what you can expect in the remainder of this book.
Migration to Open Source System Firmware
The term migration is being used in this book to refer to the transition of the existing firmware development model from closed source to open source, or to adopt the open source firmware development model for the new product development cycle.
This migration is not limited to porting the firmware alone; it’s also an ecosystem change. For example, the program source code—whether implemented based on closed source firmware or open source firmware—is written with the capability of underlying hardware in mind. Therefore, it is very important to keep in mind the required hardware capability to develop the system firmware using an open source model is also expected to be available to support this migration.
The repository to maintain the source code is also important to ensure the real open source visibility, and to provide an opportunity for the open source community to review the source code rather than limiting the firmware development among few companies through peer review. Finally, there is the build infrastructure that is being used to stitch other firmware ingredients (as applicable) with SoC architecture to qualify as an integrated firmware image (IFWI). Typically, different SoC vendors use their proprietary stitching tool for customization of IFWI ingredients as per the product requirement. But for migration to open source firmware development, it’s expected to have a unified open source-friendly tool to meet such requirements.
The important part in this whole open source migration is the system firmware code development model. Over time, the platform-enabling strategy has gone through a rapid transition. Even a few years back, SoC vendors and device manufacturers were only considering a single entity for boot firmware, typically Unified Extensible Firmware Interface (UEFI). With an open source firmware development model, where more than one entity is combined together to call it as system firmware, this assumption won’t hold. At a high level, open source system firmware may consist of two major components : boot firmware and payload.
There are several open source boot firmware options available to perform the CPU and chipset initialization. Based on the nature of the product and applicable market segment, device manufacturers choose the right boot firmware. It might also be possible that boot firmware itself may consist of several other associated firmware binaries that are restricted in nature and not necessarily available in open source due to SoC vendors or device manufacturer product requirements. This model is referred to as hybrid and there are sections to explain the work model to support such needs as well.
A boot firmware also needs to have a dedicated payload (typically, it doesn’t have a payload integrated into it by default) to detect a special boot signature to boot to the kernel from possible boot media. A payload can be defined as another boot firmware, but in a generic manner, it doesn’t need to perform specific CPU or chipset programming and is more architecture neutral and platform independent. The major task for a payload is to ensure booting to the operating system. Therefore, it’s preferable to have a configurable option with boot firmware to choose the payload as per the target operating system need.
Motivation for This Book
The PC industry is going through a transition where the typical device manufacturers are willing to design their products in a more transparent manner. There is significant interest in understanding the secretive art behind booting to the operating system. This book highlights the underlying ecosystem changes. It also makes system integrators aware of the common challenges while migrating from a well-defined process to a new, evolving, open source-based firmware development, to maintain or improve the product quality and also to meet the time to market.
First, it’s important to understand the legacy of the system firmware— its origin, architecture overview, and the reason why real-world firmware development is expecting this migration—with case studies. Additionally, this book provides an architectural overview of various popular boot firmware options. Types of firmware discussed will include both closed source and open source in nature, such as UEFI, coreboot, and Slim Bootloader as well as their applicable market segments based on product development and deployment requirements.
This book represents the journey of system firmware from its origin to now. Also, it captures the evolution of system firmware from complex and closed source to the modern firmware where it is still a hybrid between closed and open source. Finally, it attempts to predict the market transition about the future firmware model. This book tries to find the most simplistic boot firmware solution, using the open source firmware development. We deliver this information as a handbook to you so that you know how to choose the right boot firmware for your products and develop your own boot firmware using open source.
Who Is This Book For?
This book covers embedded system and firmware programming models. Readers are expected to be comfortable with low-level programming languages such as assembly and C. A few topics will require specific knowledge of UEFI.
As this book will focus on open source firmware developments, the target audience could vary between students interested in STEM topics, to recent college graduates working on developing skill sets as per market needs, to embedded firmware/software engineers migrating product development from closed source firmware to open source firmware for product adaptation needs.
Also, this book could be useful for engineers working in open source firmware development. A few sections will require specific domain knowledge like UEFI, as silicon vendors might be keen on using hybrid work models.
A comprehensive architecture overview of all market standard and popular boot firmware (a.k.a. the BIOS, the basic input and output system)
How to pick the correct BIOS for the required target hardware
How to design a hybrid workflow model for the latest chipset platform
- Understanding various popular payload architectures and offerings for embedded systems
Picking the right payload for the boot firmware solution to boot to the operating system
Various case studies done on embedded systems with different CPU architectures: x86 and ARM-based solutions to optimize the system firmware boot time, demonstrating the power of hardware innovation that influences firmware design, usage of kernel features in firmware trusted computing boundaries, and understanding the product development cycle using open source firmware development
Overview
In general, this book is built with an assumption that you are reading the chapters in sequence. Each chapter builds on a knowledge block gained from earlier chapters. As the book progresses, you will apply this knowledge.
Chapters can be divided into two categories: developing concepts and applications. In concept chapters, you will learn about various aspects such as hardware knowledge required prior to any system firmware development, designing a minimal system firmware, and understanding various different system firmware architectures and payloads. In the application chapters, you’ll build a few applications using what you’ve learned from the concepts chapters.
Starter: Chapter 1 provides the historical introduction about the boot firmware and different solutions available like closed source boot firmware and open source boot firmware. We will define the goals for you to create your own open source boot firmware for target hardware.
Knowing your hardware: Chapter 2 provides a detailed understanding of hardware interfaces that firmware needs to manage prior to booting to an operating system. This is a very basic understanding section for system boot firmware without which you really can’t make progress on your system firmware journey.
Understanding the BIOS and its minimalistic design: Chapter 3 provides details about the BIOS. It explains the basic characteristics that a firmware has to have to call it a BIOS, as well as the minimum requirement to design a boot firmware.
System firmware architecture: Chapter 4 provides architectural details about popular or market leading system firmware along with applicable market segments because of their characteristics. The idea here is to understand the pros and cons of each offering.
Hybrid firmware architecture: Chapter 5 explains the ecosystem balance with open source firmware development using minimum closed source blobs. Open source boot firmware development has an enormous dependency on SoC vendors for providing the documentation and reference code for CPU, memory, and chipset initialization. This chapter defines the hybrid firmware architecture, which is useful to build open source firmware solutions when working with closed or restricted SoC hardware platforms.
Payload: Chapter 6 explains the necessity of the payload for the boot firmware. It provides architecture details of all popular payloads and current offerings to help users to choose the correct payload for their product.
Case studies: Chapter 7 covers a case study done on real hardware. This real-life example will help you think through innovation while designing your own open source boot firmware.
The Appendices include source code data types based on Chapter 7 and system firmware postcodes details. The Glossary and Index connect back to the main topics.
The system firmware journey from its origin to today’s modern architecture and looking into the future is vast. It needs subject matter experts to contribute and share their knowledge to complete this journey. This book involved contributions from talented industry experts who we are honored to work with, and they deserve acknowledgement.
We would like to thank Maurice Ma and Ravi P. Rangarajan for sharing the Slim Bootloader (SBL) knowledge and architecture details as part of Chapter 4. A special mention goes to Karthik Ramasubramanian, Shelley Chen and Hung-Te Lin for their input on depicting the applicability of hybrid firmware architecture on all leading SoC platforms as part of Chapter 5.
Subrata thanks Vincent Zimmer, Ronald G. Minnich, and Stefan Reinauer for their expertise and for making this venture enjoyable and learnable. Above all, Subrata is thankful for his family, especially his wife, Barnali, and daughter, Samriddhi, who were patient with many nights and weekends consumed by this effort, and his parents, who influenced his technical curiosity, which translated into book development.
Vincent thanks Subrata for the great collaboration on this project and in other endeavors. Along with Subrata, he thanks collaborators across the different communities, standards groups, and his employer.
When not writing or working, he enjoys watching sports (especially football) or spending time with his daughter. A fun fact about Subrata is he is a strong believer in time travel.
You can chat with Subrata on Twitter at @abarjodi or at www.linkedin.com/in/subrata-banik-268b3317/.
Jonathan has been spearheading coreboot/LinuxBoot development for servers based on Intel Xeon server processors, through multiple generations from ground up. He initiated and has been leading an industry coalition on this journey. Prior to Meta, he led UEFI/ATF development for ARM servers and made it commercially viable from the ground up; he also led UEFI and windows/Linux driver development for smart phones.
Jonathan is a frequent speaker on firmware/software topics at industry conferences. He is an active participant of several industry standard organizations (such as CXL forum, OCP, UEFI forum) and made a number of specification changes.