Nico (Huber), > 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! ;-) Peace, Zoran _______ On Sat, Apr 28, 2018 at 3:16 PM, Nico Huber <nic...@gmx.de> wrote: > 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 > > [1] https://review.coreboot.org/#/c/coreboot/+/25634/ > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot