FSP-I is a blob that initializes SMM and installs a runtime handler and then locks down SMM.
Just as a reminder: SMM is a special CPU mode that is entered via a interrupt (SMI) and is completely invisible to the OS. This used to be for power management but now it's often used to avoid writing proper OS drivers e.g. for RAS features.
Extract from section 8:
"If an FSP binary provides the FSP-I component, usage of FSP-I can be mandatory for certain processors and chipsets. The Integration Guide will document if FSP-I is mandatory for specific FSP implementations."
By design coreboot has as little runtime as possible.
We also dislike blobs, as it's an open source project.
Having closed source code inside a CPU mode that is completely opaque to the OS is going against those 2 wishes at the same time + there already exists open source code for setting SMM.
I'd like to start a discussion about not allowing blob runtimes in coreboot before people start writing code to integrate FSP-I. We have had discussions about which blobs are ok and not in the past, with no clear outcome. We don't have a clear policy about what a blob can or cannot do (it only has to be redistributable iirc?), but even without having a clear line of what is ok or not, a runtime blob running on the main CPU is definitely crossing it in my opinion.
What are your thoughts?
Do we take a stance against FSP-I integration in coreboot?
Are there precedents where blobs runtimes are installed on the main CPU, that I don't know of which could justify FSP-I?
P.S.2 Not all about FSP2.4 is bad. I like that adds the possibility for 64bit support, though it uses the MSVC ABI instead of SYSV :-( .
Arthur