Intel fsp

Intel fsp DEFAULT


intel F S P

The Intel® Firmware Support Package (Intel® FSP) is a royalty-free option for initializing Intel silicon, designed for integration into a boot loader of the developer's choice. It is easy to adopt, is scalable to design, reduces time to market, and is economical to build. Intel FSP provides a binary package to initialize the processor, memory controller, and Intel® chipset initialization functions.

Intel FSP is designed for integration into a variety of boot loaders, including coreboot and TianoCore (open source Unified Extensible Firmware Interface (UEFI)).


Intel Firmware Support Package Overview

Firmware Flexibility Using the Intel Firmware Support Package (IDF 2014, PDF)

Creating the Intel Firmware Support Package (2.0) with EDK II (May 2016, PDF)

The Intel Firmware Support Package (2.0) with EDK II (May 2016)

Learn more

Older Versions with FSP 1.1

Creating the Intel Firmware Support Package Version 1.1 with the EFI Developer Kit II (April 2015, PDF)

Using the Intel Firmware Support Package 1.1 with the EFI Developer Kit II (April 2015, PDF)


Intel® Firmware Support Package (Intel® FSP) Binaries

10th, 8th & 7th Generation Intel® Core™ processors and chipsets (formerly Comet Lake Y-Series, Amber Lake, Kaby Lake Refresh, and Kaby Lake)AmberlakeFspBinPkgv2.1Intel® Atom™ processor E3900 product family (formerly Apollo Lake)ApolloLakeFspBinPkgv2.0Intel® Pentium® and Celeron® Processor N3000 Product Families and Intel® Atom™ x5-E8000 Processor (formerly Braswell)BraswellFspBinPkgv1.19th & 8th Generation Intel® Core™ processors and chipsets (formerly Coffee Lake Refresh, Coffee Lake, and Whiskey Lake)CoffeeLakeFspBinPkgv2.010th Generation Intel® Core™ processors and chipsets (formerly Comet Lake)CometLakeFspBinPkgv2.13rd Generation Intel® Xeon® Scalable processors and chipsets (formerly Cooper Lake)CedarIslandFspBinPkgv2.1Intel® Atom™ processor C3XXX product family (formerly Denverton)DenvertonNSFspBinPkgv2.0Intel Atom® x6000E series, and Intel Pentium® and Celeron® N and J Series processorsElkhartLakeFspBinPkgv2.110th Generation Intel® Core™ processors and chipsets (formerly Ice Lake)IceLakeFspBinPkgv2.17th Generation Intel® Core™ processors and chipsets (formerly Kaby Lake)KabylakeFspBinPkgv2.06th Generation Intel® Core™ processors and chipsets (formerly Sky Lake)SkylakeFspBinPkgv1.111th Generation Intel® Core™ processors and chipsets (formerly Tiger Lake)TigerLakeFspBinPkgv2.23rd Generation Intel® Xeon® Scalable processors and chipsets (formerly Ice Lake-SP)WhitleyFspBinPkgv2.1
  1. Youtube iwo jima
  2. 1950s moped
  3. Evertale app
  4. Flexible child mannequin
There's some good news beyond Intel's CPU microcode re-licensing to clear up the confusionamong users and developers this week: Intel is also re-licensing their FSP binaries to this same shorter and much more concise license.

The FSP "Firmware Support Package" binaries used by the likes of Coreboot, LinuxBoot, and Facebook's Open Compute Project is under this same license now as the CPU microcode files. The FSP bits have been closed-source for several generations but are used by Coreboot and friends for allowing their "BIOS" to be as open as possible otherwise. The Intel Firmware Support Package is basically the firmware that initializes the processor, memory controller, chipset, and other certain bits that unfortunately don't have open-source initialization code available.

The FSP up to this point has been under a fairly restrictive license that hadn't allowed for the easy redistribution of these binaries and other complexities. But now Intel has replaced that burdensome license with the same license text as they are using for their CPU microcode files. The short and unofficial summary of that license text is it allows for redistribution (and benchmarking, if so desired) of the binaries and the restricts essentially come down to no reverse-engineering/disassembly of the binaries and respecting the copyright. That license text in full is available from

This license change to the FSP comes a short time after they made available the Intel Coffeelake FSP.

Intel has confirmed in the Coreboot mailing listof this license change for their FSP and also within their GitHub repository.

That few paragraph license text replaces their previous nine pageFSP license. That now-replaced license can be viewed hereif you are interested.

Coreboot developers have confirmed to Phoronix the significance of this relicensing and should yield "a huge step towards better FSP integration into coreboot, LinuxBoot and TianoCore." One of the immediate benefits is much easier distribution rights on the binaries.

It's not as great as the FSP being fully open-source, but it's an improvement nevertheless, and at least they continue offering this updated FSP for new hardware generations so that new CPU/chipset support can be available via Coreboot/LinuxBoot.
FSP - 20th Anniversary Animation

~ hucktech ~

~ hucktech ~


2018-04-23 update: after receiving a courtesy request from Intel’s Director of Software Infrastructure, we have decided to remove this post’s technical contents while we investigate our options.

~ hucktech ~

~ hucktech ~

Vendors, your compiled code is an firmware attack vector, and makes it harder to trust your product. Secure Boot and signed images are not silver bullets. If you made golden images available, as per NIST 147, we could at least tell if your blobs have changed. But trusting blobs is not enough, there’s enough HW/FW vulnerabilities, and opportunities for attackers to subvert the supply chain. Only open source firmware will solve the firmware blob security problem. Intel has FSP, AMD has AGESA. All IBVs ship closed-source products, no open source vendors, and OEMs/IHVs ship closed-source drivers. Giving us an open source option would solve this problem. IBM claims the OpenPOWER is blob-free, but I’ve yet to verify this. RISC-V is also an ISA that also may be blob-free at the firmware level, depending on the manufacturer. Both OpenPOWER and RISC-V may offer some alternatives to current processors, if they wish to keep with status quo. I hope to see more security standards require the option to build firmware from source, and user ability to reinstall from their own locally-compiled version. And at least requiring that vendors ship hashes for all the blobs they ship.


Dear AMD, could you please release the Platform Security Processor (PSP) source code to the Coreboot / Libreboot project? (or publicly)
Thanks for the inquiry. Currently we do not have plans to release source code but you make a good argument for reasons to do so. We will evaluate and find a way to work with security vendors and the community to everyone’s benefit.
–AMD_jamesProduct Manager 487 points 4 hours ago


~ hucktech ~

[[UPDATE: See comment from one reader, I mistakingly took below quote to be from Bruce, where it is apparently from someone else. Oops.]]

Bruce Schneier has a new blog post on citizen cybersecurity, including advice for non-US citizens to avoid blobs in firmware.

I hope Intel and AMD are reading this. Are the patents in the IP you’re protecting in your FSP and AGESA binaries really worth the security risks you’re enabling for attackers to all of your systems? Open-sourcing your blobs will reduce this attack vector and make your products more trustworthy, and reduce the potential market loss to RISC-V and OpenPOWER, which by contrast to Intel/AMD have blob-free firmware potential.  In addition to criminal use by cybercriminals, backdoors can be “legally” misused by tyrants, bigly. Hidden backdoor management processes like Intel ME should be owner-controllable, including the ability to remove/disable it. How can I use NIST 147 guidance to check the hashes of the hundreds of blobs within the FSP/AGESA packages? The are numerous supply-chain opportunities for firmware attackers to subvert these blobs, at the IHV, OEM, ODM, IBV, some of which also have source access to these packages and modify them (for example Purism modifies FSP for their laptops, but they can’t publish their code, due to Intel NDA).

New Rules on Data Privacy for Non-US Citizens”
“- build firewalls everywhere, if possible based on non-Intel, non-AMD too, hardware platforms or at least supporting old, non-Intel ME and non-UEFI, firmware;”




~ hucktech ~

Giri Mudusuru and Vincent Zimmer of Intel gave a presentation with an overview of Intel FSP 2.0:

~ hucktech ~

Vincent Zimmer of Intel UEFI has posted TWO blog posts, to catch up to.

In the first, he point out some newly-released Intel FSP 2.0 documents:

In the second, he talks about UEFI history, focused on the 2 editions of the Beyond BIOS book (and the recent UEFI reference book in comic book pop culture).


PS: Intel Press, the web pages (including errata) for the Beyond BIOS 2nd Edition and UEFI Shell books are broken. It sucks to have an $80 book with a broken web site. Nothing personal, it seems most tech book publishers are terrible at persistant web sites and ‘cool URIs’. 😦

~ hucktech ~

Vincent has a new blog post on Intel FSP (Firmware Support Package), discussing the phases of firmware init, and how FSP works with both coreboot and UEFI.

~ hucktech ~

~ hucktech ~

First, Vincent replied to my last FSP post with an URL to another FSP-related spec, the Boot Setting File (BSF) spec, see the comments here:

Second, Vincent has two posts of his own on FSP, I may’ve blogged about one, but I believe the other one is new, there’s a lot of new FSP links to start learning…:


~ hucktech ~

Jiewen Yao of Intel submitted a 19-part patch to the UEFI Forum’s EDK2 project today, adding Intel FSP 2.0 support.

(The comments for the patch are also the first time I’ve seen a pointer to the 2.0 FSP spec. Strangely, at the moment is down for me, though the rest of the intarwebs appears to be up, so I cannot verify the FSP PDF URL…)

This series of patch is to support FSP2.0 specification at

Some major updates include:
1) One FSP binary is separated to multiple components:
FSP-T, FSP-M, FSP-S, and optional FSP-O.
Each component has its own configuration data region.
2) All FSP-APIs use same UPD format – FSP_UPD_HEADER.
3) Add EnumInitPhaseEndOfFirmware notifyphase.
4) FSP1.1/FSP1.0 compatibility is NOT maintained.

The new Intel platform will follow FSP2.0.
The old platform can either use an old EDK branch, or move FSP1.1 support to platform directory.

