Refining Open-Source Firmware Support for the Intel Platform

System Firmware Development on the latest SoC platforms has been limited to the proprietary firmware and the Intel® SoC platform is not an exception. This proprietary firmware is the essential slice for bringing silicon to life and defining its stability. Over the years, the state of closed-source blobs used for platform bring-up hasn’t improved, in the sense of leading towards openness. The exhaustive Outline section highlights the IA-SoC-based system firmware SPI flash layout (Figure 1-3) and Table 1-1 shows the challenges in the current approach.

TL;DR challenges with rapid growth in proprietary firmware from a platform enabling standpoint are:

• Dependency on SoC vendors to own the bug and provide the fix, finally sharing the release cadence might not fit well with open-source project milestones.
• Limited engineering effort at silicon vendor side where else the broad open-source ecosystem is unable to contribute even if they have the intention to contribute.
• One-binary-fits-all requirements make it bloated and unnecessary feature inclusion without the particular product interest and might increase platform security risk.

Reduce Firmware Support Package (FSP) boundary on Intel® SoC Platform

This proposal is intended to discuss a path forward towards getting openness in system firmware development with Intel SoC (which primarily uses FSP blobs for Silicon and Platform Initialization).

Primary Objectives

• Improve the platform enabling model better by balancing out the `binary blob model` (include if *mandatory* and can’t be open-source) and focusing on bringing openness in silicon code by leveraging open-source boot firmware e.g. coreboot.
• Reduce the boundaries of proprietary firmware running on Host CPU Firmware a.k.a Intel Firmware Support Package (FSP).

Secondary Objectives

• Achieving the ambitious goal of fast booting (< 1 second boot time) up the system firmware.
• Drop unused FSP modules to reduce FSP boundaries to eventually optimize the SPI flash footprint.

Non-goals

• This is moreover an initiative to overcome the problem that the open-source firmware community is facing, additionally, hearing from ODM/OEM partners and representatives[1] working on the Intel SoC platform, etc.

Key Features and/or Requirements

• Share a  Platform Initialization (PI) vision that utilizes more openness.
• Consistently in the gen-over-gen SoC platform, be able to meet the system firmware boot time requirement of < 1 second.
• Define a fixed SPINOR size requirement that applies to all product guidelines.

Design ideas

This design document shares emerging ideas to solve this longstanding problem of proprietary firmware for Open Source Firmware (OSF) Development. This section is specifically written to meet the primary objectives listed above. Additionally, the ideas are listed below in merit of exclusive study (on the Intel platform, additionally, based on some comparative study on other SoC platforms) and in-house proof of concept performed on the latest Intel platform.

Unless this design discussion materializes now, the current state of Open Source firmware development using proprietary firmware on IA SoC platforms won’t improve in the future.

An “Alternative Path” forward towards Open Source Firmware

This section highlights an alternative approach where SoC vendors are not committed to open-sourcing silicon reference code, and at times, it’s critical for the open-source community and products that derived out using OSF for their business commitment. Gaining more control over the platform initialization is the major theme for this proposal that empowers the open-source firmware developers.

Due to a lack of a minimal FSP design guide, the roles and responsibility boundaries between FSP and bootloader (i.e. coreboot) are not very clear as FSP (PEI phase) is intended to do more things to supplement UEFI bootloader. For example, lockdown configuration done as part of FSP is ideally a primary bootloader's responsibility.

The Key Performance Indicator (KPI) defines critical criteria for product quality. FSP is used for production as silicon reference code doesn’t have responsiveness KPI. As a result, while integrated with the bootloader it is difficult to debug any responsiveness issue in case the final product responsiveness KPI is not met.

Additionally, any issue being fixed into the Intel FSP development trunk has several weeks latency (between 2-6 weeks in some cases) to make the fixed FSP externally available for consumption. Having only read access to FSP GitHub limits the external Intel FSP development community (i.e., open-source firmware development engineers) to being unable to continue into the code even if the fix is known.

Gain Control of Platform Initialization using native coreboot driver

This approach states the specific route that coreboot platform initialization implementation had explored in the past and would also like to explore, knowing the lack of open source silicon initialization commitment.

