Like in the previous year, we visited the Chaos Communication Congress and hosted an assembly.

Once again, we exhibited a simple demo of the LogoFAIL vulnerability, and Ahmad Fatoum from Pengutronix joined us this time to provide a demo of the Barebox bootloader featuring Snake and DOOM.

In total, we gave 4 workshops, offered 4 badges for people to discover, and had enough space to accomodate a dozen hackers. Many people visited us, being curious about what's in their laptop's firmware or how to get coreboot on their ThinkPad T480(s) laptops, which 4 of them successfully did through the help of deguard.

Projects

One of our main focuses was on laptops and mobile devices. With a handful of Ubuntu maintainers, we had a great exchange about Chromebook support in mainline Linux and distributions, such as enabling missing modules downstream as well as userland. Those require adjustments in the respective drivers. For example, mediatekdrmfb would currently break without a DisplayPort bridge being present. Such cases require careful handling in order to ship images that work well for everyone.

Close to us sat our friends at the Linux on Mobile assembly, with whom we debugged Google's bootloader and device tree and from whom we borrowed a USB-Cereal. One of the core projects is postmarketOS, a Linux based operating system for mobile devices. That includes a lot of work on firmware on bootloaders.

Over the days of hacking, we made progresss: On Arm64 platforms, such as MT8186+, we got some steps further with audio using Sound Open Firmware (SOF) for LinuxBoot. We also discovered a regression in Mesa on a Mali G57 GPU that we will report back.

Finally, to get more people started with the project, aprl and elly gave a talk on corebooting Intel-based systems, explaining what to do when porting a new board.

Workshops

On the first day, in the first workshop, participants learned about firmware images as found on modern AMD and Intel platforms, consisting of many different parts, which they could browse using Fiedka, UEFITool and various command line tools.

On the second day, in two consecutive workshops, we took apart firmware blobs using Ghidra and learned about various ways of following remappings in memory and dealing with peripherals, then got started with oreboot on the platform we had investigated earlier.

After some extra fiddling, we got the first output from a Canaan K230 SoC.

Following up on ideas from LinuxBoot and the earlier workshop on firmware images, we looked at ways of modifying UEFI firmware on laptops on the third day in the last workshop, using the ThinkPad X270 as an example. With Fiedka, we could remove unnecessary UEFI binaries, and using utk from the Fiano suite of tools, we put a Linux kernel in flash booting up within 3 seconds, finishing up with a demo of running mpv via cpu to play a video on the target device.

In conclusion, we had a wonderful experience with lots of fun and many people joining in. We look forward to the 39th Chaos Communication Congress at the end of this year and the upcoming FOSDEM, where we will be hosting a stand showcasing coreboot, flashprog and other firmware projects.

Executive Summary

This document details the successful implementation of 64-bit boot support (x86_64 architecture) in Chrome AP firmware to boot ChromeOS devices (i.e., Chromebook, Chromebox etc.) . The primary motivation for this transition was to overcome the 4GB memory limitation of the traditional 32-bit architecture, which is increasingly insufficient for modern hardware demands.

Key technical changes faced during enabling 64-bit mode in various boot phases, including Cache-as-RAM (CAR) mode, and ensuring compatibility with SoC APIs and the payload (libpayload and depthcharge for booting ChromeOS). A unified entry point for both 32-bit and 64-bit modes was implemented in libpayload, and depthcharge was modified to support 64-bit compilation.

Comparative analysis between 32-bit and 64-bit builds showed an expected increase in SPI flash size by approximately 0.3MB (to support 64-bit architecture), but no significant impact on boot performance. This confirms that the transition to 64-bit architecture is feasible without performance regressions, paving the way for future ChromeOS devices using Intel SoC platform.

Objective

This document captures the journey of adding 64-bit boot support to the Chrome AP firmware, which involved adopting the x86_64 architecture.

Background

Traditionally, the most popular x86 architecture supports the 32-bit architecture meaning the flat address space is limited to 4GB and need to enable remapping/physical to virtual memory mapping if wish to access memory above 4GB. The first x86 processor that introduced 32-bit architecture was the Intel 80386, also known as i386. It was released in 1985 and marked a significant advancement in the x86 line of processors.

• The i386 could address up to 4GB of physical RAM memory.
• 32-bit Registers and Data Path allowed for faster calculations and manipulation of data.
• Protected Mode, initially introduced in the 80286 processor, extended the addressable memory space significantly. This enabled the implementation of a robust memory management system, facilitating virtual memory and enhancing protection against software crashes

The primary constraint of the 32-bit architecture is that it can only address a maximum of 4GB of RAM (2^32 bytes). This limitation became increasingly problematic as software and operating systems became more demanding, requiring more memory to function properly. Additionally, processors are becoming more complex, and more advanced IPs (Intellectual Property) such as AI (Artificial Intelligence) accelerators, USB-C controllers, video, and image processing units are expected to consume more system memory to operate. System memory <4GB is already occupied by existing hardware resources (IPs), system software, etc. As a result, SoC programming logic is unable to meet the hardware resource requirements with advanced SoC IPs, which is another reason why the 32-bit CPU architecture is unable to meet the requirements of advanced use cases in 2024.
In comparison, a 64-bit architecture can theoretically address a much larger amount of physical memory (2^52 bytes or roughly 4092 terabytes) and virtual memory (2^48 bytes, or roughly 256 terabyte). While this is far more than any current system would ever need, it successfully removes the memory limitations imposed by 32-bit systems.

