How about we set up some guidelines how to proceed when adding support for a new platform that requires any blobs? My vague idea is as follows: Before the very first commit for such a new platform can be merged, a set of predefined, blob related questions (to be discussed) should be answered.
Some ideas for questions from the top of my head:
o Why a blob instead of coreboot integration? (What surprised me in the past: Sometimes it's just that the blob was already written (e.g. graphics init on Intel). And people preferred already written proprietary code over open-source contribution.)
o What kind of blob is it? e.g. - resides in the same storage medium as coreboot - is loaded but not run by coreboot + is run by another processor not used by coreboot + is run later on the same processor as coreboot - is loaded and run by coreboot (questions below mostly apply to this case)
o Was the blob designed for coreboot? or is it merely compatible enough?
o Was the blob designed based on input from - the coreboot community? - any of its members?
o Is it publicly documented what the blob does?
o Is NDA documentation available?
o Does the silicon vendor allow an open-source implementation based on the available documentation?
o Does the silicon vendor allow an open-source implementation based on their undisclosed reference code?
o Does the silicon vendor allow an alternative blob implementation based on the available documentation / reference code? (Rationale: Silicon vendors often dictate the interface of their blobs, what their blobs do (sometimes much much much more than necessary) etc. The effort to integrate the original blobs might outweigh the effort to write new ones.)
o Would the silicon vendor be interested to work together with the community on an open, coreboot-native implementation?
o Would the silicon vendor be interested to work together with members of the community under NDA on an alternative blob implementation?
o Is the blob's interface (completely) documented? (IMO, something we should demand, blob documentation (e.g. FSP) is often much too thin for long-term maintenance.)
o Is the blob's documentation sufficient to integrate it into coreboot without further references (e.g. looking into the blob's source code)?
o Will there be public binary releases of the blob?
- Will there be updates to the binary releases if any issues occur with coreboot?
- Will there be security updates? If so, for how long?
- Will it be allowed to fix bugs in the binaries if the silicon vendor doesn't do it?
- Will it be allowed to fix integration/maintenance issues in the binaries if the silicon vendor doesn't do it?
I guess that's enough to get the discussion started. I hope there will be many more questions, and that those will be answered in the future :)
Nico