[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 04:57 schrieb ron minnich:
> On Sat, Apr 14, 2012 at 3:12 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at 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