• 4GB maximum addressable RAM in 32-bit vs. virtually unlimited in 64-bit.
• A 64-bit architecture can potentially process data faster due to larger registers and wider data paths.
• Backward compatibility between 32-bit and 64-bit software is also possible.
• The introduction of long mode with page-table enforces the security in system software where flat memory access seems prone to attack.

64-bit architecture for personal computers was first introduced in the early 2000s. The widespread adoption of 64-bit architecture in consumer-level desktops and laptops began in the mid-to-late 2000s with the release of operating systems like Windows Vista 64-bit and the increasing availability of 64-bit processors. System firmware also adapted towards 64-bit mode of booting even in the client segment as EDK2-based firmwares are largely leveraging the 64-bit infrastructure changes coming from the server ecosystem.

Overview

Due to the recent developments in Intel SoC architecture, including the integration of discrete tiles and the reorganization of SoC IPs, there has been an increasing need for more hardware resources. This is necessary to support improved performance and more efficient communication with reduced latency. For example, if a SoC IP/subsystem requires more system memory (than traditional ones) to map the entire device-specific register space. This space can be easily allocated above 4GB of memory if the underlying architecture supports it. However, for system firmware where accessing more than 4GB is not feasible, the SoC must support a special method to provide a window for accessing the same hardware register spaces within less than 4GB of memory boundary. Implementing a special method in SoC designs is costly and necessitates specific security enforcement. Suppose a situation where such special treatment is not feasible in the future SoC roadmap to map device register space below 4GB will no longer be supported. In this case, one possible solution is to enable more than 4GB of memory access, allowing the device register space to be mapped without incurring additional SoC costs.

This is not a significant concern for SoC vendors/ODMs/OEMs/IBVs utilizing EDK2-based system firmware (UEFI) because the 64-bit boot mode has been enabled and supported by Independent BIOS vendors (IBVs) for Windows and Linux-based client devices for several years. However, the UEFI implementation of booting x86_64 architecture is limited to specific boot phases. The early phases like Security (SEC) and Pre-EFI Initialization (PEI) are executed in 32-bit mode, and advanced stages like Driver Execution Environment (DXE) and Boot Device Selection (BDS) are solely executed in x86_64 mode.

Unfortunately, the system firmware (coreboot) used in Google ChromeOS devices has limited support for the x86_64 specification and does not have widespread support. Currently, x86_64 is only available on emulators (Qemu x86_64 board) and a few limited hardware platforms as an exploratory effort. A few specific 64-bit features have been added under the HAVE_X86_64_SUPPORT Kconfig, including:

• Generating static page tables with entries pointing to Page Directory Pointer Entry (PDPE), PDPE with entries pointing to Page Directory Entry (PDE), and PDEs with 512 entries each.
• Loading the Global Descriptor Table (GDT) to access more than 4GB of memory.
• Calling into SoC blobs/APIs in 32-bit mode by following thunking (switching from 64-bit mode to 32-bit mode).
• Transferring control to the payload only in 32-bit mode, where the payload binary should be loaded into less than 4GB of memory. During the jump into the payload, coreboot will transition from long mode to protected mode.

The rationale behind supporting x86_64 boot mode for future Intel SoC platforms is to ensure that hardware resources can be accessed without limitations. Therefore, the goal of  AP Firmware used across ChromeOS devices is more ambitious than the current offerings of coreboot regarding x86_64 support. The following is a list of objectives that Chrome AP Firmware aims to achieve when claiming that x86_64 architecture support is production-ready:

• Ability to switch to 64-bit while operating in Cache-as-RAM (CAR) mode, including validating CAR mode operation in long mode and enabling paging with a large 1GB page table.
• Support for SoC blobs/APIs in 64-bit mode, particularly the ability to call into Firmware Support Package (FSP) API entry points without switching between protected mode and long mode upon exit, thereby reducing latency.
• Exception handling should adhere to the x86_64 architecture specification across all differnt stages of the firmware boot (like boot firmware and/or payload).
• Switch to the payload in long mode without thunking, leveraging libpayload in long mode instead of the traditional approach where coreboot always switches into the payload in protected mode. Design the coreboot to libpayload entry point in a scalable manner to allow more flexibility when switching between coreboot and payload. Validate all below modes of switching between coreboot and libpayload:
  - Support traditional 32-bit mode of switching.
  - Allow thunking from coreboot running in long mode but jumping into the payload in protected mode and eventually transitioning into long mode inside the payload.
  - Support x86S mode of booting as well (for future SoC/FW readiness).
• Migrate all debug interfaces, such as the GDB (GNU debugger), firmware shell (pre-boot CLI environment in Chrome AP firmware) etc. to support 64-bit mode of operations.
• Conduct platform validation, Functional Automated Firmware Test (FAFT), and Targeted Acceptance Support Test (TAST) to ensure that x86_64 is as stable as traditional x86_32 mode of booting.

Detailed Implementation

This section aims to highlight the scattered changes made in the details across various boot phases, both within coreboot and the payload. Currently, the majority of x86 platforms hosted within coreboot projects support 32-bit architecture. Previously, there were limited experimental efforts to add 64-bit architecture support to the coreboot tree. This proof-of-concept work (performed using a Chromebook platform) extends those efforts to ensure that the x86_64 architecture support in coreboot is stable and well-tested.

Responsibility of x86_64 Kconfigs

In order to maintain support for the x86_64 (64-bit) platform alongside the current ecosystem, USE_X86_64_SUPPORT and HAVE_X86_64_SUPPORT Kconfigs are employed. The purpose of this document and the proof-of-concept work is to guarantee the x86_64 boot mode using the Intel Meteor Lake platform, even though supporting x86_64 boot using the coreboot tree is still in the experimental stage. This is done to prepare the Chrome AP firmware stack for future SoC generations from Intel.

To start coreboot in 64-bit mode, the ARCH_ALL_STAGES_X86_64 Kconfig option  is enabled by default when selected. This allows coreboot to run in long (64-bit) mode. All coreboot stages are compiled using a 32-bit toolchain by default, but enabling this option switches to a 64-bit toolchain for all stages.

The Kconfig option USE_X86_64_SUPPORT becomes enabled when HAVE_X86_64_SUPPORT is selected. This selection ensures that all boot phases, including bootblock, verstage (if enabled), romstage, and ramstage, are compiled in long mode."

A 64-bit build of coreboot boot phase picks the Cflags/Linker scripts that are required for x86_64 architecture to generate executable binary in “elf64-x86-64” format.

Moreover, x86_64-specific Kconfig options ensure that the low-level assembly files designed for long-mode operations are chosen over the ones for the native 32-bit implementation mode. For instance, the low-level operations memcpy, memset, and memmove have inherent differences in their operations between 32-bit and 64-bit architectures hence,  to implement mem memory move operation in long mode, memmove_64.S file has been picked over memmove.S .

x86_64 support in Cache-As-RAM

During the power-on reset process of an x86 system, the x86-CPU begins in real mode (16-bit) and eventually transitions to protected mode (32-bit). To enable support for x86_64 long mode, it is crucial to transition the CPU from protected mode to long mode as soon as possible. There is a specific sequence of steps that must be followed to successfully perform this transition.

Enable PAE (Physical Address Extension):

Set the PAE bit in the CR4 control register, enabling 4KB paging and expanding the available physical address space.

Enable Long Mode in EFER:

Set the LME (Long Mode Enable) bit in the EFER (Extended Feature Enable       Register), signaling the processor that Long Mode is desired.

Load a Valid PML4 Table:

Load the CR3 register with the physical address of the PML4 (Page Map Level 4) table. This is the root of the page table hierarchy for Long Mode.

Enable Paging:

Set the PG (Paging) bit in the CR0 control register, enabling paging. This is a requirement for Long Mode.

Far Jump to Code Segment:

Perform a far jump instruction to a code segment with a Long Mode compatible descriptor. This jump completes the transition into Long Mode.

In x86-64 long mode, the page table is vital for translating virtual addresses to physical addresses. They remain crucial for memory management, even in absence of physical memory (aka in CAR mode). A CPU core seeking data from a virtual address initially checks the TLB (Translation Lookaside Buffer), a cache for recent page table entries. If the entry is found, translation is rapid. However, a TLB miss triggers a traversal of the multi-level page table hierarchy. The process starts from the PML4 table (Page Map Level 4) down to the page table entry with the physical address. In the cache-as-RAM scenario, this page table walk retrieves the necessary entries from the cache, emulating regular RAM behavior. IA common code that manages setting up CAR mode, is also responsible to perform long mode transition and setting up the page table.

Early boot phase is also responsible for loading the Global Descriptor Table (GDT) in 64-bit mode that supports >4GB address accesses and exception handling.

Page Table (PT) in coreboot

Page Table in 64-bit architecture is used to bridge between virtual to physical memory access, which is also additionally meant to provide security. Each entry in the page table maps a virtual page to a physical frame, storing additional information like access permissions and caching attributes.

coreboot supports two different types of page table creation logic as below.

• Supporting Large (1GB) Paging: Each page entry in the page table maps a 1GB chunk of virtual memory to a contiguous 1GB region of physical memory. In x86-64, 1GB pages typically bypass the Page Directory Table (PDT) level of the page table hierarchy, mapping directly from the Page Directory Pointer (PDPT) Table to the physical page.
• Supporting Small (2MB) Paging: Each page entry maps a 2MB chunk of virtual memory to a contiguous 2MB region of physical memory. It utilizes all four levels of the x86-64 page table hierarchy: Page Map Level 4 (PML4), Page Directory Pointer Table (PDPT), and Page Directory (PDT).

Figure 1.0 shows the virtual to physical memory mapping in a long mode operation.

In the above example, coreboot creates a static (as physical memory is not yet available) Page Table (PT) and then programs the Page Map Level 4 (PML4) entry into the CR3 register (during the long mode entry the address of the PML4 has been programmed into the CR3 register).

For best software practices, 1GB pages can result in more efficient TLB usage due to fewer entries being required to cover the same amount of virtual address space. This can lead to faster translations and reduced overhead. If CPUID 0x80000001, EDX bit 26 is set to 1, it signifies a 1GB page size is supported. A recent change in the coreboot (!NEED_SMALL_2MB_PAGE_TABLES) attempted to ensure that the default page table creation follows the larger (1GB) paging.

Calling into SoC APIs (blobs) in long mode

On x86 platforms, all SoC programming is limited to executing the silicon vendor provided proprietary blob model. In this blob model, SoC programming starts from a coreboot call into the respective blob entry point. The integration between coreboot and SoC binaries follows the API (Application Programming Interface) model. Historically, the communication between coreboot and SoC binaries (aka FSP) API follows de-facto standards of 32-bit mode of calling conventions.

