Binary blobs in the source tree (was: Re: New patch to review for coreboot: e4fc528 Add the memory reference code binary for sandybridge chipsets)
Am 15.04.2012 04:57 schrieb ron minnich:
On Sat, Apr 14, 2012 at 3:12 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
I hope this is not going into the main repository, but into some separate repository instead. Right now we can tell people that all code in our official git repository is GPL-compatible, and I'd like to keep it that way.
We maintain GPL V2 compatibility as this is a blob that is placed into cbfs. There is no linking.
It's a slippery slope, though. We call the blob from coreboot and expect it to return to coreboot (whether the return is a JMP/RET/... doesn't matter). Unless I'm mistaken, we've never done that before, and if we do this now in the official tree, it will be very hard to refuse merging chipset init blobs (well, pretty much any init blob), and for some chipset/CPU combinations coreboot may turn into a simple blob aggregator with PCI init. That's a scenario I'm very afraid of.
Side note: AFAICS the blob in your patch came without any licensing document. Does Intel allow distributing the blob on/for non-Intel systems?
I don't see it as different from what we do today with microcode, which has been in the coreboot tree for many years now. While that code is in "source" form in some sense, it really is a binary blob. We would not have wanted to force people to maintain all that as as separate repo.
Microcode is conceptually different. It's a stream of bytes you bang into some register, you don't execute it as normal code on your CPU. CPU microcode is like a network card's internal firmware: outside the scope of coreboot.
Hope that helps. I'd like to make sandybridge support as convenient as possible.
I heard rumors that the MRC blob is only a stopgap solution because there wasn't sufficient time to write+QA RAM init code for the sandybridge platform, and such code might materialize later. If that rumor is indeed true, the added convenience is only a short-term benefit and I hope we can keep the blob out.
However, if there will never be an open source RAM init for sandybridge, we should decide now which types of blobs (if any) are acceptable in the main source tree, and make sure all active developers are aware of the policy.
Regards, Carl-Daniel
On Sun, Apr 15, 2012 at 3:49 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Am 15.04.2012 04:57 schrieb ron minnich: It's a slippery slope, though. We call the blob from coreboot and expect it to return to coreboot (whether the return is a JMP/RET/... doesn't matter). Unless I'm mistaken, we've never done that before,
We've been doing it for almost ten years, first with vga bios and then with microcode. In the latter case, the microcode was a binary blob linked in to coreboot which we called. The Intel MRC is actually less connected, as it is a blob in cbfs.
and if we do this now in the official tree, it will be very hard to refuse merging chipset init blobs (well, pretty much any init blob), and for some chipset/CPU combinations coreboot may turn into a simple blob aggregator with PCI init. That's a scenario I'm very afraid of.
it's a danger. It's something we have to watch for. I've made it clear to the vendors that's not what we want. They seem to be listening.
But we can not escape some minimal set of blobs unless we wish to drop x86 platforms (or most of them) because it's getting to be impossible to turn on an x86 without these blobs. The next blob I have to commit is the ME binary, and that's not even run by the x86, but by the external RISC CPU. And, you can't turn on the platform without it.
Side note: AFAICS the blob in your patch came without any licensing document. Does Intel allow distributing the blob on/for non-Intel systems?
Intel told us that Google is allowed to redistribute the MRC and ME blobs. I chose the coreboot repo as the redistribution mechanism. They said that was OK. Note: we should thank Intel IMHO. Both for letting us do this and for supporting our presence at the Intel IDF in Beijing.
Microcode is conceptually different. It's a stream of bytes you bang into some register, you don't execute it as normal code on your CPU. CPU microcode is like a network card's internal firmware: outside the scope of coreboot.
I see no difference but I'm not really here for a debate. If we can't come to convergence I'll just make a separate repo.And, I suppose this means there's no objections to me putting the ME binary blob into the tree?
I heard rumors that the MRC blob is only a stopgap solution because there wasn't sufficient time to write+QA RAM init code for the sandybridge platform, and such code might materialize later.
That rumor is complete and total random noise (to use a polite word). You heard it here first. I don't know why people make that stuff up.
So, one more cycle of this discussion and then I'd like to come to a decision. We've still got lots to do so we can give you all a coreboot release at the same time the laptop is for sale!
ron
Hi Everyone,
It is hot discussion and I am very new to the project so forgive me if my clueless-nests causes more troubles, then good. I would like to share my point of view of person who just got interest in coreboot project.
First, It is hobby for me at this point and I don't have any financial interests here. Second, I am big supporter of the FOSS, not for idealogical reasons, but practical reasons. Never the less I believe that I understand FSF idealogical stand on the issues. I sometimes disagree with their actions, but I think that I know why they are doing it. Third, I am here to help with practical implementation of FOSS, not with defending the FOSS ideology.
So, how new person like me sees things: I would love to see coreboot on every PC in the world. But this is not going to happen today, and it will not happen tomorrow if we (FOSS supporters), can't find away to work with companies that are not believers and supporters of FOSS. I have seen this type of discussions over and over again on many mail-lists. I hope that we can come with good solution that benefits both sides and not some kind of compromise that will leave bad feelings in everyone.
Here is my proposal: 1. We should have GPL version of coreboot. No binary blobs. This version will not be useful very much at this point, but it will enable the work needed to produce 100% free software. 2. Some companies will provide binary blobs with 'free distribution license' that will make coreboot much more practical today and it will allow more people to use it today. I hope that we can have those 'blobs' in coreboot. It should be very clearly to the future coreboot users when this blobs are needed. 3. Some companies will provide binary blobs with 'restricted distribution license'. In this case we should make it possible for those companies to work with coreboot, but they should be responsible for maintaining those blobs.
I hope it helps, and feel free to ignore me if I spoke out of place, Svetoslav Trochev
-
Carl-Daniel Hailfinger -
ron minnich -
Svetoslav Trochev