[coreboot] Why do we have FSP-S
zoran.stojsavljevic at gmail.com
Sat Apr 28 16:04:16 CEST 2018
> So it's time for an FSP3.0 that was designed with the community, I'd say.
You talk (in this email, at least) too much. :-))
I wish you a Good Luck. You'll need it (all the luck in this and
others' Worlds). And much more than that! Even Captain Jean-Luc Picard
(Star Trek Next Generation) and as extras Kathryn Janeway (Star Trek
Voyager) could not help you altogether/jointly with your requests! ;-)
On Sat, Apr 28, 2018 at 3:16 PM, Nico Huber <nico.h at gmx.de> wrote:
> Hello coreboot folks, hello Intel and Google coreboot developers,
> back on Tuesday, some of us discovered a commit on gerrit  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
> 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
> 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
> 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):
> 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
> 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
> 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:
> 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,
>  https://review.coreboot.org/#/c/coreboot/+/25634/
> coreboot mailing list: coreboot at coreboot.org
More information about the coreboot