For example, the table below shows the code snippet for calling into Intel FSP-S (Silicon Init API). The default behavior is to call FSP APIs in protected mode (if the PLATFORM_USES_FSP2_X86_32 configuration is set), even if coreboot is compiled in 64-bit mode. The primary reason for this behavior is that the FSP specification and blobs do not support native 64-bit operations.

The FSP 2.4 specification for Intel next generation processor (post Meteor Lake) supports transfer of the control between coreboot to FSP in long mode. This proof-of-concept works using Intel Meteor Lake based reference design “Rex64”, adapted to the FSP2.4 specification and 64-bit FSP blobs to be able to call into FSP APIs in direct long mode w/o thunking into 32-bit mode.

Transferring Control from coreboot to libpayload

The execution of each stage of coreboot is handled by arch_prog_run implementation found in the boot.c file. The transition to the next stage's entry point is determined by the operating mode of the current stage. For instance, programs running in 64-bit mode enter the next stage's entry point in long mode.

When coreboot decides to pass control to the payload, the above mentioned logic does not apply. The libpayload, a crucial layer in the boot process, bridges the communication gap between the boot firmware (coreboot) and the payload responsible for booting a specific operating system.

Libpayload plays a fundamental role during the boot process to the ChromeOS-specific payload (depthcharge) by making platform-centric information accessible to the payload. The control transfer between coreboot (ramstage) and libpayload always operates in protected mode. This protected mode layer guarantees that the libpayload's entrypoint implementation only supports 32-bit operations. Consequently, payload memory access and operations are limited to 32-bit addressing, restricting access to resources beyond 4GB.

In the next section, we will take a detailed look at the modifications made to the entry point of libpayload. This POC work (w/ below code change) allows coreboot to seamlessly switch between different modes (long and protected mode) based on the type of payload. This flexibility is important for validating different scenarios in the current and future scenarios (especially with the introduction of X86S).

Libpayload: Unified Entry Point for x86_32 and x86_64 mode

We have added x86_64 architecture specific CFlags, Linker Scripts, Tools chains etc. into the libpayload build system, similar to the approach followed previously in coreboot to add support for x86_32 architecture.

Along with other key changes made by CB:81968, the primary item that has been done in current implementation is refactoring the existing libpayload implementation for x86 architecture to keep both 32-bit and 64-bit support in parallel. Hence, added ARCH_X86_32 and ARCH_X86_64 Kconfig under the main ARCH_X86 architecture Kconfig. This effort allows all required architecture specific changes to be independent from each other.

As discussed in the previous section, the major limitation of the existing libpayload implementation was it only supported protected mode operations. Hence, the key feature being added by this work is to be able to support unified entry point implementation for 32-bit and 64-bit mode of operation. This new implementation would allow coreboot to directly jump into payload in long mode withoutthunking.

The heart of the implementation revolves around low level assembly changes as below:

1. head.S/head_64.S

Depending on the underlying ARCH, the platform selects either ARCH_X86_32 or ARCH_X86_64 Kconfig while building the libpayload. For example: head.S is getting compiled upon selecting ARCH_X86_32 Kconfig and head_64.S while building libpayload in 64-bit mode (w/ ARCH_X86_64).

The primary role head.S file is to fill the “cb_header_ptr” variable which is a pointer and holds the address of the coreboot table. Now the function calling convention differs between protected mode and long mode hence, the way head.S should fill the “cb_header_ptr” also differs.

Below table explains which libpayload entry point implementation to call into depending on the nature of operation.

Let's follow the difference in operation between those two specific implementations of libpayload entry point assembly file.

Table: Comparison of libpayload entry point across different ARCH_X86_?? architectures

2. pt.S

In long mode, libpayload/payload operation requires page table creation. There are two main reasons why the libpayload entry point should perform this step during the coreboot transition to libpayload:

1. Libpayload is built with ARCH_X86_64 Kconfig, while coreboot jumps into the payload entry point in protected mode. To switch back to long mode, libpayload must load the page table appropriate for the CPU architecture that supports large or small page tables.
2. coreboot jumps into libpayload in X86S mode, and the goal is to enable paging up to 512GB of range using a 1GB page table. This is crucial to avoid on-demand paging while depthcharge attempts to wipe-off or access memory >4GB in developer mode. Without this implementation, depthcharge would need to implement on-demand paging between virtual and physical memory when accessing memory >4GB. This could introduce latency and require redundant page table programming within depthcharge, which is something we want to avoid.

The page table creation in libpayload follows a similar implementation as in coreboot. However, the coreboot page table creation relies on static page table entries, resulting in a larger binary size and a potential security risk. The benefit of using a static page table in coreboot is that it requires minimal assembly programming and more importantly coreboot cannot have a single, link-time known location for the page table that has written into the memory and remains valid throughout the entire execution (due to CAR teardown) where else, In libpayload, we do not have this issue because we have DRAM available and no further stage transitions (until we hand off to the kernel). One more limitation of coreboot page table creation is that it maintains two separate implementations between small (2MB) and large (1GB) pages which increases the code maintenance.

While implementing the page table in libpayload, we had considered several factors as below: coreboot can eventually jump into the libpayload entrypoint either in protected or long mode depending upon the different modes of operations and we still should be able to create the page table being compatible with the operating mode.

