Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36328 )
Change subject: [RFC] Documentation/fsp: Discuss FSP-S issues ......................................................................
Patch Set 4:
(4 comments)
Let me translate this... you say one should stop discussing a topic just because the opponent does not want to discuss it?
No, I am saying that it's practically impossible for somebody from Intel to address legal concerns in a public forum. It has to do with typical corporate processes for handling these types of things, not whether or not they want to.
OTOH there are reputable companies in the community such as Google, Siemens, and others who have presumably done their due diligence and are obviously fine with shipping hardware with coreboot and FSP. The concerns mentioned in the earlier versions of this patch do not reflect those of the community as a whole, which is another reason they should not be in Documentation/.
AFAIK, it's only cros devices that ship the more entangled FSP2.1. And it's not even Google selling them... I don't think every individual company tracks changes in the ABI, so there is potentially a lack of awareness on that end too.
The topic is delicate indeed. However, I didn't bring it up here because I want any (legal) questions answered. Rather, if we don't want to trial ABIs against legal departments, the responsible engineers need to be aware that licenses like the GPL may be involved and take that into account. Maybe I'll add something in a follow up... The message it should carry is that
an ABI design that may raise legal concerns increases (FSP) costs further.
All the discussions about it we had on Gerrit are some $k alone. ;)
https://review.coreboot.org/c/coreboot/+/36328/4/Documentation/fsp/fsp-s_dis... File Documentation/fsp/fsp-s_discussion.md:
https://review.coreboot.org/c/coreboot/+/36328/4/Documentation/fsp/fsp-s_dis... PS4, Line 56: several FSP bugs, but they hardly ever got addressed. This means
I've also been told that validating a new FSP binary is a very time-consuming and expensive process […]
I think it's not that bad anymore. If one looks at their GitHub activity, there are a lot of updates (nowadays). But I guess you need to be a bigger customer or IBV (with direct contacts) to get issues addressed.
https://review.coreboot.org/c/coreboot/+/36328/4/Documentation/fsp/fsp-s_dis... PS4, Line 99: This shows that no matter the many options that are implemented in : FSP-S
… no matter *how* the many options are implemented …
That wouldn't be what I meant... rather "no matter how many options are offered"...
https://review.coreboot.org/c/coreboot/+/36328/4/Documentation/fsp/fsp-s_dis... PS4, Line 182: in the absence of such a firmware-development utopia,
Maybe remove to not take away the result before the actual discussion inside Intel? Maybe find words […]
The idea was to make it clear that we don't expect them to go fully open-source. Of course, I would hope for it. But if you ask them for that you can be sure they'll ignore you.
First step is to make them open up what they don't care about... which, if you take FSP as a whole, is currently mixed with things they care about. If they make that step, we can still ask for more. Or prove to them, again, that open-source raminit is no doomsday device.
https://review.coreboot.org/c/coreboot/+/36328/4/Documentation/fsp/fsp-s_dis... PS4, Line 185: And due to its complex nature, it is no surprise : if memory-controller initialization is kept secret.
Why?
(foreign) IP, for instance
Ofc, it's bullshit when somebody tells you that a single specific bit can't be set in open-source code because of IP. But in case of memory- controllers, there is really a lot involved that the silicon vendors don't want to share or are not allowed to (don't own).