Sorry, you need to enable JavaScript to visit this website.

Building the Platform Firmware Solution

vzimmer's picture

In earlier posts I've talked about the Intel Firmware Support Package (FSP). This is one ingredient to enable an open or closed work-flow for firmware development. But an FSP binary is not sufficient for building a complete platform solution. To that end, platform code needs to be combined with the FSP, along with the operating system boot loader environment.

There are a plurality of solutions for building a platform for Intel Architecture and other CPU's. OpenPower https://github.com/open-power, for example, splits the initialization into three phases - Hostboot, Skiboot, and Petitboot. The first does low-level memory initialization in a similar fashion to UEFI PI PEI phase (and/or Intel FSP). This is followed by Skiboot, which does the platform initialization. And finally, Petitboot exposes the OS loader environment. The design is such that Hostboot would be scoped to the system on a chip (SOC), so provided by the CPU manufacturer. Skiboot, on the other hand, encompasses platform initialization and would comprehend the unique details of the Original Equipment Manufacturer's (OEM's) design. Once memory (Hostboot) and the platofrm (Skiboot) have been initialized, then the OS loader environment is invoked. In the case of OpenPower, there is the Linux-derived Petitboot for booting Linux. The latter component is the one that Andrei has replaced with UEFI EDKII https://firmwaresecurity.com/2016/02/24/interview-with-andrei-warkentin-openpower-uefi-porter/, for example.

For the Intel Architecture world, there is UEFI PI and coreboot. UEFI PEI, and the encapsulation of the same in Intel FSP, does memory initialization. Then the late PEI and early UEFI PI early DXE phase does the platform initialization. After the platform initialization is complete, the EndOfDXE event is signalled and the machine becomes a "UEFI-compliant'" machine. At this point the large number of class and device drivers for block, network, and console devices can be loaded. This 'UEFI environment' between EndOfDxe and the invocation of ExitBootServices by the OS loader has been called the "Transient System Load" (TSL), as seen in Figure 9 of https://www.cs.berkeley.edu/~kubitron/courses/cs194-24-S14/hand-outs/SF09_EFIS001_UEFI_PI_TCG_White_Paper.pdf.  The device and class drivers loaded in this phase are largely platform independent. Both the PEI and DXE cores, along with these generic items, can be found in the MdeModulePkg https://github.com/tianocore/edk2/tree/master/MdeModulePkg

The coreboot taxonomy is romstage for early memory initialization (this is where Intel FSP can be combined), ramstage for platform initialization, and then the payload for the OS boot environment. The latter can be seabios for PC/AT interface, https://github.com/tianocore/edk2/tree/master/CorebootPayloadPkgfor a UEFI environment, U-Boot, an embedded Linux kernel or RTOS, etc.

And even U-Boot has various flavors, including doing full CPU + platform initialization, just platform initialization, and/or some mixture of the former two along with providing the OS boot loader environment.

So for platform work in coreboot, a developer spends time in porting a little bit or romstage and then mostly working in ramstage. In UEFI PI, the platform developer and/or porter does a little bit of PEI and a collection of DXE platform drivers, including some architectural protocol drivers, SMM drivers, etc. And it is this platform creation and porting process where we want to provide simplicity and consistency. To that end, we have recently published a document https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Secure_SMM_Communication.pdfon how to curate a set of SMM drivers to support the Windows SMM Security Mitigations Table (WSMT). And beyond just creating the WSMT, the rest of the platform work-flow and advocacy for platform consistency using EDKII is described inhttps://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Open_Source_IA_Firmware_Platform_Design_Guide_in_EFI_Developer_Kit_II.pdf.  

I hear a lot of feedback on firmware from both the industry and colleagues. One recent feedback included "No one reads white papers." I don't believe that is the case. I observe that 'some people' read them, especially technologists who want to explore the intent behind design decisions. To that end, I welcome these 'some people' to dig into the last 2 citations and continue their exploration. 

Cheers