We also add rename Fsp* to FspWrapper* in IntelFspWrapperPkg, to indicate that it is for FspWrapper only.

  IntelFspPkg: Update FSP header file to follow FSP2.0 spec.
  IntelFspPkg: Update FSP private header file used by FSP2.0 implementation.
  IntelFspPkg-FspCommonLib: Update FSP common lib for FSP2.0.
  IntelFspPkg/FspPlatformLib: Update FSP platform lib for FSP2.0.
  IntelFspPkg/FspSecPlatformLib: Update FSP SecPlatform lib for FSP2.0.
  IntelFspPkg/FspSecCore: Update FSP SecCore for FSP2.0.
  IntelFspPkg/FspNotifyPhase: Separate FSP NotifyPhase from DxeIpl to new module.
  IntelFspPkg: Update DEC/DSC for FSP2.0.
  IntelFspPkg/Tool: Update FSP tool for FSP2.0.
  IntelFspWrapperPkg/Ppi: Update FspInitDone to FspSiliconInitDone.
  IntelFspWrapperPkg/FspWrapperApiLib: Update FspApiLib to FspWrapperApiLib.
  IntelFspWrapperPkg/FspWrapperApiTestLib: Add ApiTestLib as hook.
  IntelFspWrapperPkg/FspWrapperHobProcessLib: Update FspHobProcessLib to FspWrapperHobProcessLib.
  IntelFspWrapperPkg/FspWrapperPlatformLib: Update FspPlatformInfoLib to FspWrapperPlatformLib.
  IntelFspWrapperPkg/FspWrapperPlatformSecLib: Align PlatformSecLib defined in UefiCpuPkg.
  IntelFspWrapperPkg/FspWrapperSecCore: Remove FspWrapperSecCore.
  IntelFspWrapperPkg/FspInit: Split FspInitPei to FspmWrapperPeim and FspsWrapperPeim.
  IntelFspWrapperPkg/FspWrapperNotifyDxe: Update FspNotifyDxe to FspWrapperNotifyDxe.
  IntelFspWrapperPkg: Update DEC/DSC for FSP2.0.

For more info, see the full patch sent to the EDK2-devel list:

~ hucktech ~

Vincent Zimmer of Intel has a new blog post, on UEFI’s EDK-II and Intel FSP (Firmware Support Package), and how the FSP works with the EDK-II. Good background, with lots of links.


For more information on UEFI and FSP, also read the APress book, which Vincent is one of the authors:

~ hucktech ~

~ hucktech ~

According to this tweet, Purism got their Librem13 laptop funded. Congratulations!

Looking at the above ‘thread’, it mentions two other items of Purism news.

It sounds like that after Notebooks, they’re going to target Tablets, then Smartphones.

“First privacy respecting Librem notebooks. Next: Tablets. And then: Smartphone.”

Also, it looks like they’ll have some more news on their firmware efforts, specifically related to their efforts fighting the Intel Management Engine (ME):

“we have big news soon on freeing the ME. All firmware updates will be provided”

The already have semi-regular posts on their blog by their firmware developer, with some more news that I’ve not covered. I’m not sure what the second sentence above means. Other OEMs currently provide firmware updates to ME already. Providing full source updates would be impressive, but I doubt they meant that.

Purism gets a bit of criticism from some people because their marketing department claims that their BIOS is “almost free”, but they’re using a modern Intel system, which has many blobs and out-of-band activities. Other documentation from Purism clarifies that the “BIOS is not yet free”. Use of FSP is not a 100% requirement for modern Intel systems, it isn’t clear what the mainstream BIOS vendors are using it or alternate code. One recent BIOS vendor, I forget their name, they’re based in Sweden, released a BIOS solution for the Intel Minnowboard, which was not based on FSP. I presume, but am not sure, that anyone who does a FSP alternative codebase would still need some NDA for some specifications from Intel.

The Purism web site says:

While the BIOS is not yet free, the Librem will be the first laptop ever manufactured to ship a modern Intel CPU fused to run unsigned BIOS code, allowing for a future where free software can replace the proprietary, digitally signed BIOS binaries. This marks one of the largest hurdles to a BIOS that runs 100% free software and firmware. Recognizing the importance of this critical step toward consumer freedom, Dr. Richard M. Stallman, president of the Free Software Foundation (FSF), states:

    “Getting rid of the signature checking is an important step. While it doesn’t give us free code for the firmware, it means that users will really have control of the firmware once we get free code for it.” – Dr. Richard M. Stallman

There are also hardware components, like the HD or SSD, that are flashable, and therefore upgradeable, but that currently run firmware that is not yet freed. We are working to get freed versions of this firmware! Being the first manufacturer to care about privacy, security, and freedom, we are pushing this message upstream.

Bluntly, I’m not I understand or agree with RMS’s above statements, unclear of the context. Offhand, it seems to me that RMS isn’t considering security at all, only personal freedoms. I want both, and I don’t see why I need to chose just one. I want code to be checked, but I want to be able to control what is run. I get a little worried about some privacy enthusiasts, they sometimes only focus on technology choices that give them personal freedom, and completely ignore the use case of an attacker, who doesn’t care if the binaries were backed by open source or not.

[I want a box with a kill switch, like Purism has. And two-factor authentication required to boot firmware, locally or remotely. And a Developer Mode, like Google ChromeBook Pixel has, to override BIOS and let me do what I want. I want a metal enclosure that covers all ports (Thunderbolt, etc.) when closed, and I want a quality lock integrated into system, to deter Evil Maid from accessing ports or developer mode firmware override. I expect a good key won’t be viable, TSA checkpoints will want the ability to Evil Maid people and a good lock may slow them down.]

This quote from Joanna of Invisible Things Lab summarizes my trust of Purism exactly:

“I agree there are redflags in the @Puri_sm marketing lang. There are also positives, such as @ioerror being on board.”

Purism has a tough job trying to remove blobs from firmware, make system flexible enough for users to install new boot-time software, yet prevent attackers from attacking system, while removing protections that Intel has been adding to deter attackers. With some AMD systems, they may have less firmware to worry about blobs, but will have entirely new silicon attacks, and unlike Intel, ARM doesn’t provide any firmware vulnerability assessment tools. I’m unclear about AMD64 firmware and their AGESA, which is somewhat similar to Intel’s FSP; unclear about blob-removable potential by Purism. Also, AMD, like ARM systems, doesn’t have CHIPSEC or similar tools. Overly slick marketing aside, they’re the only OEM that’s trying to solve this problem — arguably the 2nd, after Bunnie, perhaps — which is nice to see.

It’ll be interesting to see what ISA they choose for their tablet and smartphone devices!

~ hucktech ~

Purism mentioned in a Tweet that they have 3 developers working on Intel Management Engine:

They have one document, from the summer, talking about how they’re trying to free the BIOS:

And another more recently-updated status page:

Purism offers the first high-end privacy and freedom-respecting laptops by manufacturing the motherboard and sourcing daughter cards, where all chips are designed to run free software. Purism laptops are completely free from the bootloader through the kernel (with no mystery code, binary blobs, or firmware blobs), including the operating system and all software. We have yet to free the Intel FSP binary and ME binary from within the coreboot BIOS to move us toward FSF RYF endorsement. We are working diligently to free the BIOS, but our goal is to go further than that: Purism also intends to free the firmware within HDDs and SSDs.

I’m still unclear how this will result. I’m of two minds on this: I love the idea of having a system I can trust, so am happy to see projects like Novena and Purism. On the other hand, Purism is fighting Intel’s security mechanisms, and I’m a little concerned the result will remove some Intel defensive technology that makes the system more easily attackable.

Their current model has a kill switch, which is a nice feature. [I’d also like a case that closes access to the ports when closed, and has a LOCK, with a good quality lock, that can’t be easily picked. That’d be an issue for TSA checkpoints, though.] I might also consider getting ride of Suspend/Resume, a lot of attacks happen there, and systems are fast enough these days to live without this feature.

I wish other OEMs would compete with Purism, it would be nice to have more options than a handful of ancient refurbished Thinkpads and a handful of remaining Novenas. The current Purism model is nearly done with funding, only a few days left:


~ hucktech ~

Purism is getting some slack about it’s firmware:

The first one had a stock UEFI BIOS, the second one will apparently have a coreboot BIOS with a Purism-customized FSP.
It’s not too hard to fork a new Debian OS (PureOS), there’re many to emulate. But being a micro-sized OEM means you have to deal with COTS hardware, which have blobs.

You can’t build a modern computer w/o using it’s hardware. The firmware enables this. Open source projects like Tianocore or coreboot don’t have all the necessary firmware to enable this hardware. On Intel systems, they need the Intel Firmware Support Package (FSP), all the “blobs” needed to enable the hardware. OEMs and IBVs take Intel’s FSP blobs and combine them with the tianocore UEFI code or the coreboot code, and build a firmware image for their system. Some IBVs create their own firmware from spec, w/o FSP, but that is going to take a lot of work, and the NDA’ed material probably means no open source version.

Purism apparently is a licensee of the Intel FSP source code, so they can edit the FSP source and recompile them. I presume this means Purism is under NDA with Intel, and can’t give some details of what they’re doing.

There will always be blobs in current Intel systems. Purism may reduce the number of FSP blobs, but can’t eliminate them. Perhaps Purism should focus on AMD systems, if ASEGA(sp) is open source? Perhaps Purism should focus on ARM systems, where — if sufficiently funded, they could build a chip with just the parts they want; still there are ARM Ltd NDAs. I don’t think Purism — or any similar Linux OEM — will be able to create anything useful until RISV-V is an alternative to the mainstream chips, in a few years. 😦

I  hope Purism checks CHIPSEC results before they ship their product. 🙂
I wish Intel would open source FSP. I presume that can’t be done due to NDA issues. I wonder if the open source community would sponsor an FSP alternative, if they could accomplish it w/o the NDA’ed data?

~ hucktech ~

Sage Engineering maintains a Coreboot-based, SeaBIOS payload-based firmware for the Intel MinnowBoard MAX.

Today, they’ve announced an updated release. This update allows for flashing the boot image without a hardware device.

The binary SageBIOS boot ROM image, which is flashed on the development board’s SPI Flash device, is based on the Intel Firmware Support Package (Intel FSP) and coreboot open source initialization. The SageBIOS OSP replaces UEFI firmware that comes installed on both versions of MinnowBoard MAX and will support booting a greater variety of operating systems, including FreeBSD and a variety of RTOS, as well as legacy operating systems such as older versions of Microsoft Windows and even DOS. The SageBIOS OSP will support all the operating systems supported by the native UEFI firmware, such as Windows and Linux. In addition, the SageBIOS OSP will boot both 32-bit and 64-bit operating systems with a single boot image.

