The magic formula to all this, INTEL improvement, is everything contained in only one word: ARM64!
This is a very politically correct Civil Approach, don't you agree?! ;-) Best Regards. Zoran Stojsavljevic _______ On Tue, May 1, 2018 at 1:46 AM, David Hendricks <dhendri...@fb.com> wrote: > > You are just, with this desperate chit-chat, fueling INTEL's big EGO. > Please, continue to do so! INTEL, at the end of the day, will thank > you for that! :-)) > > Please keep things civil. Whatever you think of Intel and FSP, this is a > good opportunity to improve support for coreboot and others reading this > thread would like to see progress. > > > ------------------------------ > *From:* coreboot <coreboot-boun...@coreboot.org> on behalf of Zoran > Stojsavljevic <zoran.stojsavlje...@gmail.com> > *Sent:* Monday, April 30, 2018 9:58:33 AM > *To:* Nico Huber > *Cc:* Nathaniel L Desimone; Furquan Shaikh; Vincent Palatin; > coreboot@coreboot.org; Aaron Durbin; Stefan Reinauer; Martin Roth; ron > minnich; Shelley Chen; Julius Werner; Vadim Bendebury; Nick Vaccaro; Chris > Ching; Duncan Laurie; Subrata Banik > *Subject:* Re: [coreboot] Why do we have FSP-S > > Nico, Aaron, > > You are just, with this desperate chit-chat, fueling INTEL's big EGO. > Please, continue to do so! INTEL, at the end of the day, will thank > you for that! :-)) > > Zoran > _______ > > On Mon, Apr 30, 2018 at 4:48 PM, Nico Huber <nic...@gmx.de> wrote: > > Hello Aaron, > > > > thanks for your reply. > > > > On 30.04.2018 05:22, Aaron Durbin wrote: > >> On Sat, Apr 28, 2018 at 7:16 AM, 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's more of a bridge into coreboot's infrastructure, imo. > > > > It is. Anyway, maybe discuss that in another thread or on gerrit. > > > >> > >>> 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? > >> > >> Saying it's comparable to FSP-S is apt. The story is, like most > >> things, that it has specific things that are not architectural that > >> Intel thinks they need to be secret. Typical settings are related to > >> power management. When needing to be competitive in the laptop space > >> power is a big concern. Time to market may have been a thing too, but > >> I don't recall all the specifics. I'll get to it later in the > >> response, but there are temporal components to decisions and/or how > >> things change over time that are not within Google's control when > >> working on a particular platform. > >> > >>> > >>> 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. > >> > >> Based on my working history a lot of BWGs and/or specs are usually > >> wrong. They don't always contain the right information, but generally > >> contain quite a few things that are wrong where you second guess > >> everything in the docs. This should sound familiar: the 'reference > >> code' is the documentation. Most docs are not in sync with reality or > >> necessarily with how the silicon was actually designed. It's my belief > >> when there wasn't as much change from version to version, the > >> copy-pasting in docs just kinda worked. But as things have been > >> getting more complicated and incorporating more 'features' the > >> documentation has not been keeping up. > > > > Still these documents exist. And I deem them most valuable. I know there > > are flaws that can drive you crazy. But! they give a very good overview > > about what has to happen for silicon init. If published (for my sake w/o > > the secret ingredient bits) [2], they would be a great reference for > > discussions about the design of clean silicon-init code. We could har- > > ness the power of the community much better. > > > > It doesn't matter if somebody with access to the reference code has to > > fix some bugs later, once you have a decent maintainable code base. > > Neither would a blob that hides the secret ingredients if it only con- > > tains those (and no infrastructure / control flow; I think you, Aaron, > > and me share the same opinion on that). > > > >> > >>> > >>> > >>> 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. > >> > >> Purely business commentary: In order to develop a competitive laptop > >> on recent hardware one needs to include the features that consumers > >> expect. Intel also ties those features inside of FSP, but FSP has a > >> responsibility problem. It has traditionally attempted to do things it > >> should not. FSP should be a library of sorts, but it has things in > >> there it shouldn't. I mentioned some of this on the CL itself about > >> our usage of SkipMpInit. It trying to take over resources that it > >> shouldn't (among other things). > >> > >> What architectural changes are you referring to? And what is your > > > > You've got me there. I meant architectural things, not changes. Like > > that patch on gerrit. It doesn't seem to be Intel specific, I also > > can't find any soc_ reference in it. Yet, it's pushed to soc/intel/ > > and to me that looks like somebody wants to sneak it it (without big > > discussion / being thought through for all of coreboot). > > > >> definition of coreboot (I know see you wrote it below :)? early > >> firmware that will initialize everything in open source for Intel > >> platforms? I wish that were the case, but it's not something that is > >> allowed by Intel currently. I'd love to see more granularity in FSP, > >> but as noted in the CL commentary Intel hasn't been accepting of my > >> suggestions for making things more granular such that one could do the > >> only things that are deemed 'super secret' by Intel. The muddling of > >> responsibility and lack of granularity are the current result. > >> > >>> > >>> 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% > >> > >> Is this 20-30% coreboot/open source of the total? Were you counting > >> the edk2 stuff in there? A lot of the bloat in FSP comes from open > >> source edk2. > > > > You can't count EDK2 into it. Once it's built into FSP, it's not open- > > source any more (unless somebody proves what parts match a reproducible > > compilation of the open-source code). And for an open-source experience > > you'd still need means to adapt these EDK2 parts in the binary. It was > > just a wild guess based on my experience with Kaby Lake FSP (~500KiB), > > and guessed 200KiB coreboot. > > > >> > >>> 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. > >> > >> I agree with the overall assessment above. As currently > >> deployed/supported FSP is not really geared to people who don't have a > >> more intimate relationship with Intel. It's been brought up numerous > >> times, but it's Intel's decision to make a better product. > > > > Right, quality of their products is up to them. But isn't it our re- > > sponsibility to decide whether they can do that (15%) in the name of > > coreboot? > > > > Nico > > > > [2] Assuming that the BWGs don't contain the secret ingredients, even > > an NDA offer to all coreboot developer's (both hired ones and indi- > > viduals) could help. If Intel allows to derive open-source code from > > it (e.g. after a private review on gerrit) people would have less > > doubts about signing an NDA, IMHO. Just a random thought; anything I > > can come up with atm seems to be better than the status quo. > > > >>> > >>> So it's time for an FSP3.0 that was designed with the community, > >>> I'd say. > >>> > >>> Best regards, > >>> Nico > >>> > >>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__review. > coreboot.org_-23_c_coreboot_-2B_25634_&d=DwICAg&c= > 5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZme > YWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80& > s=_TJ-Ft6l7FJJmJ1VJ-GJJfSzItat6lK0i15bv5BNSl0&e= > > > > -- > > coreboot mailing list: coreboot@coreboot.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail. > coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c= > 5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZme > YWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s= > OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e= > > -- > coreboot mailing list: coreboot@coreboot.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail. > coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c= > 5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZme > YWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s= > OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e= >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot