Embedded Firmware Solutions: Development Best Practices for the Internet of Things (2015)

Introduction

We consider ourselves lucky enough to live in an era when new things and new ideas seem to come out every few years, if not every few days. We are not only experiencing an explosion of new ideas, but also witnessing some existing technologies being completely maxed out in our lifetime, including the semiconductor technology. Since Brattain and H. R. Moore made a demonstration of the first transistor at Bell Labs on December 23, 1947, the semiconductor, as we know it today, is reaching its physical limit, even though we are still trying very hard to shrink it below 10 nanometers. For the sake of argument, even if we can still shrink a couple of nanometers below 10 nanometers, how much further can we really go without changing the fundamental theory the technology is based on?

In the meantime, there are many other technologies that are approaching the limits of our sense and sensibility. Do we need more than 12 bits of color depth that shows more than billions of colors? Do we need a frame rate that is beyond what our eyes and brain can process? Do we need cars that go faster than our own response time? We now have display devices, media playback technologies, and transportation vehicles that achieve the best that they need to be.

Even though that is the case, there are still unlimited opportunities to make devices smarter and more connected to make our lives easier and safer. People are calling these devices the Internet of Things, or IoT for short. The explosive cycle of the IoT has just begun: cars will be talking to cars in the near future, thermostats and sprinkler systems can adjust themselves based on current weather forecast, buildings can manage lighting and air circulation based on where people are, and the list goes on and on.

Yes, this book is related to the explosion of the Internet of Things. We are addressing a technical area that is rarely talked about—the firmware inside of the Internet of Things. Firmware is the first piece of software that runs after silicon, coming out from the power-on reset state. Sometimes it is mysterious to people why building a firmware stack is hard and why firmware can be problematic. Considering the fact that the time it takes to run a piece of firmware is only between subseconds to a few minutes at most, why are we writing a book about it? After all, there are already books that talk about BIOS, UEFI (beyond BIOS), and techniques to optimize the firmware to boot faster. Why do we need yet another book to talk about firmware for the Internet of Things and the embedded system in general? There is one important reason: the firmware for IoT is different from the firmware running on a PC (BIOS or UEFI-based firmware), and there are many unique requirements for IoT firmware, and we will talk about them in the second chapter of this book.

This is what this book is about. We are going to examine the uniqueness of firmware requirements in embedded systems and IoT devices, and then we are going to introduce the technique Intel introduced to help IoT system firmware developers overcome the steep learning curve in developing a firmware stack for their versatile IoT products.

In this book, we are going to use two open source firmware stacks—coreboot and UEFI—to demonstrate the concept and show the steps to develop a workable firmware stack using widely available platforms from Intel. We are also going to show how the firmware works in a Chromebook, and what it does in a Chromebook, and we will also discuss the firmware for Intel® Quark family.

The targeted audience for this book are firmware engineers, hardware engineers, software engineers, and other professionals curious about IoT firmware. This is a good book for students who are learning about firmware, because we are going to give step-by-step instructions about how to build a workable firmware stack using commercially available platforms. For developers who have been involved in PC firmware, this can be a good reference book to understand the differences between PC and IoT, and the alternative solutions available. For people who have been struggling with Intel® Architecture (IA) and its firmware stack due to a lack of technical information from Intel in the past, this book reveals an opportunity for you to quickly get over the silicon initialization hump, and you will be able to quickly develop an effective firmware stack using the techniques learned from this book.

This book uses a lot of pages to describe the Intel® Firmware Support Package (Intel FSP) because it is a way to encapsulate the complexity of silicon initialization to make firmware development work easier. Since its launch in October, 2012, many developers and designers of alternative architectures have benefited from this product.

Why Should You Read this Book?

There are not many books out there talking about firmware because it is not a standard discipline that can be talked about generically. Every subject in the realm of firmware can be a book of its own, and there have been books about UEFI, BIOS, Fast Boot, RTOS, assembly languages, and so forth. There are also many system requirements and constraints that can dictate how a firmware is chosen and written; therefore, it is a topic that cannot be easily addressed holistically without an objective. Our objective is to show you how you can take advantage of Intel Architecture, and how to prepare a firmware stack for Intel microprocessors regardless of the firmware stack that you choose. There will be areas that are not covered in this book, such as power management and secure boot features, but readers can certainly find in-depth discussion of those topics in other technical books in the market. This book is written to help you build a workable firmware stack for Intel Architecture.

What Chapters Should You Read?

Since there are many interesting but distinctly different topics surrounding IoT device firmware, busy readers can pick and choose the chapters to read and skip if needed.

