BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


TECHNOLOGY CORE

Intel Pushes the Envelope for Embedded

Intel Firmware Support Package for the Internet of Things

There are a number of unique firmware requirements for embedded systems and IoT that do not require the familiar BIOS but rather domain- and application-specific needs. Specific firmware support addresses these unique needs in the embedded and IoT space.

BY JIMING SUN, INTEL

  • Page 1 of 1
    Bookmark and Share

Article Media

When the Intel Firmware Support Package (Intel FSP) was first introduced in October 2012 at Intel Intelligent Systems Summit event held in Taiwan, the immediate response was, “Not again, Intel’s embedded organization seems to come out with a new firmware initiative every two years”. At that time, the Intel Bootloader Development Kit (Intel BLDK) was still in distribution.

“Will Intel FSP stay as a long term initiative?” “Will Intel change direction again in two years after we implement the solution based on it?” These were a couple of typical questions asked in the next two years when Intel FSP was presented in technical conferences and customer meetings, including many RTECC events.

Since the BIOS has been so successful in the PC industry in the last three decades, people have the perception that they need to have a BIOS to work with Intel microprocessors. Sometimes this was what Intel wanted to persuade them to do as well because the Unified Extensible Firmware Interface (UEFI) firmware stack is well tested and there is a strong ecosystem to support it.

However, the question embedded customers frequently ask is: “Can I use a different firmware stack for my unique design if BIOS does not meet my needs?” This is the question we want to address here.

Unique Firmware Requirements for Embedded Systems

It is always fascinating to see what embedded system developers do and design. It turns out that that many embedded systems are relatively closed systems with dedicated functions, and they are highly customized for their business purposes. That means there are some unique firmware requirements that you don’t typically see in a PC firmware:

• PC firmware typically deals with open systems with open bus and device standards. However, embedded systems and IoT typically have closed or proprietary solutions in them.

• PC firmware is ready to deal with devices coming and going any time; embedded systems and IoT typically have limited expansion and fixed configurations.

• PC firmware constantly deals with a changing environment to dynamically adjust system power and performance levels, but some embedded systems need to be deterministic and predictable. Therefore changing speed or execution path is not allowed.

• PC firmware deals with a lot of corner cases because it needs to anticipate many permutations of devices, OS, applications, and user behaviors. However, typical embedded systems or IoT have pre-defined usage cases.

• PC firmware components are mostly designed to be reused, but most embedded systems and IoT firmware are highly customized to optimize for certain design goals.

These are just a few examples of the requirement differences between embedded and PC firmware; obviously not all embedded systems have the same requirements. The main point here is: the one-size-fits-all model does not usually work for embedded developers. Every developer needs to analyze and pick a firmware solution that is the best to match his or her needs. The options might be: Real-Time OS, Open Source firmware stacks (including Open Source EDK, coreboot, U-boot, etc.), and even proprietary solutions.

The other aspect of embedded system design is the domain knowledge and domain-specific features accumulated in the firmware stack over the years. These domain knowledge-based features are frequently distinctly different from application to application and from market to market. A company that has been in a vertical market segment for a while most likely has accumulated valuable experience and intellectual properties. They don’t want to re-do or port these over to a different firmware stack if they can avoid it. Therefore, allowing them to protect their investment in firmware is a must for vendors who are trying to help them to adopt a new silicon architecture.

Intel Firmware Support Package

Now, Intel has offered the industry a solution to allow existing firmware investment to be preserved. The solution is called the Intel Firmware Support Package or Intel FSP. The idea of Intel FSP is to provide the developers an encapsulated bundle of features that deal solely with silicon initialization which only Intel knows how to do effectively.

In the past, when a developer received a new set of Intel chips, they had to figure out how to program the chips by reading technical documents, comparing the sample code, porting the firmware, and even asking for help from the BIOS vendors or software vendors to help them implement the silicon initialization part of the firmware.

Obviously, this does not mean that, with Intel FSP, the developers do not have to read documents anymore, but for any standard designs where the developers only care about getting chips functional quickly so that they can start developing value-added software features, Intel FSP can dramatically cut down the time required to learn how to program a new set of chips.

