[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)

[Carl-Daniel Hailfinger]

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 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.

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

-- 
http://www.hailfinger.org/