The download of the “demo ROM” is free, but email registration is required.
More information:

~ hucktech ~

Embedded Firmware Solutions: Development Best Practices for the Internet of Things
APress Media
ISBN 978-4842-0071-1
February 2015
Jiming Sun, Marc Jones, Stefan Reinauer, Vincent Zimmer

[I recently finished reading this book. Sadly, I didn’t know about it until the other day, after my LinuxFestNorthWest talk on firmware security tools, someone from Sage pointed out that I omitted this from my More Information slides.]

If you care about firmware development — or just understanding current firmware architecture — you should have this book. It is the only current book with information about modern firmware in use today. The authors are all experienced and well-known firmware developers, including members of the Coreboot and UEFI teams, and there is also an impressive list of tech reviewers. There are 4 areas that this book focuses on:
* Intel Firmware Support Package (FSP), and it’s use in Coreboot and UEFI.
* UEFI and it’s dev platform.
* Coreboot and Chrome use of it.
* Intel Quark and UEFI firmware.

Intel Press has a handful of other UEFI books, but they are years old, this book is only a few months old, and has fresher details on UEFI. I don’t know of any other book with this kind of information on Coreboot, or on Intel FSP. There are a variety of books on Intel’s Minnowboard and Quark/Galileo IoT hardware: most of those books talk about how to write user-level apps, this is the only book that talks about updating the firmware of Intel IoT devices.

I’m looking forward to a second edition in a year or so, once tech changes enough.


Fsp intel

Firmware Support Package¶

Intel(R) Firmware Support Package (Intel(R) FSP) provides key programming information for initializing Intel(R) silicon and can be easily integrated into a boot loader of the developer’s choice. In essence, SBL is a minimal boot loader that consumes FSP as a binary package. FSP is widely used in many open source or commercial boot solutions on newer Intel silicons.

SBL supports FSP Specification v2.x

FSP provides many configuration options called User Product Data (UPD). See FSP UPD header files ().

FSP UPD is exposed to SBL configuration data interface so FSP can be configured directly using Configuration Editor or at SBL runtime.


SBL includes FSP interfacing infrastructure including locating and loading FSP binary, configuring FSP UPDs and calling FSP APIs.

This infrastructure is implemented in SBL core code to allow ease of porting to a new silicon.

The latest FSP release can be downloaded from GitHub:

For more information on FSP, please visit

OCPREG19 - Intel Firmware Support Package (FSP) + EDK II for Cloud

Intel® Firmware Support Package (Intel® FSP)

“Simple can be harder than complex: you have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

—Steve Jobs

Over the years, Intel has made several firmware products to support the embedded industry; most of them are either BIOS, UEFI Firmware, or something with the flavor of these two.

Intel enables its customers to design products around its chips by (like every other silicon vendor) making a Customer Reference Board (CRB) to showcase its new chips and its features. Intel, like other silicon vendors, expects customers to either copy or leverage what Intel has done with hardware, firmware, and software on the board, so that their designs can quickly go to the market for sale.

After three decades of perfecting the PC ecosystem and supply chain, the PC system development process for planning and designing chip and board features has become extremely efficient. The efficiency covers every link from top to bottom in terms of parts selection, vendor roadmap, software development, technology interception, distribution channels, marketing practices, to final sales online or in the brick-and-mortar shops. Everything is done in a well-tuned rhythm, and very few companies would miss a beat or have a hiccup in the process.

The efficiency of the PC industry can be a blessing as well as a curse. Due to the maturity of the ecosystem, the selection-choices of hardware components, software, and peripherals are gravitating toward a standard set of choices. These choices become more and more limited, and products are becoming more and more homogeneous even though the number of vendors is increasing. At the same time, the hardware, firmware, and software interfaces and architectures are also gravitating toward a few comprehensive standards, such as Wi-Fi, PCI, ACPI, UEFI, USB, Display Port, HDMI, Bluetooth, and so forth. Innovation and breakthroughs can still happen in these confined areas, but it is harder and harder for innovators to stand out in the crowd. Consumers may have a preference on brands, but there is hardly any reason to be loyal to a brand. The “cool” factor of Apple Mac products is one of the few remaining examples of strong product differentiation in an increasingly homogenized market.

Compared to the PC industry, the embedded market and the emerging IoT industry are more vibrant and versatile. They are not as mature as the PC industry, and are not as well-regulated by standards and specifications. However, the embedded market does not live in chaos. Each vertical segment of the embedded market still has its own regulations, standards, supply chain, and practices; they are just not as organized or homogeneous as the PC industry.

Therefore, trying to provide a horizontal solution across all segments and verticals is harder to achieve in the embedded market. Since the embedded market is about customization and diversification, and the life cycle of the devices is typically longer than a typical PC device, solutions for the industry need to be tailored to the needs of the designs for the vertical segments instead of the other way around.

This was the challenge that Intel was facing with firmware enablement strategies before Intel FSP was introduced. Since not all embedded market customers are leveraging PC architecture, they struggled with the firmware choices—or the lack of choices.

In 2010, Intel produced the Intel Boot Loader Development Kit (BLDK) to help developers customize an existing CRB and its BIOS. Intel BLDK was a good idea, but fell short of expectations, because even though it provided most of the source code for customers to customize, it was not very useful when customers wanted to alter their designs or use a completely different firmware stack for their boards.

After a few years of gathering feedback and prototyping, Intel announced the Intel Firmware Support Package in October 2012. It was not an answer to all the challenges, but it was a simple solution to support versatile needs of designs and choices. Intel FSP contains only the silicon initialization code that can be integrated into any firmware stack. Once integrated, developers can design the rest of the firmware stack for value-added features.

If you are confused by BIOS, BLDK, and FSP, let’s compare these three offerings using automobile metaphors. The reference BIOS on a CRB is like an 8-cylinder, fully loaded SUV: powerful, impressive, and with all the features you can dream of. BLDK, on the other hand, is like a customizable VW Beetle with a lot of accessories and parts to alter the design and to customize its look. But, the Beetle is still a car in a fixed frame. If you plan to build a different kind of car, whether it is a race car, a sand buggy, or a military tank, it is not impossible, but it is hard to pick the parts you need from an SUV or a Beetle to build the car you want.

Using the same analogy, metaphorically, Intel FSP is like an engine, which is needed by every car. Obviously, in reality, cars of different models use different engines, but in the firmware case, the engine for initializing a silicon is identical whether you are building a server, a desktop, a laptop, a set-top box, or a wearable device. If a silicon vendor does it right, it is very possible to share the same silicon code for all market segments.

Intel FSP is the engine that provides the silicon initialization code for Intel chips. Each Intel silicon and its companion chip will have their own Intel FSP. There is no super FSP that encapsulates multiple silicon families, simply because it is not necessary. The goal is to keep FSP small enough that it can be utilized in the most compact and size-constrained environment. In Intel’s case, the programming information is mostly documented in a BIOS Writer’s Guide (BWG) or UEFI Firmware Writer’s Guide, which are confidential documents that only privileged customers can obtain (after signing a non-disclosure agreement with Intel). If you are a developer who does not want to understand or debug Intel’s code, and you have no interest in reading hundreds of pages of a BWG, you can simply take the Intel FSP, integrate it into your firmware stack, and let the magic of Intel FSP work for you.

Once executed, Intel FSP initializes the memory, programs the system address space, and initializes the input/output (I/O) controllers of the microprocessor and its companion chip. You will be able to run the next stage firmware stack to do whatever you like to do from this point on. Obviously, you still have a lot of work to do to initialize the rest of the platform, but the good news is that the rest of the system depends less on silicon vendors, but more on industry standards, publicly available specifications, and your own design recipes. There is even reference code and sample code to help you finish the features that are commonly available in a system.

The Intel FSP Philosophy

As discussed in Chapter 1, Intel believes that there are a lot of smart firmware engineers out there in the embedded industry. Intel knows that some of them are looking for turnkey solutions, with which they don’t have to do anything besides turning knobs on a GUI-based tool. Intel also knows that some of them are looking for completely open source solutions that bring total freedom in creating customer-specific firmware stacks. Besides the 100% GUI-tool users and 100% open source users, there are many engineers who need to work with hybrid solutions because their code bases are either proprietary or have a lot of customized features to be added beyond standard features offered by the reference designs.

No doubt in people’s mind, silicon vendors know their chips inside out because they design them; therefore, providing Intel FSP to encapsulate the chip initialization code that Intel knows the best makes sense. Developers who choose to leverage Intel FSP will have a better starting point with a new Intel chip than relying on a self-learning process from reading programming manuals.

Intel FSP does not have features that are typically available in reference BIOS from Intel (such as secure boot, PCI Bus enumeration, power management, etc.). The reason why these features are not included is because Intel does not want to burden everyone with code they may not need. Intel wants to keep the FSP footprint as small as possible. For this reason, a developer may feel lost if he or she has been depending upon Intel to deliver the additional features in the reference BIOS, but the good news is that these features have publicly available specifications, standards, and even sample code to follow or copy. Obviously, the bad news is that the developer will have to somehow implement these features in the firmware stack if they need the features. If the developer is implementing them from scratch, it could be hard, but this is the price the developer has to pay when switching away from the reference BIOS model. Whichever way the developer chooses to acquire the features (do it himself/herself or pay someone to do it), the developer has a better starting point with Intel FSP than with a reference BIOS because of the additional freedom provided by FSP. Hopefully, as the ecosystem for supporting Intel FSP grows, there will be more and more ISVs involved to provide firmware solutions different than BIOS. Additionally, once the code for these peripheral features is done, most of the code is reusable and can last for a long time. For example, PCI bus enumeration code, even though is complicated, does not change between generations of chips. Most of the power management and secure boot features do not need an overhaul once the foundation is built.