Intel FSP includes all the silicon initialization code that provides basic functionality. For example, after the execution of Intel FSP code, the memory will be fully functional and the firmware stack owned by the developer can use the memory to run value-added features and to discover the topology of system buses and devices. There should be no need to refer to confidential programming documents that the developer may or may not have access to.

What Does Intel FSP Do?

As described before, Intel FSP carries out CPU initialization, memory initialization, and companion chip initialization. Also, it will grab microcode patches and apply them after matching CPUID with the silicon on the circuit board. The microcode patches can be updated separately so that Intel FSP can work with the latest CPU you have on your board even though Intel FSP was released earlier.

Beyond Intel’s silicon initialization, it is up to the firmware stack to implement the rest of the platform firmware code; for example, platform initialization, power management, secure boot, device discovery, boot device selection, and OS loading. Intel FSP is not a stand-alone boot firmware; it needs to be integrated into a firmware stack of choice. Some developers might be bothered by the fact that Intel FSP does not include all the features as the reference BIOS does, but this is only one of the ways that Intel designs to support developers’ needs. If a developer wants to see all the reference code from Intel, the reference BIOS option is still offered. Intel FSP is the vehicle to support the developers who have an existing firmware stack, or decide to use a different firmware solution than BIOS. Intel FSP is not a replacement for BIOS; it is designed to provide a building block for people to easily overcome the first step of initialization.

As shown in Figure 1, the typical boot flow involves the following boot steps:

Figure 1
A sample boot flow illustration.

1. The host firmware stack switches to 32-bit protected mode after reset.

2. The host firmware stack discovers Intel FSP (details will be documented in the porting guide).

3. The host firmware stack jumps to TempRamInit API.

4. Intel FSP loads microcode patches, and turns on cache as temporary memory; it could be something other than cache in future CPUs.

5. Intel FSP returns control back to the firmware stack.

6. The host firmware stack carries out pre-memory initialization (such as security check, turn on LED backlight, spin up hard drives, etc.)

7. The host firmware stack calls FspInit API.

8. Intel FSP carries out memory initialization, CPU initialization, and chipset initialization.

9. At this point, memory is fully available, and the root level bus bridge is fully initialized for further bus enumeration and device discovery.

10. The host firmware stack can choose to initialize the rest of the platform and then boot to an OS.

11. After PCI bus enumeration and before booting an OS, the host firmware stack can call back to Intel FSP via NotifyPhase API to lock certain registers to protect system configuration from being tempered by the OS or applications.

The Intel FSP box in the middle, even though looks big, is actually pretty small (about 100KB to 250KB depending upon which memory technology is used), and it uses about 100 milliseconds to 300 milliseconds to complete the execution also depending upon the memory configuration. When the developer has a memory-down (soldered down) and fixed memory configuration, the time spent in Intel FSP can further be shortened by 50 or 60 milliseconds after saving the memory configuration in a non-volatile storage or Flash ROM.

As shown in Figure 2, there are 3 interface APIs for the host firmware to jump to or call when integrating with Intel FSP. The first two APIs were described in the previous boot flow section, the last API is a unique API, which allows the host firmware to call back to Intel FSP to lock down important registers and do some final clean-up before giving control to an OS.

Figure 2
Interfacing the Intel FSP.

The output of Intel FSP is a data structure in the format of Hand-Off-Block (HOB) defined in the openly available UEFI Specification. For example, the memory parameters discovered and trained by Intel FSP will be made available via HOB so that the host firmware can pick them up from here, save them, and use them for other parts of platform initialization.

