Re: Doubt in MinPlatform QemuOpenBoardPkg task

["Nate DeSimone" <nathaniel.l.desimone@intel.com>]

Hi Kaaira,

Great questions! So I’ll start out describing what the FSP is and why we built it. The FSP (Firmware Support Package) is a mechanism Intel developed to distribute chipset initialization code that must be run during bootup in a binary format. Historically there were multiple different BIOS implementations from different IBVs (Independent BIOS Vendor, companies like AMI, Phoenix, Insyde, etc.) and they had some fundamental incompatibilities that made it impossible to run C code provided as a binary. For example, different methods for initialization of the stack. Due to this, historically we only provided chipset initialization in source code format under NDA. However, this strategy limited the companies that were capable of building BIOS implementations to those that could obtain NDAs, which eventually became too limiting.

So, we needed a binary executable format that would work with many different BIOS implementations while still allowing the chipset initialization code to be written in a higher level language than assembly. The first attempt at this was UEFI actually, which created a very generic binary format that would work not only for chipset initialization, but other multi-vendor compatibility concerns like expansion cards and operating systems. UEFI has become very successful in the general purpose computing (aka PC) industry, and it is widely used today to make PCIe add-in cards (graphics cards for example) work in PC systems from different vendors. It is also very successful at making PCs capable of booting an operating system from any software vendor.

But UEFI turned out to be overkill for embedded/Internet of Things designs. Most embedded designs generally only boot one OS (VxWorks, QNX, heavily customized Linux, etc.) and don’t support expansion cards. Moreover, they are usually designed by companies with small engineering departments that had difficulty working with UEFI due to its large and rich feature set. So we went back and built another mechanism for distributing chipset initialization code in a binary executable format, and kept it focused to just that use case this time. The result of that was FSP. Initially, FSP was only used by embedded customers, but its usage has grown over the years and now a lot of PCs use it for chipset initialization as well. The earlier versions of the FSP specifications (v1.0-v2.0) were designed primarily for use with non-UEFI firmware implementations. For example https://slimbootloader.github.io/, which is a sister project to TianoCore developed by Intel’s Internet of Things department. Due to the increasing interest in using the FSP on PCs, in the FSP v2.1 specification we made the FSP operate in two different “modes”: API Mode and Dispatch Mode. API mode is backwards compatible with the FSP v2.0 specification and is intended for use on non-UEFI firmware implementations. Dispatch mode is conversely designed to for use with UEFI firmware implementations and works very differently.

So, the basic idea is that now that the FSP is widely used on PCs, it makes sense to include an FSP in the new QemuOpenBoardPkg so that it closely mirrors what a real UEFI firmware/BIOS implementation looks like. The Internet of Things department at Intel (the same guys who wrote Slim Bootloader) has created a dummy FSP for QEmu and posted it here: https://github.com/universalpayload/fspsdk/tree/qemu_fsp_x64 Since it is just a dummy FSP, they released it open source instead of binary only like most FSPs. However, since Slim Bootloader does not support dispatch mode they only implemented API mode. Hence that QEmu FSP only goes up to the FSP v2.0 specification. That is where “upgrade QEmu FSP to v2.2” come in. Basically the proposal is to implement dispatch mode in the QEmu FSP and then integrate it into QemuOpenBoardPkg, so that way we have an open source emulated example that is much closer to what the real UEFI implementation on modern PCs actually looks like.

Yes there are been several MinPlatform Architecture platform implementations available right now:

CometlakeOpenBoardPkg: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/CometlakeOpenBoardPkg
KabylakeOpenBoardPkg: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/KabylakeOpenBoardPkg
TigerlakeOpenBoardPkg: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/TigerlakeOpenBoardPkg
WhiskeylakeOpenBoardPkg: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/WhiskeylakeOpenBoardPkg

Out of all of them, I'd say that KabylakeOpenBoardPkg is the best example.

Hope that helps. Let me know if you have more questions!

Best Regards,
Nate

From: Kaaira Gupta <kaaira7319@gmail.com> 
Sent: Friday, April 9, 2021 3:14 PM
To: discuss@edk2.groups.io; Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Subject: Doubt in MinPlatform QemuOpenBoardPkg task

The second part of this task talks about fsp sdk and its use for testing FSP integration. I wanted to confirm if I understood this part correctly.
From what I understand, we will have to work on this FSPSDK such that it can generate FSP binaries with the OpenBoardPkg we create which can be used for silicon initialisation. Is this correct?

Another question,
Has there been any similar adaptation work to MinPlatform Architecture earlier for any other Processor/SoC so that I can get some pointers from those patches about the workflow? This would help me define a timeline for the proposal and also make the work a lot clearer.

Thanks,
Kaaira