On Sat, 2013-12-07 at 14:38 -0800, ron minnich wrote:
FSP is a delivery vehicle for binary code. It is designed to be a binary blob with well-defined entry points.
So, what you're saying is "the best option for delivering the binary blob is to be delivered as not a binary blob."
At that point my head explodes as I try to parse the contradiction. :-)
Some things have to be binary blobs. Because the world will apparently end if we tell someone how to initialise a memory controller.
But the *infrastructure* that ties those binary blobs together, that knows how to invoke the individual PEI modules, doesn't have to be binary too.
That part could reasonably be done in source code (hell, most of it already exists in EDKII), and could give FSP users a lot more flexibility and debugability.
It would also help to combat the trend of including stuff in the FSP that *doesn't* belong there because we *can* have open code that does it (such as graphics setup).
On 12/07/2013 06:05 PM, David Woodhouse wrote:
Some things have to be binary blobs. Because the world will apparently end if we tell someone how to initialise a memory controller.
But the *infrastructure* that ties those binary blobs together, that knows how to invoke the individual PEI modules, doesn't have to be binary too.
That part could reasonably be done in source code (hell, most of it already exists in EDKII), and could give FSP users a lot more flexibility and debugability.
It would also help to combat the trend of including stuff in the FSP that *doesn't* belong there because we *can* have open code that does it (such as graphics setup).
Your rant is most inappropriate in this thread. An Intel engineer wants to help us with FSP. Instead of trying to sort things out, you just rant. Why is it so difficult to agree to saying "May we please have the source code?"
Zoran, may we please have the source code under a GPLv2 compatible license? I think this would be the best way forward for integrating FSP with coreboot.
Alex
Hello Alex,
Here are my thoughts (on things I know so far) from working with INTEL, and how things are looking so far. I'll try to use strategy: "divide and conquer", since there are more than one complex area touched here.
Before I start with my explanation, I'll give some comparison, so you'll get the big picture. INTEL is very big ship taking course set by CEO B.K. and BOD. Ship which is 50x bigger that Titanic. So, it is not easy to stir such a ship and change immediately its course. Me and several people INTEL Inside are trying to align INTEL Embedded with Open Source, but it is not an easy task, whatsoever.
[1A] As for The Present, it is impossible to work out IVB FSP source code out to the Coreboot, or any Open Source project (such as the example: EDKII). And David (Woodhouse) knows it even better than me. ;-) I am sorry if I disappoint you, Alex, but these are higher forces in place. Still, we are working on that. Time still did not come for that. [1B] Nonetheless, there is opportunity coming Coreboot ways. There will be CPU released, which supposed to have from reset vector all Open Source Code. And, YES, you push me to start thinking how to accommodate this one as the complete package into Coreboot, with source code FSP. Interesting experiment to be done. I'll work toward this one setting it as project in my background. As ice-breaker for what you have proposed (under GPL license).
[2] Management Engine. This is very farfetched. Likely, as I understand, source code for ME will be NEVER released to *any* public site, since this code has specifics... It is AMT and similar function driven, but not only. It has its own crucial functionality (Integrated Clock Controller function, for example), and so far it must be taken as is. The adopted (minimized) ME for IVB is included into IVB FSP package (ME in SPI0, FSP + coreboot + payload in SPI1).
[3] Very soon another packages will follow (HSW FSP, BYT FSP). With the same type of license. Considering embedding the whole IVB FSP package as is (downloaded), I got green light that as such it could be taken and placed inside Coreboot. Email says: "There is nothing that prohibits that in the license. INTEL purposely build the FSP with a self-extracting utility that includes the license acceptance so that FSP can be redistributed as-is. However, the Coreboot maintainers like to try to keep what they distribute free from any proprietary code. Intel would be fine with this, so it is really more of a question to the Coreboot community as to whether or not they will allow it."
I hope I answered all the questions as best I could. Sorry, at The Present time my powers are very limited, which does not preclude development for The Future.
Please, stay tuned! Zoran _______ Most of The Time you should be “intel inside” to be capable to think “out of the box”.
-----Original Message----- From: mrnuke [mailto:mr.nuke.me@gmail.com] Sent: Sunday, December 08, 2013 2:59 AM To: David Woodhouse; ron minnich Cc: Stojsavljevic, Zoran; coreboot@coreboot.org Subject: Re: [coreboot] INTEL FSP support coreboot-v4.0-4966
On 12/07/2013 06:05 PM, David Woodhouse wrote:
Some things have to be binary blobs. Because the world will apparently end if we tell someone how to initialise a memory controller.
But the *infrastructure* that ties those binary blobs together, that knows how to invoke the individual PEI modules, doesn't have to be binary too.
That part could reasonably be done in source code (hell, most of it already exists in EDKII), and could give FSP users a lot more flexibility and debugability.
It would also help to combat the trend of including stuff in the FSP that *doesn't* belong there because we *can* have open code that does it (such as graphics setup).
Your rant is most inappropriate in this thread. An Intel engineer wants to help us with FSP. Instead of trying to sort things out, you just rant. Why is it so difficult to agree to saying "May we please have the source code?"
Zoran, may we please have the source code under a GPLv2 compatible license? I think this would be the best way forward for integrating FSP with coreboot.
Alex Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
-
David Woodhouse -
mrnuke -
Stojsavljevic, Zoran