• Need to keep only one implementation that can dynamically support either 2MB or 1GB page table creation looking at the CPUID 0x80000001/EDX bit 26.
• The page table initialization function `init_page_table` is designed to function in both 32-bit protected mode and 64-bit long mode.
• The page table implementation will only utilize assembly instructions that have the same binary representation in both 32-bit and 64-bit modes.
• We compile with `.code64` to ensure the assembler uses the correct 64-bit version of instructions (e.g., `inc`).
• Additionally, we carefully utilize the registers:
• use 64-bit register names (like `%rsi`) for register-indirect addressing to avoid incorrect address size prefixes.
• It is safe to use `%esi` with `mov` instructions, as the high 32 bits are zeroed in 64-bit mode.

3. exception_asm_64.S

Exception handling is the process of responding to unexpected events, such as hardware errors or invalid instructions, that disrupt the normal flow of a program. For example: Divide by zero, Page fault, Machine check exception, Invalid opcode etc. Refer to payloads/libpayload/include/x86/arch/exception.h for more details about exception types.The Interrupt Descriptor Table (IDT) plays a critical role in this process. The IDT is a data structure that stores the memory addresses of different types of exceptions and interrupts, including their corresponding handlers. The IDT is indexed by the vector number of the exception, which is a value between 0 and 255. The IDT entry for a given vector contains the memory address of the corresponding exception handler, as well as a value that is used to determine the error code that is passed to the exception handler.

When an exception or interrupt occurs, the processor consults the IDT to locate the appropriate handler, which is a piece of code designed to address the specific event. This handler then takes necessary actions, such as logging the error, stack dump, hooking the GDB (GNU Debugger) or gracefully terminating the program.

There are basic differences between the size of the Interrupt Descriptor Table for 32-bit and 64-bit. On 32-bit processors, the entries in the IDT are 8 bytes long and form a table like this:

On 64-bit processors, the entries in the IDT are 16 bytes long and form a table like this:

When filling the interrupt table entries for a 64-bit system, we must consider three offsets: offset_0 (bits 0-15), offset_1 (bits 16-31), and offset_2 (bits 32-63). However, in a 32-bit IDTR, we do not need to account for the offset_2 field.

Depthcharge: Supporting x86_64 mode

Similar to libpayload, the depthcharge code changes also introduces ARCH_X86_64 (64-bit) and ARCH_X86_32 (for 32-bit) to keep two supported architectures in parallel as part of the payload support. Files necessary for 64-bit compilation are now guarded by the `CONFIG_ARCH_X86_64` Kconfig option.

Besides adding 64-bit architecture specific Kconfig and allowing to compile 64-bit implementations (.C and .S files) for the x86_64 architecture, this patch also modifies compiler flags to meet the stack boundary alignment requirements for 64-bit architecture. For example:

• -mpreferred-stack-boundary=2 --> Aligns to 4-byte boundary (2^2 = 4) for x86_32 (32-bit)
• -mpreferred-stack-boundary=4 --> Aligns to 16-byte boundary (2^4 = 16) for x86_64 (64-bit)

Similarly, we have encountered an interesting problem related to “firmware-shell” operating in long mode. While executing any in-built command inside the firmware-shell resulted in the exception. After debugging, we have concluded that the linker symbols of firmware-shell pre-built commands are not aligned to the underlying architecture. For example: while compiling the firmware-shell in x86_64 mode, the variable should be aligned to 8-bytes/16-bytes compared to the alignment requirement for 32-bit mode is 4-bytes.

Finally, libpayload implements arch_phys_map() function that maps virtual memory to physical memory for 64-bit in a more sophisticated way compared to the 32-bit implementation of arch_phys_map(). The 32-bit mode of implementation offers on-demand virtual addresses to a physical address and optionally invalidates any old mapping.

Transferring Control from Depthcharge to ChromeOS

Modern Linux operating systems support two different entry points while bootloaders plan to jump into the kernel entry point aka legacy protected mode and modern long mode. Traditionally, payload designed for CrOS performs a jump into kernel mode in protected mode. The only argument that it passes to the kernel entry point is “boot_params”. Below table provides the code snippet which has been executed by kernel, while transiting into the kernel entry point in protected mode.

This newer implementation relies on transferring control to the kernel entry point in long mode (which is 512-bytes apart from the kernel legacy entry point).  The newer implementation relies on the kernel header data structure (e.g., an ELF header) that contains information about the kernel being loaded.

- xloadflags: A field within the hdr structure holding flags that describe the kernel's properties.

- XLF_KERNEL_64: A constant representing a flag indicating that the kernel is designed for 64-bit execution.

Eventually, the bootloader transfers the call into the kernel in long mode if “Kernel is 64-bit bootable” after looking into the XLF_KERNEL_64 flag is set within the xloadflags field.

Comparative Analysis

This POC work is not only helping to establish the fundamental block of x86_64 mode for Chrome AP firmware, which can be possibly used by Intel next generation SoC platform (aka Panther Lake). Therefore, it’s important to not only add foundational 64-bit code to create 64-bit binaries and be able to boot cleanly to the OS in x86_64 boot mode but also capture the comparative analysis between a platform in 32-bit mode vs the same platform supports 64-bit boot recipe as well.

We are able to create a 64-bit build for Rex (the reference platform based on Intel Meteor Lake generation) known as Rex64. We have completed the end-to-end measurement related to boot time and SPI size increase between Rex and Rex64 build.

Table: SPI Size Impact between Meteor Lake (32-bit) and Panther Lake (w/ N-1 aka Meteor Lake) due to 64-bit migration

Based on the above table, we are expecting to see ~0.5MB growth in the SPI flash due to migrating to x86_64 mode.

Unfortunately, we are unable to see any savings in the FSP and/or overall coreboot boot numbers w/ this planned toolchain migration. But at the same time, the boot numbers are in parity with the 32-bit boot numbers (aka no-regression).

Table: Boot Impact between 32-bit AP firmware and 64-bit AP firmware

Summary

The document outlines the process of updating the coreboot, FSP, libpayload and depthcharge codebases to support x86_64 (64-bit) mode in ChromeOS.

• Successfully enabled complete x86_64 boot flow using real hardware (Rex64).
• Highlighted the total changes across different boot phases to support x86_64 mode.
• It addresses the need for large page tables (1GB) to avoid on-demand paging and enable efficient memory wiping during developer mode.
• The page table creation in libpayload is designed to support both 32-bit protected mode and 64-bit long mode, using assembly instructions with the same binary representation in both modes.
• Depthcharge also introduces support for x86_64 and compiles 64-bit implementations for the x86_64 architecture.
• The document highlights the challenges faced in ensuring proper stack boundary alignment and handling firmware-shell commands in long mode.
• It concludes with a discussion on transferring control from depthcharge to ChromeOS, emphasizing the use of kernel header data structures to facilitate this transition.
  

In a groundbreaking move at the OCP Regional Summit, Supermicro and AMD have aligned with the Open Source Firmware Foundation (OSFF) to pivot the tech landscape toward open-source firmware, challenging decades of dependence on proprietary systems.

A Technological Revolution at OCP

The joint booth of the Open Source Firmware Foundation, AMD and Supermicro was a focal point at the summit, where they showcased proof of concept (POC) firmware solutions on two mainboards. With the open-source release of AMD openSIL (PoC for AMD CRB platform based on 4th Generation AMD EPYC™ server processors)  on June 14^th 2023, available on https://github.com/openSIL, Supermicro took on the challenge to perform a comprehensive evaluation of the new silicon initialization architecture and showcased their own server platform (Supermicro H13SSL-N) hosting 4^th Generation AMD EPYC™ server processors – demonstrating scalability and seamless integration of AMD openSIL across two host firmwares – (1) UEFI based Tianocore and, (2) coreboot/Linuxboot.

AMD's openSIL solution becomes available in 2026 as production-worthy open-source library for silicon initialization.

In addition to Open Host Firmware/BIOS, Supermicro has announced its intention to equip their systems with OpenBMC in the future.

Shifting Business Models

The traditional firmware model involves proprietary SDKs from BIOS vendors, which often leads to dependency and loss of control over the technology, which often leads to dependency and loss of control over the technology. The OSF model, by contrast, promotes collaboration with the OSF community and Independent BIOS Vendors (IBVs).

This model empowers companies to maintain control over their firmware and gain all the benefits of open-source innovation, supported by contracts and OSFF’s consultancy in navigating partner ecosystems.

Why It Matters

This strategic shift to open-source firmware offers a sustainable advantage by allowing companies to innovate more rapidly and securely. For industries ready to break boundaries, this model reduces risks associated with vendor lock-in, accelerates technological adaptability and offers a reduced time-to-market strategy for board bring-up of new systems.

Introducing Hancock Chang - OSF Ambassador for APAC

Hancock Chang steps up as the new OSFF Ambassador for the APAC region, ready to navigate the complexities of open-source adoption across continents.

Looking Ahead

Supermicro, AMD, and OSF are not just participants but pioneers in a movement setting a new standard in technology. As we watch this evolution unfold, the tech industry can expect more robust, customizable, and secure systems that align with modern demands and standards.

Stay connected to witness how this transformation will redefine the hardware industry, ushering in an era of transparency and collaborative innovation.

Author: Subrata Banik (subratabanik@google.com)                                         Collaboration with: Vincent Zimmer (vincent.zimmer@intel.com)

TL;DR: This document demonstrates a path forward that breaks the boundary of using FSP (Firmware Support Package) for firmware development, by defining a way to create your own custom FSP blob(s) that meets and aligns with your target product requirement.

A previous article written by me sometime last year named Refining Open-Source Firmware Support for the Intel Platform initiated the thought about bringing openness in firmware development even while working with closed-source silicon reference code. Although the previous article was more specific to detail the challenges seen with Intel SoC-based platform enablement using open source boot firmware aka coreboot, in practice the situation is not much different with other SoC vendors as well. To understand this problem in more detail, one should additionally refer to our last year OSFC talk named The “Thing” Around Your System Firmware.

The prior article had called for action to improve the overall platform-enabling environment that uses the open-source firmware development model with closed-source silicon reference blobs. Below is the list of the work items that came out from that discussion:

• Improve the platform enablement environment by balancing out the `binary blob model` (only include the *mandatory* closed source blobs which 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).
• Classify the FSP modules as `mandatory` and `good to have`. Allow dropping of `good to have` FSP modules to leverage more open source coreboot libraries/drivers for platform bring-up. This effort would help to reduce FSP boundaries and eventually optimize the SPI flash footprint.
• Optimizing the boot path would eventually help to achieve the ambitious goal of fast booting up the system firmware (in < 1 second boot time).

This document is to capture the progress being made to solve such ambitious challenges and provide flexibility to the boot firmware designer/developer aka users of the FSP to create their own FSP blobs (essentially could be different than what Intel “officially” uploaded into the FSP Github for each SoC product). Further sections of this document will provide more technical details about solving this challenge and how it would benefit the open-source community.

"One thing that can be clearly claimed already at the starting of this article is the big shortcoming of the current FSP delivery: the "one-binary-fits-all and eventually bloated" blob is now getting diminish with this approach where the consumers of the FSP binary have the freedom to create their own FSP binary that fits well in the open source firmware development model with coreboot."