It is really all about additional freedom provided by Intel FSP; it is not an answer to all the firmware needs associated with Intel Architecture. If you have a design that heavily leverages Intel CRB and standard features, you are probably better off with a standard BIOS solution; it does not likely make sense to start a new firmware stack to replace your existing BIOS. However, if you are starting from scratch, or if your design is significantly different from a traditional PC, you might want to consider the options involving Intel FSP. Intel FSP addresses a niche market where the developer doesn’t use PC architecture or when the developer does not plan to use BIOS. Therefore, don’t jump onto the Intel FSP bandwagon until you know your ultimate goal.

What Is in Intel FSP?

Later in this book, we will show you where to download Intel FSP. At the FSP download site on the Web, you will find self-extracting executable packages (in .exe format for Windows or in .tgz files if you are exploring Linux options).

After you download the file in .exeor .tgzformat for your favorite OS, you can extract the contents from the file by executing the .exefile or by using your favorite Linux unpacking utility. And, you can find a couple of items in your expanded folder:
  • A subfolder called Documentation, which contains an integration guide and release notes.

  • A subfolder called FSP, which contains an FSP binary file (with an .fd file extension), a Boot Setting File (BSF, with a .bsf file extension), and two subfolders with sample header files and source code.

  • A subfolder called Graphics. This folder is optional. When it exists, it contains graphics components that you might need, such as a VGA BIOS image.

  • A subfolder called Microcode, which contains the microcode patches available at the time of the release of FSP. The microcode patches can be updated independently of FSP, as well as when you must download the latest ones to make sure that they match with the microprocessor used on your board.

There are additional files, such as the licensing agreement, a ReadMe (describing the contents of FSP), and so forth. These are not important to the discussion of this book. There is an important tool available—the Binary Configuration Tool—on the same download page, but it is a separate download file. We will discuss this tool later in the book.

We will explain each item in more detail, but a hard-core open source software engineer may already have a question about why Intel ships only a binary file, not the source code. Currently, there are a couple of reasons. Intel may change the design and deliverables in the future.
  • Intel FSP still has some IP-protected code inside; therefore, until this code can be properly protected or cleared for protection, Intel does not have a near-term plan to release it in an open source repository. However, you may have discovered that Intel has already released 100% of the source code for the Intel® Quark™ SoC X1000 Series; therefore, Intel is gradually removing the barrier of IP protection. It may take a few years to see Intel completely open all the source code at this level.

  • Intel wants to eventually move basic silicon initialization code inside the silicon one day; therefore, a binary file is isolated enough that it can pave the road for future silicon inclusion. Many silicon vendors have already included a Boot ROM inside their SoC. Since the code inside the Boot ROM is for the purpose of initializing the SoC, it should not be a concern if silicon initialization code is isolated and protected somehow. Intel FSP does offer a way to customize its internal configuration with the BCT tool; thus it further eliminates the need to change what is inside Intel FSP.

  • Many vendors release binary files to abstract silicon and hardware code. This practice has been in existence for many decades; for example, the Option ROM on plug-in cards contains a binary code that initializes the hardware on the card. VGA BIOS still exists in the form of Option ROM, even though there is no longer a plug-in card. This abstraction has been working out nicely in the PC industry because it provides a simple interface and isolation so that the cards can be sold separately from the motherboards.

  • Being a binary, it can be interfaced with a firmware stack without being dynamically or statically linked into the host firmware. In this way, it can help eliminate the concerns of open source codebase using General Public License (GPL) when integrating. Because this book does not provide legal advice and there are a few different versions of GPL, you need to double-check with your legal department to decide what is OK and what is not OK.

That said, Intel does realize that many hardware and firmware engineers need source code to bring up or power-on a brand-new board in order to debug a problem when the board is not functioning after the power is applied. Intel offers source code to customers under a special software license agreement (SLA). It is beyond the scope of this book to discuss how to obtain source code from Intel; therefore, you should contact Intel’s sales or field engineers to ask for details.

As previously discussed, even though Intel FSP is a binary file, it needs a provision to customize its internal states and features; therefore, it has reserved a data region inside the binary for customization. The data area also contains a couple of platform-specific parameters that Intel FSP would otherwise have no knowledge about, or would initialize the board with default values. The Boot Setting File (BSF) plays an important role for this purpose. It is basically a text file that contains firmware internal settings associated with the board; for example, the SMBUS (System Management Bus) address of a SPD (Serial Presence Detect) ROM on a DIMM (Dual Inline Memory Module) is one of the data in the BSF.

$gPlatformFspPkgTokenSpaceGuid_PcdMrcInitSPDAddr1  1 byte $_DEFAULT_ = 0xA0

$gPlatformFspPkgTokenSpaceGuid_PcdMrcInitSPDAddr2  1 byte $_DEFAULT_ = 0xA2

A sample BSF can be found in Appendix A.

The data in BSF is represented in a GUI-based tool, which allows developers to visualize the meaning of each component in BSF. With the GUI and BSF, it is collectively called a Binary Configuration Tool (BCT). There are three versions of BCT: one runs under Windows, one runs under Linux, and the third is a command-line option under Linux. Figure 3-1shows a BCT tool for Windows.

The last part of Intel FSP is the header files and sample code. These files are for developers to include in their firmware stack to develop the interface code with Intel FSP; therefore, developers can include these files in the firmware stack or re-create the files based on these files. For example, fsp.h under the include directory, looks like this:

#include <stdint.h>

#include "fsptypes.h"

#include "fspfv.h"

#include "fspffs.h"

#include "fsphob.h"

#include "fspapi.h"

#include "fspplatform.h"

#include "fspinfoheader.h"

#include "fspvpd.h"


{ 0x69a79759, 0x1373, 0x4367, { 0xa6, 0xc4, 0xc7, 0xf5, 0x9e, 0xfd, 0x98, 0x6e } }


{ 0x721acf02, 0x4d77, 0x4c2a, { 0xb3, 0xdc, 0x27, 0xb, 0x7b, 0xa9, 0xe4, 0xb0 } }


{ 0xd038747c, 0xd00c, 0x4980, { 0xb3, 0x19, 0x49, 0x01, 0x99, 0xa4, 0x7d, 0x55 } }


{ 0x9c7c3aa7, 0x5332, 0x4917, { 0x82, 0xb9, 0x56, 0xa5, 0xf3, 0xe6, 0x2a, 0x07 } }


{ 0xbbcff46c, 0xc8d3, 0x4113, { 0x89, 0x85, 0xb9, 0xd4, 0xf3, 0xb3, 0xf6, 0x4e } }


// 0x21 - 0xf..f are reserved.



#define BOOT_ON_S3_RESUME                  0x11

Intel FSP Binary Format

Since Intel FSP is a binary file, it needs to be organized in a standard way that the data inside can be easily found and retrieved. What are things you need to find inside the Intel FSP? The two most important interface points are the application programming interface (API) and the configuration region.

Intel FSP chose to follow UEFI’s Firmware Volume (FV) layout format. Don’t be alarmed if you are not familiar with Platform Initialization (PI), UEFI, or FV. FV is just a layout format that dictates how the data inside is organized. If you want to learn more about FV, please find more information in the Appendix or look it up on the UEFI web site. The diagram in Figure 3-2shows the FV layout format.

Figure 3-2 shows an FV where Intel FSP resides, but Intel FSP can be split into multiple FVs due to the needs of secure boot and other features. For example, there can be one FV that contains part of the code that needs to be certified and signed, and there can be another part of the code that is customizable for developers; therefore, the latter can exist in a different FV so that the second part can be certified or signed separately from the first one. The other case that warrants the separation of the FVs is where one part can be masked after production and the other part can be updated in the field. Intel FSP provides the flexibility to be used in different ways.

A few key ingredients are in the Intel FSP binary:
  • FSP information header region for configuration data

  • Offsets pointing to API entry points and the configuration data region

  • The APIs themselves

The FSP information header provides a basic FSP image signature, a base, size information, and the offsets pointing to the API entry points and the configuration region.

The following shows the FSP information header:

typedef struct  {

UINT32  Signature;      // Off 0x94

UINT32  HeaderLength;

UINT8   Reserved1[3];

UINT8   HeaderRevision;

UINT32  ImageRevision;

CHAR8   ImageId[8];      // Off 0xA4

UINT32  ImageSize;

UINT32  ImageBase;

UINT32  ImageAttribute;  // Off 0xB4

UINT32  CfgRegionOffset;

UINT32  CfgRegionSize;

UINT32  ApiEntryNum;

UINT32  NemInitEntry;    // Off 0xC4

UINT32  FspInitEntry;

UINT32  NotifyPhaseEntry;

UINT32  Reserved2;


As you can see, offset numbers are provided here in the sample header structure: 148 bytes (0x94 is the hexadecimal number) from the top of the file is the starting point of the FSP_INFO_HEADER; 164 bytes (0xA4 is the hexadecimal number) from the top is the identification string of the FSP binary; 180 bytes (0xB4 is the hexadecimal number) from the top is the location that contains the offset to the configuration region; and 196 bytes (0xC4 is the hexadecimal number) from the top is where the three pointers to the three APIs are located. Later on, we will talk about why the offset values are important to know. These numbers may change based on the platform. Please check the documentation that comes with each Intel FSP release—particularly the Intel FSP Integration Guide—to obtain the latest offset values.

The configuration data region stores platform-specific information; some parameters are customizable during runtime by the firmware stack, and some are fixed once configured—thus static once they are manipulated by the BCT. Details will be discussed later. The pointers to the APIs and the APIs themselves are part of the FV, and they will be discussed in later sections as well.

Sample Boot Flow

The boot process starts from the Reset Vector after power is applied. In modern computers, many things have already happened before the first fetch of the opcode located at the Reset Vector of the CPU, such as microcontroller firmware and management engine firmware. In a secure boot implementation, the management engine in the system can hold the reset signal to the CPU until it deems that the firmware running the CPU is trustworthy and safe to run.

As shown in Figure 3-3, once the firmware stack is allowed to execute, the CPU will fetch its first instruction from the Reset Vector, which is located at top of the 4-gigabyte physical memory space, minus 16 bytes (or FFFFFFF0, in hexadecimal value). This address is hardwired in the Intel microprocessors during reset, and the location should fall inside the Flash ROM if you have designed your board correctly. In the design of future microprocessors, this physical address of FFFFFFF0 may change to allow more flexibility.

At this point, the firmware stack inside the Flash ROM will begin to execute; the first thing it needs to do is quickly exit the “reset mode” and enter a more permanent 32-bit Protected Flat Mode. This “32-bit Protected Flat Mode” is a loaded term, but it is basically a mode that allows you to access 4 gigabytes of “flat” physical address space with the existing segment register and selector settings. After entering this 32-bit Protected Flat mode, the firmware stack has a powerful execution environment to access code and memory mapped I/O anywhere within the 4-gigabyte range.

However, even with the power to access the 4-gigabyte address range, you still cannot do too much without memory and I/O devices; therefore, the firmware stack should be initializing the memory controller and the companion I/O controllers as soon as possible so that it can actually run its code inside the faster DRAM (instead of the slow Flash ROM) and access I/O devices in the system. This is where you will run into the first headache in dealing with a new silicon from a silicon vendor. In Intel’s case, you may use Intel’s Memory Reference Code (MRC) directly if you can get one, or you can download Intel FSP that contains the MRC.

Since MRC is very complicated, we recommend you not to touch MRC. If you understand DDR (Double Data Rate) memory technology, you know that MRC contains the memory training algorithm to try to find the sweet spot of the operating speed, signal strength, and other parameters for the DRAMs in the system; whatever algorithm Intel (or any other silicon vendor) has developed inside MRC, it is robust, optimized, and validated. You should not touch the code if you don’t have a reason to do so. However, you might want to customize your design; for example, bypassing memory training when you have a soldered-down or fixed memory configuration. But this so-called “Fast Boot” path is also provided inside MRC; it is typically an option provided by the Intel FSP BCT configuration tool. You can achieve this “Fast Boot” by simply turning a bit on and off inside the tool. FSP will automatically apply the fast boot option when a valid NVS (Non-Volatile Storage) data region is provided by the firmware stack. The NVS data region contains the memory parameters that can be used repeatedly by Intel FSP.


DDR technology is quite delicate; the training algorithm exists for a reason.  The “sweet spot” of operation may change over time due to temperature, aging, and other factors in the environment; therefore, the parameters stored in the NVS may not work all the time unless careful error margins are built in, and a failover mechanism is provided when the parameters in NVS no longer work.  The memory training may need to be executed again to acquire new parameters when old parameters do not function.

As shown in Figure 3-3, Intel FSP does more than just memory initialization; you should use it rather than dealing with MRC directly. Intel FSP also loads microcode patches and initializes companion I/O controllers for you. In addition, it sets up a small amount of temporary memory using cache or SRAM before DRAM is initialized, so that you can execute code more efficiently before the system memory is fully initialized.

Therefore, once the host firmware stack transitions to the 32-bit Protected Flat Mode, it can look for the first Intel FSP entry point and jump into it. The first thing that Intel FSP does inside the first FSP API is load microcode patches, and then initialize a small region of temporary memory. Once the temporary memory is set up, Intel FSP returns control back to the host firmware stack. Why? Because the next step Intel FSP is about to do is to initialize DDR memory, where a memory training algorithm will be conducted, and it can take 100 milliseconds to 300 milliseconds to finish, depending upon the board layout, the amount of memory, and which DDR technology is used. If you have something important and urgent or devices that can be turned on early to allow the electronics to be stabilized before the OS starts (e.g., the LED backlight, HDD spin-up, etc.), you can do it before memory is initialized. Some firmware stacks take this opportunity to verify the integrity of the next stage of boot code to ensure that the code running next is secure and trust worthy.

Once pre-memory initialization work is done by the host firmware, it can once again call into the second entry point of Intel FSP. This time, Intel FSP is going to finish the memory initialization and the companion chip initialization altogether. Once this is done, upon return, the host firmware will be able to see 4 gigabytes of memory available for them to use. There are many techniques in firmware to look beyond 4 gigabytes, such as memory hoisting (moving memory above 4 gigabyte to fill the memory holes created by Memory Mapped I/O); but the best way to access memory above 4 gigabyte is to transition to 64-bit long mode, although most embedded firmware stacks don’t do that unless they are designed to boot a 64-bit OS. Some firmware stacks will remain in 32-bit mode until the last minute before booting a 64-bit OS; it is up to the firmware developer to decide when to switch to 64-bit mode if it is necessary.

At this point, Intel FSP has done its job and leaves the rest of the platform initialization work to the host firmware. The following chapters will be walking you through two firmware stacks as examples for carrying out the platform initialization work.

There is another entry point of Intel FSP that we have not talked about— NotifyPhase. NotifyPhase is an entry point for the host firmware to call back to Intel FSP after PCI bus enumeration and before booting an OS, because there are things to be adjusted, locked down, and cleaned up; as an example, the TSEG register will be locked so that no one can mess it up after booting an OS.

Once NotifyPhase returns the control to the host firmware, the firmware is ready to transition control to a payload or an interface to boot an OS.

Is this the only way to go through the boot process? Of course not; this is a typical boot process for a system based on PC architecture. For a system without PC bus or graphics, or closed without expansion, the boot process can be different or simpler, and Intel FSP can still be part of the boot process to initialize silicon features.

One thing should be very clear to you now: Intel FSP is not a firmware stack itself. It needs to be integrated into one. And, Intel FSP contains only the basic silicon initialization code; more sophisticated features need to be carried out by the host firmware stack; for example, power management, bus enumeration, ACPI, and so forth.

A rough estimation of the Intel FSP size is between 100 and 300 kilobytes, and it can finish all the tasks within 100 to 300 milliseconds. These size and performance estimations are all tied to the CPU type, and the size and performance of MRC dominate the overall estimation because it is the biggest and slowest code inside Intel FSP.

The boot flow shown in Figure 3-3 may change in the future, when new requirements for Intel FSP show up; for example, Intel FSP may provide more hooks to allow host firmware to carry out actions in between various Initialization tasks.

Locating the Entries of Intel FSP

Since Intel FSP is a binary image, the host firmware stack needs to find the image of Intel FSP soon after it starts running from the reset vector. Once Intel FSP is found, it needs to find the entry points pointing to the three APIs that we mentioned in the section about Boot Flow. There are two ways to find the pointers to these APIs.

The Hard Way to Find Intel FSP APIs: Use Data Structure

A developer can certainly follow the predefined and standard FV data structure to parse the data in an FV binary. All you have to do is trace through the data structure and look for header and data regions that contain relevant FSP data.

The first step is to find the base address of the FV where Intel FSP resides. This is where you physically put the FSP binary image. Many Intel FSP binary images are designed to exist at a physical address, such as 0xFFFF8000. A developer can customize the location by rebasing Intel FSP to a different location by running the BCT, which will be discussed later. As you read the data out of the FV and match it against the data structure of EFI_FIRMWARE_VOLUME_HEADER, defined in a standard UEFI header file for FV, you can basically follow the hierarchy of the data structure and look for the data you need.

typedef struct {

UINT8 ZeroVector[16];

EFI_GUID FileSystemGuid;

UINT64 FvLength;

UINT32 Signature;


UINT16 HeaderLength;

UINT16 Checksum;

UINT16 ExtHeaderOffset;

UINT8 Reserved[1];

UINT8 Revision;



FSP_INFORMATION_HEADER is a firmware file that is placed as the first firmware file within the FV. All firmware files have a GUID that can be used to identify the files, including the FSP header file. The FSP header firmware file GUID is defined as 912740BE-2284-4734-B971-84B027353F0C.

The host firmware stack can find the offset of the FSP header within the FSP binary by following these steps:
  1. 1.

    Use EFI_FIRMWARE_VOLUME_HEADER to parse the FSP FV header and skip the standard and extended FV header.

  2. 2.

    The EFI_FFS_FILE_HEADER with the FSP_FFS_INFORMATION_FILE_GUID is located at the 8-byte aligned offset following the FV header.

  3. 3.

    The EFI_RAW_SECTION header follows the FFS File Header.

  4. 4.

    Immediately following the EFI_RAW_SECTION header is the raw data. The format of this data is defined in the FSP_INFORMATION_HEADER structure.

The following is a sample code snippet that does the previous steps in a stackless environment. Since the code will be executed in a stackless environment, assembly code is preferred. In this example, we use the C language for easier readability.


// Validate FV signature _FVH


if (((EFI_FIRMWARE_VOLUME_HEADER *)ptr)-> Signature != 0x4856465F) {

ptr = 0;

goto NotFound;



// Add the Ext Header size to the Ext Header base to go to the

// end of FV header


ptr += ((EFI_FIRMWARE_VOLUME_HEADER *)ptr)->ExtHeaderOffset;

ptr += ((EFI_FIRMWARE_VOLUME_EXT_HEADER *)ptr)->ExtHeaderSize;


// Align the end of FV header address to 8 bytes


ptr = (UINT8 *)(((UINT32)ptr + 7) & 0xFFFFFFF8);


// Now ptr is pointing to thr FFS Header. Verify if the GUID

// matches the FSP_INFO_HEADER GUID


if ((((UINT32 *)&(((EFI_FFS_FILE_HEADER *)ptr)->Name))[0] != 0x912740BE) ||

(((UINT32 *)&(((EFI_FFS_FILE_HEADER *)ptr)->Name))[1] != 0x47342284) ||

(((UINT32 *)&(((EFI_FFS_FILE_HEADER *)ptr)->Name))[2] != 0xB08471B9) ||

(((UINT32 *)&(((EFI_FFS_FILE_HEADER *)ptr)->Name))[3] != 0x0C3F3527)) {

ptr = 0;

goto NotFound;



// Add the FFS Header size to the base to find the Raw section

// Header


ptr += sizeof(EFI_FFS_FILE_HEADER);

if (((EFI_RAW_SECTION *)ptr)->Type != EFI_SECTION_RAW) {

ptr = 0;

goto NotFound;



// Add the Raw Header size to the base to find the FSP INFO

// Header


ptr += sizeof(EFI_RAW_SECTION);


__asm__ __volatile__ ("ret");

All of these data structures are provided in FSP header files in the package; therefore, you can develop a generic solution to locate FSP APIs.

The Easy Way to Find FSP APIs: Use Hard-Coded Constants

If you are more concerned more about saving a few bytes here and there, or a few nanoseconds or microseconds here and there, and you are not worrying about changing code for every platform you build, you may consider using hard-coded constants to find the FSP APIs.

For example, the offset constant OFFSET_OF(FSP_INFO_HEADER) is defined as 0x94 for BayTrail platforms. It is the offset from the beginning of the FSP binary. The next important offset constant is OFFSET_OF(FSP_BASE), which is defined as 0x1C (28 bytes from the beginning of FSP_INFO_HEADER). The FSP_BASE must match the location where you put the FSP image in Flash. Then we have three pointers pointing to Intel FSP’s three APIs located at offset constants from the beginning of FSP_INFO_HEADER: 0x30, 0x34, and 0x38, respectively. They are 4 bytes apart because these offsets are 32 bits long.

Using these offset constants, you may find the following:
  • The first API (TempRAMInit) entry point at the physical location of (FSP_BASE + *(UINT32 *)(FSP_BASE + OFFSET_OF(FSP_INFO_HEADER) + 0x30))

  • The second API (FspInit) entry point at the physical location of (FSP_BASE + *(UINT32 *)(FSP_BASE + OFFSET_OF(FSP_INFO_HEADER) + 0x34))

  • The last API (NotifyPhase) entry point at the physical location of (FSP_BASE + *(UINT32 *)(FSP_BASE + OFFSET_OF(FSP_INFO_HEADER) + 0x38))

Programming Interface: The APIs of Intel FSP

Now you know how to find the three APIs inside of Intel FSP. It is time to understand what they are and how you should interface with them.


As described in the “Sample Boot Flow” section, this FSP API will load the microcode patches, enable the code cache region specified by the host firmware, and set up a temporary stack to be used until the main memory is initialized. There are a couple of input parameters for passing in: the microcode patch base address and its size, and the host firmware code region base address and its size. The microcode patch mechanism built in FSP will try to load the correct microcode patches for the silicon by matching its CPUID and the ID of the patches; if no matching one is found, the API will return an error code. This is a typical error that the developer will face when he or she is not familiar with Intel microprocessors and the microcode patching mechanism.

The other input parameters are firmware code region base and size. They are used to enable the code cache to speed up the execution of the code in Flash. Here is the data structure of the input parameters:

typedef struct {

UINT32 MicrocodeRegionBase,

UINT32 MicrocodeRegionLength,

UINT32 CodeRegionBase,

UINT32 CodeRegionLength


Since the host firmware is supposed to blindly jump into TempRamInit after finding its address, how does Intel FSP know where to return to after TempRamInit is done? A trick called “ROM-based stack” is used here. It is basically a trick to point the ESP (Stack Pointer) register to a location in ROM where a return address is stored. When the TempRamInit code is done, all it has to do is execute a “ret” instruction, which will pop the return address from the location pointed by the ESP register, and the Instruction Pointer will point to the next instruction that the host firmware specifies. Besides the return address, the input parameters will also be stored there so that TempRamInit can simply look at the “stack” and retrieve the input parameter as if it is running a subroutine written in the C language.

The following is an example of what the ROM-based stack looks like. ESP will be loaded with the address tempRamInitStack, where it contains the return address as temp_RamInit_done, and also the pointer to the input parameters—tempRamInitParams. The microcode patches–based address and length are passed in here.


.long _ucode_base # Microcode base address

.long _ucode_size # Microcode size

.long 0xfff00000 # Code Region Base

.long 0x00100000 # Code Region Length


.long temp_RamInit_done # return address

.long tempRamInitParams # pointer to parameters

This API should be called only once after the system comes out of the reset, and it must be called before any other FSP APIs. The system needs to go through a reset cycle before this API can be called again; otherwise, unexpected results may occur. The sample implementation of find_fsp_info_header and tempRamInit are listed next as an example:

# prepare to find FSP header

lea findFspHeaderStack, %esp

lea _fsp_rom_start, %eax

jmp find_fsp_info_header


mov %eax, %ebp # save fsp header address in ebp

mov 0x30(%ebp), %eax # TempRamInit offset in the header

add 0x1c(%ebp), %eax # add FSP base to get the API address

lea tempRamInitStack, %esp # initialize to a rom stack


# call FSP PEI to setup temporary Stack


jmp *%eax


addl $4, %esp

cmp $0, %eax

jz continue


# TempRamInit failed, dead loop


jmp .



# Save FSP_INFO_HEADER in ebx


mov %ebp, %ebx


# setup bootloader stack

# ecx: stack base

# edx: stack top


lea -4(%edx), %esp


# call C based early_init to initialize meomry and chipset.

# pass the FSP INFO Header address as a paramater


push %ebx

call early_init


# should never return here


jmp .

.align 4


.long findFspHeaderDone


.long _ucode_base # Microcode base address

.long _ucode_size # Microcode size

.long 0xfff00000  # Code Region Base

.long 0x00100000  # Code Region Length


.long temp_RamInit_done # return address

.long tempRamInitParams # pointer to parameters

If this function is successful, ECX and EDX registers will be returned to point to a temporary but writeable memory range available to the host firmware with FSP_SUCCESS stored in register EAX. Register ECX points to the start of this temporary memory range and EDX points to the end of the range. At this point, the host firmware is free to use the whole range described. Typically, the host firmware can reload the ESP register to point to the end of this returned range so that it can be used as a standard stack now, and the C-style function call can now be used; in other words, the programming language can be switch to the C language after this API is called. Since there is only limited space, the host firmware should not try to do crazy things using this memory range. Stack is probably the only function that the host firmware should consider using until the main memory is initialized by the next API.

Developers should also be aware that this returned range is just a subregion of the whole temporary memory initialized by the TempRamInit function; Intel FSP maintains and consumes the remaining temporary memory. It is important for the host firmware not to access the temporary memory beyond the returned boundary.


As shown in the sample boot flow diagram in the previous section, once Intel FSP hands over control back to the host firmware after TempRamInit is executed, the host firmware can choose to do a few things before calling the next API—FspInitEntry. Since this upcoming API initializes the memory, the CPU, and the companion chips, it may take a few hundred milliseconds before the host firmware gains control again; therefore, the host firmware can utilize this opportunity to carry out some pre-memory initialization work; for example, turn on the LED backlight, spin up the hard drive, or turn on other hardware components that need time to stabilize their electronic and mechanical states. The host firmware can also choose to verify components for secure boot purposes before continuing.

Since FspInitEntry deals with CPU, memory controller, and companion chips, it is highly dependent on the silicon it is associated with. Therefore, even though the input parameter is consistent among all Intel FSP as a pointer to a data structure, the contents of the data structure will be defined differently by each FSP release. They will be documented in the Integration Guide. The prototype of the input parameter is as follows:






And, the data structure is shown as the following:

typedef struct {

VOID *NvsBufferPtr;

VOID *RtBufferPtr;



Within the data structure, NvsBufferPtr points to the data buffer with data that needs to be stored into and retrieved from a non-volatile storage device. In the very beginning—the first time the host firmware calls the API—this parameter is NULL, and Intel FSP will return the data in the Hand-Off Block (HOB) after this API is executed. The data can then be stored in the non-volatile storage device for later usage by the host firmware. For subsequent boots, the data can be passed in by the host firmware to the FSP to handle special cases, such as S3 resume or fast boot.

RtBufferPtr points to the data buffer used for runtime configuration. For example, the “StackTop” pointer pointing to the top of the host firmware stack after memory is available; the pointer pointing to the configuration data region that contains customized configuration settings; and the boot mode, which is the flag to tell Intel FSP to optimize its initialization flow. This S3 resume path (i.e., resume from a sleep state using existing memory contents) is used to optimize the boot speed by using the memory parameters passed in (instead of going through the memory training code). It can also be used for soldered-down memory configuration, or after the first boot when there is no change in memory configuration and when memory training parameters remain valid. There is not a “Fast Boot” flag to reflect the need to skip memory training, but FSP will look at the input parameter, NvsBufferPtr, to determine if it should skip memory training or not. If it is NULL, it will not skip, and if there is a valid pointer stored in NvsBufferPtr, it will skip the memory training code. This can save potential boot time up to 100 milliseconds.

typedef struct {

UINT32 *StackTop;

UINT32 BootMode;

VOID *UpdDataRegPtr;

UINT32 Reserved[7];


ContinuationFunc is a pointer to the “continuation function” address, where Intel FSP will jump back to after the execution of this API is done. After the FspInitEntry API completes its execution, it does not return to the host firmware from where it was called, but instead returns control to the host firmware by jumping to the continuation function. The jump is accompanied by two parameters: the Status and the Pointer of a HOB list that contains the hand-off data from Intel FSP to the host firmware.



IN VOID *HobListPtr


Why are we using an input parameter, continuation function’s address, as the return address? The reason why a simple return is not used after FspInitEntry is done in this case is because after memory is initialized, the old stack using temporary memory will be destroyed, and a new stack will be set up in its place. The transfer of contents in a stack can be done, but this is very risky due to compiler compatibility issues, and the old stack may no longer have valid contents after the transition; for example, a pointer to a local variable in the old stack will still point to the old stack. Even after migration, it is more reliable if we simply jump to an address passed in as a parameter.

Like the previous API, this API should be called only once.


This API is used by the host firmware to notify the FSP after finishing certain phases during the boot process, so that Intel FSP can take appropriate actions as needed for these phases. The actions and phases are platform dependent and will be documented with each FSP release. Examples of boot phases include “post pci enumeration” and “ready to boot.”

The FSP will lock the configuration registers to ensure system security and reliability.

#define FSPAPI __attribute__((cdecl))

typedef UINT32 FSP_STATUS;


(NOTIFY_PHASE_PARAMS *NotifyPhaseParamPtr);

typedef enum {

EnumInitPhaseAfterPciEnumeration = 0x20,

EnumInitPhaseReadyToBoot = 0x40


typedef struct {



void FspNotifyPhase (UINT32 Phase)


FSP_NOTFY_PHASE NotifyPhaseProc;



/* call FSP PEI to Notify PostPciEnumeration */

NotifyPhaseProc = (FSP_NOTFY_PHASE)(fsp_info_header->ImageBase + fsp_info_header->NotifyPhaseEntry);

NotifyPhaseParams.Phase = Phase;

Status = NotifyPhaseProc (&NotifyPhaseParams);

if (Status != 0) {

printf("FSP API NotifyPhase failed for phase %d!\n",Phase);



Intel FSP Output

As initialization progresses, a lot of system information and configuration data are collected in the process. The data needs to be passed to the host firmware so that it does not need to rediscover this data on its own. While Intel FSP is discovering the data, it builds a series of data structures called Hand-Off Blocks, or HOBs, and fills them with useful information, such as total memory size and so forth. The data structures conform to the HOB format, as described in the PI specification Volume 3: Shared Architectural Elements, which can be downloaded from under the latest specification listed on the page. HOBs are the only conduits between Intel FSP and the host firmware once Intel FSP is done with its work. Therefore, the user of the FSP binary is strongly encouraged to go through the specification mentioned earlier in order to understand the HOB design details and create a simple infrastructure to parse the HOBs, because the same infrastructure can be reused with different FSPs across different platforms.

The specification mentioned earlier describes about nine different HOBs; most of the information may not be relevant to a particular host firmware. It’s up to the host firmware to decide how to consume the information passed through the HOBs produced by the FSP. Regarding how you know which information is important and which information is not important, you need to examine the data structures and decide what is needed by the platform initialization code, and then retrieve the data from the data structures, as needed. The data structures can be different from platform to platform, and new data can be available as new features and new requirements are developed.

API Execution Status

The host firmware can check the status after each API call. The following are the statuses for TempRamInit:
  • FSP_SUCCESS: Temp RAM was initialized successfully.

  • FSP_INVALID_PARAMETER: Input parameters are invalid.

  • FSP_NOT_FOUND: No valid microcode was found in the microcode region.

  • FSP_UNSUPPORTED: The FSP calling conditions were not met.

  • FSP_DEVICE_ERROR: Temp RAM initialization failed.

The following are the statuses for FspInit:
  • FSP_SUCCESS: The FSP execution environment was initialized successfully.

  • FSP_INVALID_PARAMETER: Input parameters are invalid.

  • FSP_UNSUPPORTED: The FSP calling conditions were not met.

  • FSP_DEVICE_ERROR: FSP initialization failed.

The following are the statuses for NotifyPhase:
  • FSP_SUCCESS: The notification was handled successfully.

  • FSP_UNSUPPORTED: The notification was not called in the proper order.

  • FSP_INVALID_PARAMETER: The notification code is invalid.

Temporary Memory Data HOB

A few paragraphs ago, we talked about the temporary stack being destroyed after main memory initialization, but there could be data that interests you that is still in the stack. Intel FSP will save the subregion where the host firmware data is stored, and pass it back to the host firmware using a HOB data structure with a unique GUID, defined as follows:


{ 0xbbcff46c, 0xc8d3, 0x4113, { 0x89, 0x85, 0xb9, 0xd4, 0xf3,

0xb3, 0xf6, 0x4e } };

Non-Volatile Storage HOB

Another HOB worth mentioning is the Non-Volatile Storage HOB, which is used to pass data to the host firmware to save for S3 resume or fast boot. The host firmware needs to parse the HOB list to see if such a GUID HOB exists once the continuation function is regaining control from Intel FSP. If so, the host firmware should extract the data portion from the HOB and save it into a platform-specific NVS device, such as Flash, EEPROM, and so forth.

During the following boot process, the host firmware should load the data block back from the NVS device to temporary memory and populate the buffer pointer into the FSP_INIT_PARAMS.NvsBufferPtr field before calling into the FspInit() API. If the NVS device is memory mapped, the host firmware can initialize the buffer pointer directly to the buffer.

Sample Code for Parsing HOBs

This is sample code that parses HOBs to look for memory size below the 4 gigabyte boundary:


GetLowMemorySize (

UINT32 *LowMemoryLength




*LowMemoryLength = 0x100000;


// Get the HOB list for processing


Hob.Raw = GetHobList();


// Collect memory ranges


while (!END_OF_HOB_LIST (Hob)) {


if (Hob.ResourceDescriptor->ResourceType == EFI_RESOURCE_SYSTEM_MEMORY) {


// Need memory above 1MB to be collected here


if (Hob.ResourceDescriptor->PhysicalStart >= 0x100000 &&

Hob.ResourceDescriptor->PhysicalStart < (EFI_PHYSICAL_ADDRESS) 0x100000000) {

*LowMemoryLength += (UINT32) (Hob.ResourceDescriptor->ResourceLength);




Hob.Raw = GET_NEXT_HOB (Hob);




For memory above 4 gigabytes, the following code is used in place of the code looking a PhysicalStart element:

if (Hob.ResourceDescriptor->ResourceType == EFI_RESOURCE_SYSTEM_MEMORY) {


// Need memory above 4GB to be collected here


if (Hob.ResourceDescriptor->PhysicalStart >=

(EFI_PHYSICAL_ADDRESS) 0x100000000) {

*HighMemoryLength += (UINT64) (Hob.ResourceDescriptor->ResourceLength);



Customization of Intel FSP

Even though Intel FSP can carry out CPU, memory, and companion chip initialization, it needs the cooperation from the host firmware to pass in crucial information about the platform. And developers can also customize Intel FSP by changing the hardware configuration settings when necessary.

The way Intel FSP organizes the configurable region is to separate it into two areas: a static area and a dynamic area. The static area is called VPD (Vital Product Data) and the dynamic area is called UPD (Updatable Product Data). Both areas can be customized using the BCT; however only the UPD area can be overridden by the host firmware during runtime.

The way to override the UPD data is to copy the UPD data structure to the temporary memory (remember that this is before FspInit is called), modify the data you want to alter, and then pass the pointer in as an input parameter. The FspInit API parameter includes a pointer that can be initialized to point to the UPD data structure. If this pointer is initialized to NULL when calling the FspInit API, the FSP will use the default UPD data that is available in the FSP configuration region. If it is not NULL, the FSP will use the data structure in temporary memory. Whatever data you have modified will be used to configure the hardware when FspInit executes.

The following shows an example of the VPD data structure:

typedef struct _UPD_DATA_REGION {

UINT64 Signature; /* Offset 0x0000 */

UINT32 RESERVED1; /* Offset 0x0008 */

UINT8 Padding0[20]; /* Offset 0x000C */

UINT16 PcdMrcInitTsegSize; /* Offset 0x0014 */

UINT16 PcdMrcInitMmioSize; /* Offset 0x0016 */

UINT8 PcdMrcInitSPDAddr1; /* Offset 0x0018 */

UINT8 PcdMrcInitSPDAddr2; /* Offset 0x0019 */

UINT8 PcdeMMCBootMode; /* Offset 0x001B */

UINT8 PcdEnableSdio; /* Offset 0x001C */

UINT8 PcdEnableSdcard; /* Offset 0x001D */

UINT8 PcdEnableHsuart0; /* Offset 0x001E */

UINT8 PcdEnableHsuart1; /* Offset 0x001F */

UINT8 PcdEnableSpi; /* Offset 0x0020 */

UINT8 PcdEnableLan; /* Offset 0x0021 */

UINT8 PcdEnableSata; /* Offset 0x0023 */

UINT8 PcdSataMode; /* Offset 0x002E */

UINT8 PcdEnableAzalia; /* Offset 0x002F */

UINT32 AzaliaConfigPtr; /* Offset 0x0030 */

UINT8 PcdEnableXhci; /* Offset 0x0034 */

UINT8 PcdEnableLpe; /* Offset 0x0029 */

UINT8 PcdLpssSioEnablePciMode; /* Offset 0x002A */

UINT8 PcdEnableDma0; /* Offset 0x002B */

UINT8 PcdEnableDma1; /* Offset 0x002C */

UINT8 PcdEnableI2C0; /* Offset 0x002D */

UINT8 PcdEnableI2C1; /* Offset 0x002E */

UINT8 PcdEnableI2C2; /* Offset 0x002F */

UINT8 PcdEnableI2C3; /* Offset 0x0030 */

UINT8 PcdEnableI2C4; /* Offset 0x0031 */

UINT8 PcdEnableI2C5; /* Offset 0x0032 */

UINT8 PcdEnableI2C6; /* Offset 0x0033 */

UINT8 PcdEnablePwm0; /* Offset 0x0034 */

UINT8 PcdEnablePwm1; /* Offset 0x0035 */

UINT8 PcdEnableHsi; /* Offset 0x0036 */

UINT8 PcdIgdDvmt50PreAlloc; /* Offset 0x0043 */

UINT8 PcdApertureSize; /* Offset 0x0044 */

UINT8 PcdGttSize; /* Offset 0x0045 */

UINT16 PcdRegionTerminator; /* Offset 0x003A */


Whereas a sample VPD data structure is shown here:

typedef struct _VPD_DATA_REGION {

UINT64 PcdVpdRegionSign; /* Offset 0x0000 */

UINT32 PcdImageRevision; /* Offset 0x0008 */

UINT32 PcdUpdRegionOffset; /* Offset 0x000C */

UINT8 Padding0[16]; /* Offset 0x0010 */

UINT32 RESERVED1; /* Offset 0x0020 */

UINT8 PcdPlatformType; /* Offset 0x0024 */

UINT8 PcdEnableSecureBoot; /* Offset 0x0025 */

UINT8 PcdMemoryParameters[16]; /* Offset 0x0026 */


These two examples are from the Intel FSP for Intel Atom E3800 Product family. In this VPD data structure, each element has a matching member provided in a Binary Setting Flag file, which specifies the layout of the configuration region.

Downloading Intel FSP

Now you understand the basic plumbing and interface of Intel FSP. More practice exercises will be provided in later chapters using coreboot and EDK II codebase to show how they integrate Intel FSP, including the handling of input parameters and output parameters. During these exercises, you will need to download a copy of Intel FSP. Here are the steps:
  1. 1.

    Figure out which CPU and Chipset combo you are designing your firmware for. If you are working on a SoC, you need to figure out which SoC family you are using.

  2. 2.

    Go to and select the “Download an Intel FSP” link, as shown in Figure 3-4.

  1. 3.

    Once you click the “Download an Intel FSP” link, it takes you to the next screen, as shown in Figure 3-5. Select the kind of package you want: Windows or Linux.

  1. 4.

    After accepting the licensing agreement, the download will start. After downloading, unpack it.

  1. 5.

    Depending upon which source code codebase you are using, you can start copying them to the appropriate folders under the host firmware directory trees.

Now, you are ready to create code, change the code, and build the code.

Microcode Patches

Microcode is a unique machine code that runs inside a CPU and many other silicon chips to initialize its internal states and features. Since the year 2000, all modern CPUs have been using microcode updates to fix issues that are frequently documented in erratum by silicon vendors.

The microcode update format is not documented and it cannot be easily read or understood by engineers who are not specialized in microprogramming. For example, one microinstruction could carry out a “Connect this register to that side of the ALU” task, and the other one might “Set ALU’s carry input to zero”. Each microinstruction may be doing something completely tied to the silicon at the logic level, and will only make sense to the silicon designers who actually designed the chip.

As shown in Figure 3-8, one of the Intel FSP folders is called Microcode, and it has the microcode updates that are available at the time Intel FSP was released. Intel FSP has the microcode update mechanism already incorporated. During the microcode update step, it will check the CPUID of the microprocessor on the circuit board and update the appropriate microcode update file into the CPU. There is the possibility that you are using a newer board with a newer stepping of the CPU, and thus the microcode updates inside Intel FSP do not match the stepping of your CPU; therefore, it will not be able to find the appropriate microcode update to update your CPU, and the system will hang as a result. If this is the case, you will need to go to Intel’s support web site and look for the latest microcode updates for the CPU you have on board, convert it from a raw text file to an .h or an .inc text file, and copy it to the corresponding microcode folder in the host firmware directory tree.

If you are familiar with Linux commands, here are two commands to convert from a .txt file to .h or .inc files:

cat name.txt | awk ' { print $1 ; print $2 ; print $3; print $4 } ' > name.h

cat name.txt | sed 's/,//'| awk ' { print " .long " $1 } '

There is also a utility in the coreboot tree to convert the microcode file for you; there may be other tools available to do the same thing.

The microcode updates–based address and the length are passed into the TempRamInit API as an input parameter, which is stored in ROM and is part of the ROM-based stack that we described earlier. In a multiprocessor environment, FSP supports BSP (Boot Strap Processor) and AP (Application Processor) microcode loading. The microcode range can contain multiple back-to-back microcode binaries, and the FSP will check them one by one and load all applicable patches. The microcode code patches for BSP will be loaded inside the TempRamInit API, and the patches for AP will be loaded in the FspInit API.

Relocating Intel FSP

After you download and start building your host firmware, you are told to put the Intel FSP binary at the physical location described in the FSP integration guide. However, if you decide to move Intel FSP, you will need to run BCT and change the base address of FSP to the location you prefer to use. This step is needed because many internal references to the base address need to be corrected by a tool, since they do not dynamically resolve address assignment at runtime.

Integration and Build

At this point, you should have all the elements from Intel in place to do an integration with your host firmware stack. Once you have done the integration, the build process and testing will begin. Hopefully, you will spend most of time developing your value-added features, rather than debugging Intel silicon code. Intel FSP should have taken care of your basic silicon initialization needs at this point.

The Future of Intel FSP

Intel FSP is only the first step in the direction that Intel wants to take to help embedded and IoT developers to adopt Intel Architecture easily and quickly, so that they aren’t spending precious time studying, implementing, and debugging silicon-related configurations and issues. Going forward, Intel FSP will continue its evolution toward a more flexible, scalable, and customizable silicon initialization module, and will cover more silicon on the Intel roadmap. We do realize that there are different needs in the developer community. Unfortunately, these needs are distributed on a scale with two opposite extremes on the spectrum. On one end are the developers who want completely open source code available to them so that they can play with the source code with total freedom and total control. On the other end are the developers who just want a turnkey solution so that they don’t have to know anything about firmware; “knobs” for tuning parameters and for turning on and off features are all that they need.

The best way to satisfy everyone is to keep opening up source code for collaboration and customization and to provide different levels of turnkey solutions where it makes sense.

What Is Coming in the Following Chapters

By now, if you have been reading this chapter carefully, you should know what Intel FSP is, why it was created, what it can do, and how it carries out the work, as well as how to customize Intel FSP and how to integrate it into the host firmware stack of your choice.

Even though there are only three APIs (this number may change in a future Intel FSP) that you need to interface with in your firmware stack, you still need to prepare input parameters and deal with output parameters carefully, and learn how to build the firmware with the right tools. It is best if you continue by reading the following hands-on chapters to get familiar with the practical knowledge about building successful firmware stacks.

Copyright information

© Jiming Sun 2015

Open Access This chapter is licensed under the terms of the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (, which permits any noncommercial use, sharing, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence and indicate if you modified the licensed material. You do not have permission under this licence to share adapted material derived from this chapter or parts of it.

The images or other third party material in this chapter are included in the chapter’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

Authors and Affiliations

  • Jiming Sun
  • Marc Jones
  • Stefan Reinauer
  • Vincent Zimmer
  1. 1.WAUS

Similar news:

coreboot & FSP for Intel

Fast, predictable, minimalistic boot firmware

coreboot is minimalistic boot firmware for a variety of types of processors. On Intel® architecture-based processors, it is an alternative to UEFI and legacy BIOS boot firmware.
While traditional BIOS and UEFI firmware solutions can be used in embedded systems, they are primarily written to be used in common commercial systems such as laptops, workstations, and servers.
This can lead to problems when the needs of the embedded system diverge from those of a commercial system. coreboot provides a base for a fast, predictable, reliable, and efficient boot firmware.

coreboot & Intel® FSP solutions from X-ES

The X-ES coreboot firmware with the Intel® FSP is available as either a standard or optional feature on many of our Intel® processor-based SBCs. Our standard coreboot firmware releases are configured for a balance between boot time and feature support.

X-ES coreboot is a supported, verified, customized, standard x86 BIOS compatible distribution of the Open Source coreboot firmware. This is a corporate-and-community-developed alternative to UEFI and legacy BIOS boot firmware for Intel processors.

Along with the firmware image itself, the X-ES coreboot distribution comes with a development package which includes the source code for all open source components, documentation, and the necessary tools to build the final binary free of license fees and royalties.

stopwatch icon

Lightning Fast

Reliable, sub-2.5 second boot times on most boards makes coreboot an ideal solution when rapid system initialization is required.

coreboot icon

Open Source

As an open source firmware, coreboot does not have license fees, and receives contributions by hundreds of developers annually.

Lock icon

Ultra Secure

The small, simple, and open code base of coreboot and its payloads lends itself to easier security and reliability auditing.

Payload modules provide boot compatibility & flexibility

The coreboot project was designed to perform the minimal hardware initialization required for booting, then pass control to what coreboot refers to as a ‘payload’ to finish the boot procedure.

Various payloads can be built into the boot firmware flash image to do different things, such as boot a specific operating system, run a specific test, or load the services expected from a typical BIOS.

For X-ES’ coreboot implementation, the SeaBIOS package provides legacy BIOS compatibility services and loads the user’s operating system from standard storage devices. X-ES coreboot also includes built-in iPXE, an open source network boot firmware which provides advanced, standards-based network boot options.

Complex initialization simplified by coreboot

Power-on initialization of modern microprocessors is a complex task that requires software written with specific knowledge of the board they are installed on. Detailed information about the processor and its register sets are required to initialize the processor itself and its memory controller.

Until recently, this information was out of the reach of the typical open source developer without a direct connection to Intel®. With their release of the Firmware Support Package (FSP), Intel® has enabled open source projects, such as coreboot, to support their cutting edge processors.

Featured X-ES Boards that Support coreboot
and the Intel® FSP

XPedite8101 XMC/PMC Mezzanine Module


Intel® Atom™ E3800-based XMC/PMC mezzanine module featuring up to 8 GB of DDR3 ECC SDRAM, up to 32 GB of SLC NAND flash, and power-efficient 22 nm technology.

XPedite8150 COM Express Mezzanine Module


Extended Mini COM Express® module based on the Intel® Atom™ E3800 series of processors, featuring up to 32 GB of SLC NAND flash and 4 GB of DDR3 ECC SDRAM.

XPedite7670 3U VPX SBC


High-performance, 3U VPX SBC based on the Intel® Xeon® D processor with up to 16 Xeon®-class cores in a single, power-efficient System-on-Chip (SoC) package.

XPedite7674 3U VPX Single Board Computer (SBC)


High-performance, 3U VPX SBC based on the Intel® Xeon® D processor with an integrated, user-configurable Xilinx Kintex® UltraScale™ FPGA for hosting custom security functions.

Advanced Features from X-ES' coreboot Distribution

Building upon the base of coreboot, X-ES has incorporated numerous features to meet the needs of our customers. Operating in a fully write-protected system or adjusting the boot flow based on non-volatile configuration, GPIO, or by external device reads are all possible.

In addition, a minimal Linux image is included in the boot firmware to provide a familiar, user-friendly and powerful Command Line Interface (CLI) to the user when system diagnostics are required.

Optimized Execution for Near-Instantaneous Boot

The execution time of the boot firmware can be optimized by customizing coreboot and its supporting components. Stripping out unnecessary support for hardware or software can reduce the boot time.

In some cases it is possible to embed either the entire application, or just part of it, directly into the boot firmware to skip the initialization delays associated with common mass storage devices.

Simple & Agile Codebase for Maximum Performance

The small, simple, open code base of coreboot lends itself to easier security and reliability auditing. Unused code can be removed to further reduce the code size. Unlike more complicated boot firmware solutions which rely on journaling non-volatile storage to track each boot (resulting in significantly different code paths on each boot), coreboot follows the same code path on each execution.

Another benefit of coreboot’s usage of build-time configuration is that the firmware image can be configured to boot exactly as the application requires on the first time, without requiring a technician to navigate configuration menus. This leads to a simpler, more consistent and reliable manufacturing, provisioning, and sanitization process.

X-ES & the coreboot Firmware

X-ES provides coreboot solutions for a variety of X-ES single board computers and processor mezzanine products, enabling impressive sub-2.5 second boot times.

X-ES is able to provide support, expertise, development services, and training to assist in customizing the boot firmware on X-ES products to meet the exact needs of the customer’s application.

Speak to one of our product experts today to learn more about how coreboot can be supported in your project.


1076 1077 1078 1079 1080