Dear Intel,
We have heard you, and we agree with you: “Innovation thrives in an open, democratized environment where people can connect, collaborate, and respond together to new stimuli.…. This free exchange increased our ability to learn from one another.” [1] Under this exact sentiment, we hereby request a pledge from Intel to adopt an open source friendly development approach for silicon firmware delivery.
According to the published technical article by Subrata Banik from Google (Open Source Firmware Development: Reduce Firmware Support Package (FSP) boundary on Intel® SoC Platform) [2], there are imminent and industry-wide demands calling for a more open source approach in the host firmware space. Let’s examine the current situation and define the most feasible path forward.
A decade ago, Intel introduced the Firmware Support Package (FSP), which wraps the proprietary processor and chipset initialization code in a binary PI (platform initialization) model. This enabled any vendor or developer in the world to adopt Intel SoCs freely without the IBV lock-down. Since then, the open source firmware initiative has given birth to many thriving firmware projects like coreboot, U-Boot, LinuxBoot and many; thus creating a healthy firmware ecosystem surrounding x86 architecture and more specifically with Intel architecture.
Over the years though, the FSP has grown significantly, and each new generation has become an increasingly chunky and tightly locked down firmware framework for the various hardware platforms. The ‘one-binary-fits-all’ model not only provides the developers and ecosystem partners with very little to no control over the chip enablement, it also increases platform security risks as more closed code without a chance for a public review has been added in every generation causing the FSP to become more and more bloated. This has unquestionably increased the deployment cost on the partners' side while they work on Intel platforms and has set a very high threshold to enter the Intel ecosystem.
The new “alternative path” model outlined by Subrata creates a very viable and pragmatic approach to get rid of the secrecy in the platform enablement model present in the current approach. It balances the business needs of SoC vendors and protects their core interests while enabling more innovation and allowing participation from the open source community. Here are some of the highlights of the new design philosophy:
The goal of highly integrated firmware can only be achieved if the code that is integrated into coreboot or other firmware packages is available as source code. Every code that is added in binary form during the build contradicts this approach and produces unnecessary tension within the community and between Intel and their partners. Having the source code for as many pieces as possible in the boot flow enables the community to find the most suitable boot solution for all Intel processors directly.This will not only speed up the development but in addition provide high quality and adaptable code doing the initialization right.
Hereby, we call upon Intel to join us and commit once again to the power of an open ecosystem.