The Planning                                

TL;DR: This section illustrates the design aspect of creating a custom FSP blob solution.

The “Alternative Path” section from the previous article discussed the few possibilities that the open-source firmware development approach needs to consider to optimize the usage of proprietary FSP modules over the coreboot libraries/drivers. This section illustrates the design philosophy being used to identify the mandatory FSP modules and how to eliminate them (as there might be more modules optional). This effort results in achieving the “Gain Control of Platform Initialization using native coreboot driver”  which was briefly described in the previously written document.

For ease of understanding let's describe the SoC in more firmware-friendly terms: the SoC design incorporates various IPs (Intellectual Property) to provide a great set of capabilities for the different platforms to choose from.

An IP can provide different hardware interfaces for example audio IP provides interfaces (like High-Definition Audio or HDA, Non-HDA a.k.a. I2S and Soundwire) for the target platform to eventually select and perform the configuration. The firmware being closest to the hardware is responsible for such interface selection, and the Intel SoC platform is no exception to that, where silicon reference code represents the SoC features. Figure 1.0 illustrates the relationship between SoC and silicon reference code.

The missing part in this whole evolution process is the understanding of the end-user platform requirement. Intel Silicon reference code enabling model only focuses on delivering a unified blob irrespective of the different OS-based platform needs. It’s very obvious that silicon vendors can't customize the silicon for every end-user product requirement but the minimum expectation is to allow configurable silicon reference code as per the platform need. The reference code, being designed to show all the capabilities of the new platform, usually does more than the default user actually needs (and of which a big portion is re-done in the firmware then) which in turn leads to an overloaded FSP piece after piece.

Based on this proposed design principle we shall provide the platform owners the opportunity to create an essential silicon reference code for the target platform. In fact, silicon reference code is not only meant to pass the board configuration parameter but also to remove unused or redundant IP initialization that resonates with the target board design.  Figure 1.1 illustrates the design principle that results in optimized silicon reference code based on the target platform.

To summarise, the work items based on the design phases are:

1. Enhance the coreboot/open source boot firmware capability so that it can be used as a replacement for any closed source FSP module (preferably where register sets are well explained as part of the datasheet and OEM programming section ask to implement the mandatory silicon programming in the boot firmware). For example, coreboot implemented CAR using a native driver/library and helped to make the FSP-T optional starting with FSP 2.0 specification.
2. In the open source development model, the highest preference is to execute the native code of the open source firmware instead of calling into closed source FSP modules but at the same time needs to have a way to eliminate the unused FSP modules from the SPI Flash. This effort will help to reduce the maintenance towards incorporating FSP fixes and additionally reduce the SPI flash space occupied by the FSP binary.
3. Need better tooling support at the FSP side to able to achieve the #2 above.

The Execution

TL;DR: This section illustrates the stepwise approach that leads into meeting the goal.

In practice, meeting the ambitious goal of designing the custom FSP binary won’t be possible without a detailed and gradual approach to it. These approaches might be interconnected or may appear independent but eventually required altogether to meet the desired goal (for the interest of the readers and easy understanding, the numeric ordering being used here to describe the stepwise approach).

Step 1: Enhancing the Open Source Firmware capability to suppress the need for Closed Source Firmware Blobs

Since the evolution of the Intel FSP, the main goal is to reduce the effort at the boot firmware side and use the FSP blobs as a drop-in solution to create final production AP firmware. It serves to meet the goal of platform enablement taking place with pre-validated SoC code.

Unfortunately, due to several reasons (for example FSP being bloated with more than required functionalities and lack of roles and responsibility) the entire FSP binary drop-in model has been unable to prove its inevitability. Over the period of time, the boot firmware has evolved and become more powerful in terms of taking more responsibility for the platform enablement without relying on the 3rd party blob solution.

Table 1.0 shows the comparison between coreboot and FSP. coreboot is one of the powerful boot firmware, which is capable of doing more than what FSP is actually expecting from the bootloader.

Table 1.0: Comparison between coreboot and FSP phases

For example, the primary responsibility of the FSP-Notify Phase APIs is to meet the SoC programming requirements (described in the Firmware Architecture Specification (FAS) Chapter 11, known as the `Security Guideline`). The intent of this section is to ensure all OEM designs are meeting the SoC vendor-provided security guideline requirements. This section of the FAS is purely meant for the OEM/ODM design to comply with using underlying boot firmware (in the case of ChromeOS, it applies to the coreboot) but FSP still prefers to perform those recommended chipset programming on its own which often at an execution time contradicts with the open source firmware flow.

The `Gain Control` proposal described in the previously written article helped to enhance the open-source firmware capabilities. Now with this approach, coreboot can eliminate the need to have multiple FSP modules due to redundant functionality. A total of 8 FSP modules from FSP-S Firmware Volume can be now dropped.
                                                                                                                                    Additionally, another work item that intended to replace the FSP modules for multi-processor initialization with open-source coreboot drivers has shown that yet two more FSP modules can become optional.

Another work item that currently is in progress is to adopt open source libgfxinit to replace FSP GFX PEIM performing Pre-Boot display Initialization.

In summary, out of roughly 13 PEIM modules the FSP-S consists of, 10 modules can be eliminated. This leads to a  reduction of ~80%.

Step 2: A way to eliminate the FSP modules using better tooling

