Hello coreboot folks, hello Intel and Google coreboot developers,
back on Tuesday, some of us discovered a commit on gerrit [1] that implements (another) foreign interface inside coreboot. Discussing it didn't go well and I kind of bursted. I feel sorry about that now (especially because I got too personal).
One of the causes for this clash definitely was that things apparently were discussed before but not with coreboot (i.e. this coreboot mailing list). So I'll try to take the general discussion here, but I've to start some years back, where you lost me.
Some questions (that I believe have to be answered) right away. I'll argue about why later, so these won't get lost (in an already too long email):
TLDR; For Google: You kind of introduced blobs in coreboot (with Sandy Bridge) which was a simple jump-in-jump-out thing and kind of accepted. The argument was that the things it does aren't documented by Intel anymore, AFAIR. But with Broadwell suddenly another blob emerged (in ramstage) some `refcode.elf` AIUI. It turned out, later, that this blob (also) does things that were open source for Haswell (and would work verbatim on Broadwell). It seems to play a role comparable to FSP-S. o What's the story behind this blob? o Why was it introduced? o Was there more than IP concerns? Time to market pressure maybe?
For Intel: It's hard for me to understand what parts of your silicon init you can open-source and what parts you can't. I know your BIOS Writer's Guides (BWG) / BIOS Spec, and many things therein are often published by you or Google. Please tell us. o Are the things that you can *not* open-source documented at all? o if so, in these BWG documents? o Or is everything in these documents generally publishable (with some NDA clearance, ofc)? o For a configuration of FSP-S that just runs the bare minimum to boot (e.g. skips questionable add-ons like TXT, SGX), is there anything not publishable? o Can anything be done to get more documentation published? e.g. for things that are done in open source (or were done in the past) but are not publicly documented.
So why ask? The original introduction of blobs in coreboot in general happened with the argument that the things it does (e.g. memory init) are not documented anymore by Intel. This is a valid argument because the lack of documentation makes it harder to write clean code. I also believe it's true (that no documentation exists) because I've seen a previous BWG that already referred a lot to the reference code.
But, AFAIR, the introduction of blobs in coreboot's *ramstage* was never discussed. The blobs I've seen so far all did things that were already open source for earlier platforms. Plus they are twisting coreboot into something that isn't coreboot anymore. Architectural changes happen in chipset specific code instead of moving coreboot as a whole (after an open discussion). Also, most of the positive aspects about coreboot are lost.
Of course, it's hard to argument about whether something is coreboot or not without a clear definition of coreboot. But let me get this one straight: It's definitely not coreboot just because it happens on coreboot.org.
I'll try to sum up what is coreboot to me, and compare that to a current coreboot with FSP. coreboot
1. is free software 2. is open source 3. is auditable 4. is lean (less code means less bugs) 5. gives control to the user
but with FSP:
1. You can not fully adapt it, you can't even just download it (often have to steal the FSP binary): 0% 2. Comparing the sizes of open-source parts and FSP, maybe 30%. But if you don't count open-source code that is only needed to handle blob issues, rather 20% 3. If you are backed by a huge company or government, you can audit coreboot+FSP (I guess), if not than not, 50%? But given that the size of the whole package is about 10 times the size of a clean implementation, you have to audit 10 times more code (of much poorer quality), thus at most 5% 4. 0% (see above) 5. That seems to be my only point that Intel cares about. Still, coreboot compatible binaries are often not available. You need very weird workarounds if the one setting you miss is not there: 50%
Numbers are just educated guesses, but might match reality. If you average these, you'll see that coreboot+FSP is only 15% of (my) coreboot. I would estimate that you can get up to 20% with the design of FPS2.0.
So it's time for an FSP3.0 that was designed with the community, I'd say.
Best regards, Nico