In the past with FSP 2.0 specification, coreboot decided to make FSP-T optional as it relies on open source cache-as-ram (CAR) implementation and is updated periodically to add new SoC support.

This section highlights the short term and long term plan in this approach, along with a few design assumptions:

Drop FSP APIs and use coreboot native driver with the below characteristics:

• Chipset programming is documented as part of external datasheets (processor/pch).
• Implement only the Intel recommended chipset programming steps for ODM/OEMs, for example, Alder Lake FAS chapter 12 specifies the Security Configuration, ideally, all host-firmware running on Alder Lake SoC should comply with this recommendation.
• Programming steps and outcome expectations are well captured in White Paper/BWG/FAS (non-confidential document).
• Only focus on IP programming that is applicable for targeted platforms (example: RAS, RST, etc. are irrelevant for CrOS devices).

A consideration while implementing chipset programming recommendations in coreboot:

• Design APIs-based implementation based on the underlying IP.
• Implemented using a common code library and have hooks for SoC/mainboards(variants) to override if required. Ideally, we would like to avoid overrides because it might make things harder while debugging. The idea is to have a more compatible design approach reflected in firmware and software, and how it appears in hardware in general (like reusable IP across different SoC with up-rev IP versions).

Figure 1-1 presents the current plan of action for implementing the gain control proposal in the scope of coreboot, which eventually helps to reduce the dependency on FSP-APIs.

Here are the benefits of this approach

• A thinner FSP footprint with reduced FSP APIs reduces the baggage of proprietary firmware in the Open Source System firmware stack.
• Feasible to open-source the majority of FSP code using coreboot native implementation.
• Improved flexibility while debugging and feature implementation without getting locked into Silicon program milestones and unable to support feature requests even with potential business reasons[2].
• Efficient tooling can also help to reduce FSP binary size after removing unused FSP APIs (example: Removal of FSP-S associate APIs would help to get any size savings by 3x times due to Chrome AP firmware SPI layout).

Below code changes landed into upstream coreboot to get rid of FSP Notify Phase APIs[3] (as proposed in Figure 1-1) for Alder Lake SoC-based platform.

Note: Reduction of FSP Notify Phase APIs is just a tiny step toward the right direction where the idea is to get rid of most non-mandatory FSP APIs (FSP-Silicon Init aka. FSP-S) with native coreboot drivers. Figure 1-2 illustrates the proposed FSP-API view for future SoC platforms (which is possible to achieve with help of the open-source community while co-working) that integrate with open-source coreboot boot firmware.

The proposed design solution and implementation is very much generic and can be applicable even for other SoC designs that inherit the FSP framework, for example, AMD's latest SoC platform adopts FSP.

Exhaustive Outline

Table 1-1, describes the challenges due to proprietary firmware during platform enabling.

Summary

Proprietary Closed Source Silicon Reference Code is the most used approach in modern host firmware development to support restricted SoC platforms. Open Source Firmware development model is expected to see more openness towards platform enablement solutions but still sensitive towards silicon vendors business model hence adopted the hybrid model to balance out the business in front of certain limitations in the current open-sourcing approach. Going forward the expectation is to have zero or absolute essential binary blobs, that are reduced in size, easy to configure, and flexible enough to build using a software development kit (SDK), which would bring more code visibility to the public. Additionally, allow users to build and integrate the essential binary blobs with pure open-source boot firmware for creating the system firmware for the targeted embedded system.

Looking forward to your feedback and thoughts to improve the current platform enabling using an open-source firmware development model to innovate in the future.

References

[1] Open Source Firmware Community is asking about Intel’s commitment towards PI open-source https://mobile.twitter.com/_zaolin_/status/1497237365135491072

[2] Need to compromise on Firmware Boot time on Alder Lake-P platform due to program milestone concerns https://review.coreboot.org/c/coreboot/+/61447

[3] Intel FSP 2.1 specification release email to coreboot mailing list highlights that FSP dispatch mode is also not using FSP-NotifyPhase APIs natively implemented in PEI phase. https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/WCGVZABKXYYSWBSLORIKIHY4JE5VWCGM/

[4] Source: Brya ChromeOS.fmd https://github.com/coreboot/coreboot/blob/master/src/mainboard/google/brya/chromeos.fmd