第1页 / 共215页
第2页 / 共215页
第3页 / 共215页
第4页 / 共215页
第5页 / 共215页
第6页 / 共215页
第7页 / 共215页
第8页 / 共215页
coreboot 及UEFI 集成intel fsp书籍.pdf
Contents at a Glance
Contents
About the Authors
About the Technical Reviewers
Acknowledgments
Foreword
Introduction
Chapter 1: Introduction
What Is Embedded Firmware?
Where Is Firmware?
What Do Firmware Engineers Do?
Firmware Preparation for New Hardware
The Mystery of Bits
Programming Guides
The Intel® Firmware Support Package
The Uniqueness of Embedded Firmware
The Choice of Firmware Stacks
Welcome to the Era of the Internet of Things
Technical Coverage in This Book
The Future of Firmware
Chapter 2: Firmware Stacks for Embedded Systems
Is a One-Size-Fits-All Solution Possible?
Microkernel
Real-Time Operating S ystem (RTOS)
Legacy BIOS
Implementations of the UEFI Framework
Open Source Firmware Stacks
Proprietary Firmware Stacks
Make o r Buy
The Advantages of Outsourcing
The Disadvantages of Outsourcing
In-House Development
Summary
Chapter 3: Intel® Firmware Support Package (Intel® FSP)
The Intel FSP Philosophy
What Is in Intel FSP?
Intel FSP Binary Format
Sample Boot Flow
Locating the Entries of Intel FSP
The Hard Way to Find Intel FSP APIs: Use Data Structure
The Easy Way to Find FSP APIs: Use Hard-Coded Constants
Programming Interface: The APIs of Intel FSP
TempRamInit
FspInitEntry
NotifyPhase
Intel FSP Output
API Execution Status
Temporary Memory Data HOB
Non-Volatile Storage HOB
Sample Code for Parsing HOBs
Customization of Intel FSP
Downloading Intel FSP
Microcode Patches
Relocating Intel FSP
Integration and Build
The Future of Intel FSP
What Is Coming in the Following Chapters
Chapter 4: Building coreboot with Intel FSP
The Introduction of coreboot
The Philosophy of coreboot
A Brief History
v1: 1999–2000
v2: 2000–2005
v2+: 2005–2008
v3: 2006–2008
2008 LinuxBIOS Renamed “coreboot”
v4: 2009–2012
v4+: 2012–2014
Further Reading
Prerequisites for Working with coreboot
Community Organization
Git and Gerrit
Git Commit Messages
coreboot Sign-off Procedure
Developer’s Certificate of Origin 1.1
Adding Your Sign-off
Working with the coreboot Community
coreboot Do’s
coreboot Don’ts
Nonsource Binaries in coreboot
A Hands-on Example: Building coreboot for the MinnowBoard MAX Mainboard
Environment
Hardware: MinnowBoard MAX
MinnowBoard MAX Platform Details
Development Directory
Downloading Intel FSP
Installing Intel FSP
Downloading the coreboot Source
coreboot Toolchain
coreboot Commit Hooks
Creating a coreboot Development Branch
Building the Mainboard
On the Menuconfig Menu
On the Chipset Menu
On the Devices Menu
Build
Summary of Commands
Flashing the ROM
Preparing the Flash Programmer
Flashing the ROM Image
coreboot Internals
Boot Stages
Additional Files
CBFS
An Example of CBFS
CBFS Size
Special Binaries
Boot Flow Using Intel FSP
Reset Vector and Bootblock
romstage
ramstage
Payload
coreboot Source
coreboot Device Tree
Chips and Devices
Device Tree Variables
A Device Tree Example
Chip Operations
Device Operations
coreboot Hardwaremain State Machine
State Machine States
State Machine Callbacks
Mainboard
The Chipset Driver
Chipset FSP UPD Options
The FSP Driver
Kconfig
xcompile
Payloads
SeaBIOS
GRUB 2
FILO
iPXE
TianoCore
Depthcharge
U- Boot
Memtest86+
libpayload
coreboot Troubleshooting and Debugging
Postcodes
Serial Debug
EHCI USB Debug
Summary
Chapter 5: Chrome book Firmware Internals
About Chrome book and Chrome OS
Chrome OS Firmware Overview
Chrome OS Security Philosophy
Chrome OS Security Guiding Principles
Power wash
Chrome OS Boot Modes
Verified (Normal) Mode
Recovery Mode
Developer Mode
Chrome OS Coreboot
x86
ARM
Depth charge Payload
libpayload
Verified Boot
Verified Boot and Kernel Security
Chrome OS Firmware Boot Log
Boot Times Log
Chrome OS Firmware Event Log
Google SMI Linux Kernel Driver
Chrome OS Extensions to the Firmware Image
FMAP
BOOT_STUB FMAP Section
Chrome OS Firmware RW FMAP Sections
An fmap.dts (RW_SECTION_A) Example
Google Binary Block (GBB)
GBB: HWID v3
GBB: Firmware Bitmaps
GBB: Firmware Keys
GBB: Boot Flags
Vital Product Data ( VPD)
Firmware TPM Usage
Chrome OS Firmware Update
Chrome OS Utilities
flashrom
gbb_utility
GBB Flags Utility Script: set_gbb_flags.sh
crossystem
mosys
Google Embedded Controller
Power Sequencing
Battery Charging
Thermal Management
Keyboard Controller
Other Peripheral Controls
Chrome EC Software Sync
Software Sync Steps
Summary
Chapter 6: Intel FSP and UEFI Integration
Introduction to EFI
Introduction to FSP
Introduction to EDK II
Summary
FSP Components
FSP Wrapper Boot Flow
Generic FSP Wrapper Boot Flow
Normal Boot
Boot Flow
Memory Layout for a Normal Boot Flow
FSP Normal Boot Data Structure
S3 Boot
Boot Flow
S3 Memory Layout
S3 NV Data Passing
Capsule Flash Update
Boot Flow
Capsule Update Memory Layout
Recovery Boot Flow
FSP Recovery Memory Layout
coreboot Payload Based upon EDK II
Building Minnow and MinnowMax with FSP
Future of the Intel FSP
Conclusion
Chapter 7: Building Firmware for Quark Processors
Overview of UEFI and PI
History of Implementations and Specifications
Introduction to EDK II Building Blocks
PKG: Packaging
MdePkg
MdeModulePkg
IntelFrameworkPkg
IntelFrameworkModulePkg
Packages
PCD: Platform Configuration Database
Syntax
DEC: Platform Declaration File
Syntax
DSC: Platform Description File
FDF: Flash Description File
Syntax
Build: The EDK II Build Command
INF: INF File
More Information
Introduction to the EDK II Subset
Introduction to Quark
ROM Flash Image Size Optimization
Fixed Resource
DRAM/SMRAM
Remove Features
Reduce Features
Compiler Options
Build Options
Results of the TinyQuark Optimization
RAM Footprint Optimization
Optimization
Result of Memory Usage Optimization
Conclusion
Chapter 8: Putting It All Together
RTOS and Intel FSP
Intel FSP and Open Source Philosophy
Customization and Production of Intel FSP
It Is a Community Effort After All
Appendix A: Sample Boot Setting File (BSF)
Index
For your convenience Apress has placed some of the front
matter material after the index. Please use the Bookmarks
and Contents at a Glance links to access them.
Contents at a Glance
About the Authors ���������������������������������������������������������������������������� xv
About the Technical Reviewers ����������������������������������������������������� xvii
Acknowledgments �������������������������������������������������������������������������� xix
Foreword ���������������������������������������������������������������������������������������� xxi
Introduction ���������������������������������������������������������������������������������� xxiii
■
Chapter 1: Introduction
������������������������������������������������������������������ 1
■
Chapter 2: Firmware Stacks for Embedded Systems
������������������ 13
■
Chapter 3: Intel
® Firmware Support Package (Intel® FSP) ����������� 25
■
Chapter 4: Building coreboot with Intel FSP
�������������������������������� 55
■
Chapter 5: Chrome book Firmware Internals
������������������������������� 97
■
Chapter 6: Intel FSP and UEFI Integration
���������������������������������� 121
■
Chapter 7: Building Firmware for Quark Processors
������������������ 145
■
Chapter 8: Putting It All Together
����������������������������������������������� 173
■
Appendix A: Sample Boot Setting File (BSF)
������������������������������� 179
Index ��������������������������������������������������������������������������������������������� 191
v
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.
xxiii
■ introduCtion
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.
xxiv
■ introduCtion
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”.
: Platform Initialization and Unified Extensible
PI and UEFI
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.
xxv
■ introduCtion
•
•
•
•
•
•
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.
: Firmware Support Package. Intel FSP is the silicon
FSP
initialization module that Intel produces to encapsulate basic
silicon initialization code.
Microprocessors, CPU (Central Processing Unit), chips
terminologies are used interchangeably to represent the silicon
that does more of the general computing and control tasks.
: These three
I/O
: Input and output.
: Silicon-on-Chip, Silicon-in-Package. This
SoC, SOC, SIP
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.
: Today’s SoC
Southbridge, northbridge, and companion chips
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
xxvi
Chapter 1
Introduction
If you can fix a hardware bug in firmware, it’s not a bug but a
documentation issue.
—An anonymous hardware manager
What Is Embedded Firmware?
Since you are reading this book, you must have some understanding of what the words
embedded and firmware mean in the context of computer technology. There are quite a
few interesting discussions on the Web about the difference between firmware engineers
and embedded engineers. Some say that an embedded engineer is a software engineer
turning into a hardware engineer, and a firmware engineer is a hardware engineer turning
into a software engineer. There is some truth to this because most firmware engineers
learned how to design circuits in school, but there are definitely a lot of smart firmware
engineers out there with a computer science or nonhardware degree. Regardless, writing
firmware is a unique skill that deals with both hardware and software at the same time.
You need to know something about signal strength, timing, voltage, and at the same time,
data structure, algorithm, and modularity.
For the purposes covered in this book, let’s define firmware as the layer of software
between the hardware and the operating system (OS), with the main purpose to initialize
and abstract enough hardware so that the operating systems and their drivers can further
configure the hardware to its full functionality. To make embedded systems run faster
and be more robust, the relationship between the firmware and the OS is transitioning
from isolating themselves from each other to cooperating with each other. In the past, you
might have seen the same hardware initialized by the firmware first, and then initialized
again by a driver in the OSas shown in Figure 1-1; but in modern systems, you see more
effort in trying to eliminate redundancy between the firmware and the OS.
1
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
