Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36622 )
Change subject: drivers/fsp2_0: drop support for FSP-T ......................................................................
Patch Set 4:
(1 comment)
https://review.coreboot.org/c/coreboot/+/36622/4//COMMIT_MSG Commit Message:
https://review.coreboot.org/c/coreboot/+/36622/4//COMMIT_MSG@9 PS4, Line 9: FSP-T is only working in very few cases
You have data to back this up? […]
I think the big problem here is the way it is integrated. Both on coreboot and FSP sides. People often give up before they have figured out the correct Kconfig settings to make it work. Does that count as a case where it is (not) working?
So if Intel wants to maintain this feature as an upstream option, it would be much appreciated if the FSP binaries could be fixed or the integration guides updates (one thing that comes to mind is that the integration guides say you *are* allowed to pass a NULL-pointer for microcode updates, but if you do, FSP often crashes). It's pretty ridiculous, as most of the CPUs (or maybe all?) already apply the update via FIT. Also, with the complex rules of updating, especially in cases like SGX enablement, it's even harder to track if everything goes according to plan when FSP does updates too. So please fix all the binaries, nobody needs microcode updates performed by error-prone FSP!
If really necessary, because Intel can't fix their own programs, we could also fix the microcode-update pointer on the coreboot side, see how it is done for FIT, for instance. No need for a Kconfig mess!
That this pops up every few months is a clear sign that Intel doesn't take the integration serious. So why should the coreboot community?