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