[coreboot] To bin or not to bin. was: Allow components to add files to CBFS

[Stefan Reinauer]

* xdrudis <xdrudis at tinet.cat> [101216 01:53]:
> I don't care where it runs. For me it's more whether it's been derived from
> some other form and what's more useful to touch if you want to change it.
> There's also the question of whether it can be replaced, but if it couldn't
> it wouldn't be included, of course.

While that last conclusion might sound logical, loading something at
runtime rather than onto a masked rom or FPGA or ASIC does not
necessarily mean it can be changed or makes sense to be changed.

> I hope it does not change even if one day vendors start giving permission
> to distribute sourceless binaries, as happens in linux or elsewhere.
> In fact there's already CPU microcode, but I'm not sure what would be
> "source" for that, so it may be ok.

Yes, we are already including microcode, and I think it would make sense
to separate it more obviously (also, putting it in some CBFS file
instead of linking it into RAM stage)

> And that drove me to coreboot. This is why the project would lose all interest
> for me if this market trend would be accepted as an excuse for including
> sourceless stuff. But I guess that the project wouldn't lose much from
> my loss of interest in it.

Actually the direction is to move stuff that was previously done in an
ASIC to some kind of firmware. The situation didn't really become more
closed than it was before, just hardware became more complex.
Not sure how that makes coreboot less interesting. It still enables you
to experiment with opening more parts of it while having a large
quantity of code already open sourced. So, how much of the code running
in tomorrow's system firmware depends on you and every other
contributor. Cutting down functionality just because it is not open
sourced yet only makes limited sense (in some very specialized
scenarios)

> I'm not arguing the usefulness of hardware without binary stuff in
> those cases, I'm just arguing the usefulness of free firmware lacking
> source for components that do have source but it is not public.

Following your reasoning a free operating system running on a closed
bios would not be useful either. Or a free firmware running on a closed
hardware. (Or, only when the hardware is an FPGA? What about an ASIC?)
Not sure we generally want to draw a line here.

> That brick would at least be useful to develop free replacements for the 
> missing parts :) 

Unfortunately coreboot depends also on people using it, not only those
developing for it. I wish more people would appreciate bricks the way
you do, though :-))

> > The default will be to not ship those files, both because we aren't
> > allowed to redistribute them, and to have a safe default from a
> > license perspective.
> 
> Default ? or policy ?

Right now we do distribute microcode files. And there's a separate
repository with some option roms that are allowed to redistribute in
coreboot context. I hope we can increase the number of redistributable
binary code needed for "the best possible coreboot experience", and at
the same time not forget the goal to provide an as open solution as
possible. My guess is that we will never see a "source" representation
of stuff like CPU microcode and stuff like EC firmware will make a
completely new project (like OpenEC) to go side by side with coreboot
but it might well be out of our scope. (VGA oproms, too)

> Thanks for explainig. Yet build system magic may hide important info
> from the user _if_ binaries are distributed. 

Right now all binaries have to be specified in Kconfig, and we might
keep a lot of it that way. If you build a coreboot rom without, coreboot
will usually fail to find the "blob" in flash and try to continue as
good as it can. On some systems (like Geode) you will not be able to
boot without the "blob". On those Geodes the source code for the blob is
out there, but can only be compiled with some old DOS assemblers, making
it hard to integrate it into coreboot as a non-blob.

>  Still helping users install non free software is not nice
> (as stated in the GNU free system distribution guidelines, for
> example), although I'd say coreboot users are not so naive as not to
> notice. Coreboot is not exactly as easy to install as Ubuntu.

I certainly don't agree with the GNU free system distribution guidelines
from a usability perspective. Yes, non-open source stuff might end up in
the binary automatically (like cpu microcode), but given that most PCI
cards have a non-open source option rom on them makes the distinction
between a blob-free and blobby coreboot somewhat artificial.

The question is, do most users want a working system, or would they
prefer a free brick. And how much thinking can we expect from someone 
who prefers a free brick in comparison from someone who just wants a
working system. My impression is that if someone wants the extra freedom
to run without blobs they are smart enough to change the open source
code of coreboot not to include the blobs. That said, freedom does not
usually come for free. There's always some work involved.

While the open source loving part of my soul might disagree, I firmly
believe that we need to provide something that works before we can sit
back and do philosophical discussions.

Stefan