Am 2014-05-07 23:57, schrieb Jiming Sun:
If open source community is meant for collaboration and innovation, do you think there can be silicon specific code that only a few people can understand, therefore whether it is open or not really does not matter?
It matters in that it can be checked. It also matters that fixes are possible: I had to binary patch an Intel bug in Google's MRC binary, it would have been easier to find in source code (in particular because I've been told that the comment above the point I fixed actually said the right thing. I had no comments in the binary to work with). In an open source process (with feedback loop) I could even have pushed that fix your way. As-is I have no idea who's still affected by that bug.
Also, this argument only works because the data sheets are locked down. I still have some vain hope that this will change at some point, too. :-) The PC space thrived because/despite (pick your favorite) open data sheets, and the embedded space still does (see also: Quark).
One more advantage open source brings is that it provides standardized licensing (and this issue is more important to commercial integrators that want to sell their work than to private developers): Mainstream open source licenses are well-known, battle-tested in courts around the world, and companies tend to have (simple) policies on using code under open source terms in products.
I was recently told that the FSP license is different from the click-through license on www.intel.com/fsp (the one shown when trying to download the files).
So here's how I understand the FSP license situation: There's the click-through license on the web site, the FSP license (shown by the self-extracting archive), the intersection of both that actually applies to me when using FSP, and the application of these resulting terms in jurisdictions world-wide. And every single-letter change to the license in future releases restarts the license evaluation process from scratch.
This may not be a problem for Intel - it's huge so these things don't matter much, but please keep in mind that Intel's legal department alone is probably larger than many of the companies that integrate Intel's chips.
So custom licensing is certainly a great scheme to keep lots of lawyers employed. But it's not so great if you're just trying to get chipset initialization code (and by extension: chipsets) into the hands of integrators.
ARM has a Boot ROM inside their SOC, should the code inside the Boot ROM be open? or does it matter?
Those tend to be small, in the 4-8kb range, and focused on a single purpose: getting the next stage into iRAM. For the Allwinner CPU we support, one developer in our community checked that the signed binary-only part (that we can't replace) is harmless.
This isn't so easy with a multi-100kb binary affecting pretty much everything across multiple chips.
I know this view point is not going to be popular, but Intel is trying hard to open as much code as possible (tianocore.org [1], Linux drivers, and Quark firmware are a few examples; I am sure more will come in the future).
I'm certainly looking forward to that!
We believe encapsulating basic silicon code is a good idea regardless if it is completely open.
It sure is. But it's even better when it's open :-)
Regards, Patrick
On Wed, May 7, 2014 at 11:30 PM, Patrick Georgi patrick@georgi-clan.dewrote:
One more advantage open source brings is that it provides standardized licensing (and this issue is more important to commercial integrators that want to sell their work than to private developers): Mainstream open source licenses are well-known, battle-tested in courts around the world, and companies tend to have (simple) policies on using code under open source terms in products.
I was recently told that the FSP license is different from the click-through license on www.intel.com/fsp (the one shown when trying to download the files).
So here's how I understand the FSP license situation: There's the click-through license on the web site, the FSP license (shown by the self-extracting archive), the intersection of both that actually applies to me when using FSP, and the application of these resulting terms in jurisdictions world-wide. And every single-letter change to the license in future releases restarts the license evaluation process from scratch.
This may not be a problem for Intel - it's huge so these things don't matter much, but please keep in mind that Intel's legal department alone is probably larger than many of the companies that integrate Intel's chips.
So custom licensing is certainly a great scheme to keep lots of lawyers employed. But it's not so great if you're just trying to get chipset initialization code (and by extension: chipsets) into the hands of integrators.
Yes - Simplicity, harmonization, and freedom in licensing is huge deal and impacts processes at many levels. I personally rank this as equal to the collaboration aspect of FOSS licensing. The need to "deal with partners" rather than to actually "work with partners" is both frustrating and a colossal waste of time and resources for both sides.
ARM has a Boot ROM inside their SOC, should the code inside the Boot
ROM be open? or does it matter?
Those tend to be small, in the 4-8kb range, and focused on a single purpose: getting the next stage into iRAM. For the Allwinner CPU we support, one developer in our community checked that the signed binary-only part (that we can't replace) is harmless.
This isn't so easy with a multi-100kb binary affecting pretty much everything across multiple chips.
I know this view point is not going to be popular, but Intel is trying
hard to open as much code as possible (tianocore.org [1], Linux
drivers, and Quark firmware are a few examples; I am sure more will come in the future).
I'm certainly looking forward to that!
They have been getting better as Jiming points out. But going back to the process, how would one actually use this for a third-party project such as coreboot? Once everything is up on tianocore.org, can the necessary components be copied over to coreboot.org so that a user can build a working image by selecting the right options and running "make"? Or does the user need to visit >= external site, download something, pick apart bits and pieces that are needed, and plop them into a coreboot image built separately? How could the latter process even work if one were to attempt to automate this for large-scale development? You get the idea.
-
David Hendricks -
Patrick Georgi