If you are just curious about what firmware options you may have for IoT devices, you may read Chapters 1 and 2 before diving too deeply into actual implementations.

If you are interested in developing a coreboot-based firmware solution for Intel Architecture, you can get a complete picture of the process by reading Chapters 1, 3, and 4.

If you are more interested in developing an EDK II–based firmware solution for Intel Architecture, you can get a complete picture of the process by reading Chapters 1, 3, and 6.

If you are more curious about what Chromebook is about and how the firmware for Chromebook works, you can read Chapters 1, 3, 4, and 5.

If you have heard about Quark and you are interested in building firmware for Quark, you can read Chapters 1, 2, 3, 4, 6, and 7. Why do you need to read more chapters for Quark? It is not because it is complicated, it is because it can be used in many varieties of applications using different firmware stacks. If you want a complete picture about firmware solutions for embedded applications and IoT devices, you should take your time and read all of the chapters in this book. After all, this is the purpose of the book: to give you a complete picture of the firmware solutions for IoT devices.

Hobbyists should be able to obtain a platform mentioned in the chapters, follow the instructions to download the source trees and tools, build a firmware image to try on a real platform, and enjoy the accomplishments.

Every firmware stack has its advantages and disadvantages; there will be situations when a developer needs to pick a different and unfamiliar firmware stack for the applications at hand. From time to time throughout the book, you might find some unfamiliar terminologies. We will list them here for reference. If you are still puzzled by a specific terminology, Wikipedia is probably the best resource to check. Internet search engines may be the second best source, but careful filtering of information is needed.

· Bootloader: This term might be confusing from time to time. In coreboot, bootloader is identified as the payload, which loads the OS, but in some cases, bootloader is used to represent the code from the reset vector to the hand-off point to an OS. The definition changes based on context. Also, this term is mostly used outside of the Intel Architecture (x86) world, where hardware initialization is not as complicated. In this book, we will not use bootloader to represent the complete firmware stack. When you see this term in this book or outside this book, you need to read the context to see which part of the firmware stack it is referring to.

· Firmware stack: In this book, we use the term to represent all the components in a firmware solution; there might be phases in the boot process of a firmware solution, but the term firmware stack will cover them all. We will also refer the firmware stack used to integrate Intel FSP as the “host firmware”.

· PI and UEFI: Platform Initialization and Unified Extensible Firmware Interface. These are two major standards governed by the UEFI Forum. People are frequently using UEFI to represent the modern firmware stack that boots 64-bit OS in a PC. “UEFI BIOS” is frequently used to represent the firmware stack developed based on UEFI and PI specifications. PI specifications is a set of specifications that focuses on platform and silicon initialization.

· BIOS: Basic Input/Output Systems. This is a term that is used “conveniently” to represent the firmware stack of a PC, even though it is no longer the same 16-bit hardware abstraction layer to interface with a 16-bit OS. Today, as a habit, people are still using this term to call the firmware stack of a PC, even though the firmware stack has become more powerful, more dynamic, and has more features. You will see “legacy BIOS” and “UEFI BIOS” terms in the book when we describe the implementations of PC firmware stacks today. Some companies might still use “BIOS” in the names of their products, but the purpose is to associate their products to a more familiar terminology so that PC developers understand the products better.

· FSP: Firmware Support Package. Intel FSP is the silicon initialization module that Intel produces to encapsulate basic silicon initialization code.

· Microprocessors, CPU (Central Processing Unit), chips: These three terminologies are used interchangeably to represent the silicon that does more of the general computing and control tasks.

· I/O: Input and output.

· SoC, SOC, SIP: Silicon-on-Chip, Silicon-in-Package. This represents silicon designed to include more than one component on a die or in a package; typically these components are CPU cores, northbridge(s), I/O components, and other glue logic. From the outside, they function as an integral unit.

· Southbridge, northbridge, and companion chips: Today’s SoC still contains components that we used to call northbridge and southbridge for two distinct functions that used be on different sides of a front-side bus (or a high-speed point-to-point bus) that connects all the components internal to the chip. Even though internal buses have evolved in modern SoC designs, the names northbridge and southbridge remain in many code bases to represent the functions that used to be there: northbridge deals with CPU, memory controllers, and other related features, and southbridge deals with I/O–related features.

Obviously, this book cannot cover all of the peripheral knowledge that you might be interested in. Here are online resources and links for further reading and research:

· http://www.intel.com/fsp

· http://www.tianocore.org

· http://www.uefi.org

· http://www.coreboot.org