Part of Intel FSP is a data region that contains all the configuration settings (Figure 3).This part of the configuration region can be modified statically with a binary configuration tool (BCT), or dynamically by the host firmware stack. The BCT is available for download at the same web site as Intel FSP (http://www.intel.com/fsp/).The configurable features, such as: ECC versus non-ECC, SPD ROM I2C address, ME size, Fast-Boot mode, are presented in a GUI based BCT, in both Windows and Linux versions. A command line version is also available upon request.

Figure 3
Intel FSP Configuration.

Using Intel Atom Processor E3800 (formally known as Bay Trail) as an example, once you download the self-extracting kit from Intel’s web site, the kit will expand to a file structure as in Figure 4 and there are: an integration guide, several header files and sample code, a Boot Setting File (BSF), microcode patches, and optionally a graphics component, such as VGA BIOS.

Figure 4
Contents of Intel FSP Kit

The integration guide provides the step-by-step instructions about how to integrate Intel FSP into the host firmware stack; the BSF is the file that contains all the configurable features, and the header files can be used by the host firmware to leverage the existing data structure provided by Intel FSP. The BCT can be used to manipulate the data inside BSF and it also allows the developer to rebase Intel FSP to another location in the ROM if the default location needs to be changed.

An Example in Integration

The Intel FSP is agnostic about which host firmware stack it is being integrated into, but Intel has been using coreboot as an example to demonstrate the steps. The open source firmware community, coreboot, was created by Ron Minnich in 1999, using the LinuxBIOS name; it was renamed coreboot by Stefan Reinauer in 2008. The source code is mostly in C language compiled and built with the gcc tool chain. A unique feature of coreboot is its module payload concept, which allows you to integrate a payload based on a specific OS or application. For example, Google’s Chromebook has a “Depthcharge” payload specifically designed to load ChromeOS.

The pre-requisite of building coreboot is to set up a Linux or Cygwin-type of Linux environment under Windows. At the command line of Linux or Cygwin, you have the following steps to take care of the build environment (Figure 5):

Figure 5
FSP integration example.

(1)    Clone the coreboot git repository, by running the command:

>    git clone http://review.coreboot.org/p/coreboot

It might require you to config proxy if you run this command behind a firewall.

(2)    Once the coreboot source code tree is duplicated on your work space for coreboot, you need to build the tool chain by running the following commands:

>    cd coreboot

>    make crossgcc

(3)    It will take a while for the tool chain to be downloaded and built on your machine.

(4)    Once the tool chain and the source code are available, you need to download Intel FSP that you are interested in building from Intel’s http://www.intel.com/fsp/ web site.

(5)    In parallel to the “coreboot” directory that was created in step (1), you need to create a new directory, and name it “intel”.

(6)    Then, you need to move the files from Intel FSP kit to the “intel” directory tree that you have just created:

The example in Figure 5 could be different from project to project, and the box on the right hand side can be customized to your own firmware stack, whether or not it is an RTOS or your proprietary source code.

Figure 5
FSP integration example.

(7)    Once all the Intel files are in place, all you have to do is to go back to the “coreboot” directory, and run:

>    make menuconfig

(8)    This will show the GUI based coreboot configuration menu for the build environment.

(9)    After you carefully change all the components inside the menuconfig configuration, you can exit it and save it to the .config file inside the directory.

(10)     Now, you can try to run “make”, and a coreboot.rom will show up in the “build” directory under coreboot.

This example may be shown as a simple ten-step operation, but there are many places that could take a while to debug to resolve all the issues. Once this is done, you have a pretty consistent environment for all future projects.

Intel FSP Development Options snd Ecosystem

In the last few years, Intel has been working with a few ecosystem partners to enable them to support developers’ needs in Intel FSP integration with different firmware stacks, such as: Wind River Systems, Sage Engineering, Waris Technology, Mobica, Ircona, Eltan, Insyde, ByoSoft, and AMI.

If you have your own firmware engineering resource and would like to integrate Intel FSP into your firmware, you can certainly do so by following the instructions provided in the Integration Guide of each Intel FSP release. Or, you can contact one of the ecosystem partners listed on Intel’s FSP distribution web site to help you with the integration effort. Some of these vendors also provide different levels of turn-key solutions, such as: board support package and web-based firmware build tools to help you build firmware for your particular system.

Intel
Santa Clara, CA.
(408) 765-8080
www.intel.com