Am 15.04.2012 22:08 schrieb ron minnich:
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.
I thought the microcode updates were not executed as binary blobs, but rather uploaded (or banged into a register) into the CPU.
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.
Glad to hear that.
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.
Is this a problem for all x86 CPU vendors? I don't believe in "name and shame", but at least knowing if there is unaffected hardware would help making an informed decision. By the way, we should really document in the wiki what's going on outside the coreboot code paths before and during startup.
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.
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?
Now that you're explicitly asking me, I'd like to keep ME/IMC (Management Engine/Internal Management Controller) binary blobs out as well. Rudolf has worked quite a bit on a free IMC firmware for recent AMD chipsets, and there's a faint hope (i.e. wishful thinking) we'll get something like that for Intel as well one day. The same applies to firmware for standalone EC (Embedded Controller) in laptops/servers.
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.
Wishful thinking maybe? I really hoped the rumor would be true. Probably a classic telephone game: "MRC blob is a hard requirement" -> "would be nice if we had a MRC blob replacement" -> "maybe someone is already working on that" -> "surely somone must be working on that, it's an obvious goal".
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!
I'm all for having a separate git tree with all sorts of helpful/necessary blobs hosted at coreboot.org, because that gives us the option to keep the trees in sync and it also makes coreboot.org the canonical source of everything you might ever want or need for a firmware build. (CPU microcode updates should remain in the main source tree, though.)
Regards, Carl-Daniel