The design principle of the silicon programming blob is to dynamically configure the IP interface based on the boot firmware provided inputs (as per the target board schematics). But the underrated part is the capability inside FSP to be able to statically decouple the `good to have FSP modules` from the `mandatory ones` at the source. Hence, in the present scenario, FSP doesn’t provide any option to eliminate the unused modules from the FSP blob and to reduce the SPI Flash usage. This limitation leads to keeping unused/dead binaries in the SPI Flash and eventually bearing the additional BoM cost.

The earlier section (as Step 1) illustrates the path to make a number of FSP modules possibly unused while integrating with open-source coreboot as boot firmware. But the actual benefit of boot time improvement or the SPI size reduction won’t have been achieved unless there is a scalable way to be able to drop those *claimed unused FSP modules* (without modifying the FSP source code). The fact is that most likely consumers of the FSP are directly consuming FSP binaries for their platform enablement. Hence, the most specific need is to be able to remove FSP Firmware Files (FFS) from the Firmware Volume using simple command line arguments (without modifying the source code).

Intel Firmware Module Management Tool (Intel® FMMT) is a utility that is capable of removal, addition, and replacement of FFS files in FV image binaries. This utility belongs to the open-source EDK2 github repository (link here https://github.com/tianocore/edk2/blob/a64b944942d828fe98e4843929662aad7f47bcca/BaseTools/Source/Python/FMMT/README.md).

Our target was to use the FMMT utility to be able to drop the unused modules from the given FSP blob. But the limitation of FMMT utility is that after removing an FFS file, the utility is unable to shrink the firmware volume space, which results in having the unused memory space being occupied by the firmware volume and eventually increasing the cost of the OEM devices (due to maintaining the higher SPI Flash footprint).

Good News is that with the bug being filled on the EDK2 to add the `shrink` support into the FMMT utility and the EDK2 community has responded positively by adding the shrinking support into the latest FMMT release (part of the EDK2 latest repository).

With the latest FMMT tool, we are now able to drop any “good to have” FSP file system (FFS) from the FD (Firmware Device) after following the few simple steps below:

1. Remove an FSP module FFS by providing the module GUID

2.  Shrink the FSP Firmware Volume using the newly added feature of FMMT.

Step 3: FSP Integration Guide to list out “good to have” FSP Modules

Since the origin of the FSP specification the entire FSP Firmware Device (FD) is considered mandatory and boot firmware is supposed to make calls into each and every entry point to let the FSP modules get a chance to execute and perform the silicon initialization. For the first time with FSP 2.0 specification, Intel has made FSP-T (aka for performing temporary memory initialization) an optional API. With this evolution, we are asking to even do more deep down inside each FSP firmware volume and classify modules inside each FSP Firmware Volume as “Mandatory” (aka Must Have, which shouldn’t be dropped as it might have an adverse effect on the platform) or “Good To Have” (aka Optional, which can be dropped as per the decision made by boot firmware).

Based on recent communication with the concerned team on the FSP side, the FSP team has now agreed to capture such a “Good To Have” module list per SoC inside the FSP integration guide. This would help the boot firmware aka consumer of the FSP, with the ability to actually decide what goes inside the FSP Firmware Volume aka FSP blob.

This Good To Have FSP module list can be used now along with the FMMT tool to be able to achieve our goal of creating our own custom FSP blob as per the target product requirements.                                        

The Outcome

The final section of this document shows the benefit of this approach in terms of the data and other improvements that this evolution brings to the users of open-source firmware (working along with the FSP-like binary PI (platform initialization) model).

1. Having the flexibility to choose Open Source Firmware over a closed-source binary model even for silicon initialization is great freedom from the product designer side. The users of the open-source firmware would be able to appreciate it much better.

2. This evolution would help to bring more adoption towards the Hybrid Work Model (a combination of closed and open source firmware used for platform enablement) as now the users of the closed source blob have the flexibility to chop down redundant/unrequired pieces.

3. OEM/ODM firmware engineers can create their own customized FSP binary which meets their product requirements.

4. Overcoming the shortcomings of the FSP model is often described as a “single FSP binary meeting all customer need problems and very much bloated”.

5. Optimise the boot time significantly with the limited FSP modules and lesser infrastructure overheads due to UEFI.

6. Able to meet lower SPI Flash which is a product distinguishing feature. Figure 1.2 illustrates the amount of reduction that one could achieve in the SPI Flash size with the flexibility of being able to drop unused FSP modules as per the target platform's need.

This proposal is readily available for all the latest Intel platforms starting with Alder Lake while working with coreboot in API mode.

Summary                                                              

Refining Open-Source Firmware Support for the Intel Platform had initiated the thought about defining a more open-source-friendly firmware development environment and with the “Gain Control '' proposal, the idea was to provide more flexibility while designing AP firmware using open-source boot firmware. This document has been drafted to capture the progress being made in the paths since the origination of this idea.

Additionally, so far we have only outlined the scope for improvement in FSP-S, which is the tiniest blob in the whole Open Source AP firmware FSP integration process. An actual saving in boot time and SPI Flash size could have been achieved if we were able to bring modularity in FSP-M design where platform owners are able to customize the MRC block as per their need, for example, most of Alder Lake based reference designs have shipped with LPDDR4x DIMM alone but the growth in ADL-MRC is multiple times compared to the previous generation (Tiger Lake SoC platform). We need to understand how much additional opportunity we have to be able to customize FSP-M blobs based on the final product memory type. Because remember our goal is to be able to customize the silicon reference code although we might not be able to customize the actual underlying silicon as per the target product.

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