[coreboot] Binary blobs in the source tree (was: Re: New patch to review for coreboot: e4fc528 Add the memory reference code binary for sandybridge chipsets)
rminnich at gmail.com
Sun Apr 15 22:08:04 CEST 2012
On Sun, Apr 15, 2012 at 3:49 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at 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
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!
More information about the coreboot