[coreboot] To bin or not to bin. was: Allow components to add files to CBFS
xdrudis at tinet.cat
Sat Dec 18 00:00:56 CET 2010
Warning: long, personal, philosophical, not even very original
or insightful. Read at your leisure or not at all.
On Thu, Dec 16, 2010 at 05:14:29AM +0100, Stefan Reinauer wrote:
> 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 only partially understand you. What it makes sense to change or not
should not be a reason to stop people from changing it. What makes
sense or not is not related to freedom, and what makes sense to someone
may not make sense to someone else. What can or
cannot be changed is a different story. Things that cannot be
modified do not need to carry freedom to modify them. It's like the
declaration of human rights: it would make sense to include the right
of all humans to flap their wings and fly to the moon if only we
could, the reason it's not there is that it's not possible, not that
it would be wrong to have that right. You don't need the freedom to
do something impossible but you need the freedom to do something that
does not make sense (to whom?) unless there is an ethical reason
to restrict that freedom.
> 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)
I'm not sure I understand how microcode is produced. I faintly remember
some blackboard exercises at college with some toy CPUs and instruction sets where we
wrote microcode by hand. There I guess microcode was source if there was
any source at all. In reality microcode is possibly compiled from some source with some
tool which also gives some circuit designs. Both circuits and microcode
is just logic, with the difference that the microcode can be changed
and the circuit can't. The microcode can be modified without changing
the circuit (I guess), at least to disable some nasty feature.
The question for me is whether there is a source for the microcode
that can be modified without altering the circuits in order to get
some change in behaviour, performance, etc. If the only source there
is can't do that (because if modified it would give different microcode
but also different circuits, so back to factory), then it's likely not
necessary to have that source. Now the question is what about some other
conceivable source which could be used with some other tool to modify
the microcode and still run it on the same circuit? That would be desirable,
but possibly unrelated to the microcode at question.
So the microcode would be acceptable or not depending on how it was
produced, which I don't know. The fact that the vendor provides
updates to the microcode that don't require to change the hardware
suggests there may exist some source like we would need, but it does not
prove it. If you ever know there was a source and you don't have it
then you'll know you're not in compliance with GPL if you link the
microcode with someone else's GPL code in a derived work. If you have
an option of avoiding that, it's nice to take it. Putting the microcode
in external files would possibly be cleaner legally, although it
would not help much philosophically. I agree help about that may not
belong in coreboot but other free projects.
> > 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 necessarily more complex, but more general.
If there are two designs for the same functionality, design A with an ASIC
and design B with firmware, then the hardware (unchangeable part) is more
general with design B, because it can at least do as much as A and potentially
more by changing the firmware (which is not hardware). If you think of the
hardware has the circuits + firmware, then it may be getting more complex,
but I think the hardware may be getting even simpler (at least the logic
in it, I'm not talking quantum physics or electronics here), there's just more
of it, and so the increased complexity is more manageable in firmware.
For those who have the firmware's source, that is.
In fact firmware is increasingly doing more nasty or undesirable stuff,
like remote controlled PCs and the like, so this very trend is a reason
to watch out for propietary firmware, not to accept it. And I believe
the reason for the trend is simply that OSes (specially propietary OSes)
are incresingly unreliable, so vendors tend to shift stuff to firmware
(which does not help, it just delays the problem, propietary firmware
will evolve like propietary software, opacity scales worse with complexity).
> 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
I see your point. My view is that if I have free projects which don't
include propietary parts and report support on different hardware, I
have a clearer idea of what hardware I want to buy. It's also easier
to pick my ethical choices when compiling. If all free projects start
including propietary parts just because that's the market trend, and
there's too little functionality available wiht only free software
with the hadware in the market, then I have more work of finding out
and separating the propietary parts.
So I guess our common ground is the more clearly separated free parts
and propietary parts are, more clearly documented and more obvious in
documentation and "advertising" the better.
> 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.
I think the line is what can be changed vs what can only be replaced.
Hardware cannot be changed, can only be replaced, software can be changed.
So software should be free. Hardware should be open ? Yes, but I thought
coreboot was a software project.
So, personally, for the purposes that lead me to coreboot, yes, a free OS
on propietary BIOS is not useful to the task of preparing a computing platform
that is as free as possible for my needs.
> > 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 :-))
You must love this planet, then. Most people use bricks to build stuff (houses,
Lego artwork...) not as tools by themselves. :-)))
> 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)
I agree those free projects may be out of coreboot scope, no matter
how interesting or difficult. I fail to see why the propietary
projects would be more in coreboot scope, though. But I understand
my concept of "best experience" is not the same as everybody's.
For me finding out I've wasted time and effort learning and setting
up stuff I thought was free to find out it was not as free as I thought
is a bad experience.
> 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.
IMHO if source is available and the corresponding binary is distributed
then the source should be distributed too, no matter how difficult to compile.
I see no problem with distributing binaries when there is free sorce
for them, it's a nice convenience, just make the source available too.
In general I tend not to put binaries in svn, but that's because they're
easy to produce from sources, and svn is most useful for sources. As soon
as binaries are not easy to produce from sources, I'm ok with keeping
both on svn. And of course when one can choose, the easier and freer
compilers the better, but that's no reason to avoid the worse when/while they
are the only options.
> 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.
If it's a ROM it can't be changed and there's no issue, as said before.
A blob it's different.
> The question is, do most users want a working system, or would they
> prefer a free brick.
I'm afraid most users want a propietary BIOS, or more precisely they
want whatever BIOS comes with their hardware because they don't want
to flash anything and want it to work with "everything". So the
question is what do _your_ users want?. And that comes to who are your
users? And that's another way of asking what do you want to build ?.
> 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.
I see it the other way round. If people choose a free project they expect
the community to provide free software, not a mixed bag. From then on
the effort should be expected to introduce propietary components.
Otherwise trust is eroded and understanding what you get is harder.
I don't see freedom as an "extra". At least not in a free software project.
> 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.
Do you mean propietary BIOSes don't work ? Only you know your reasons but I
very much doubt there weren't philosophical considerations in deciding to
work in coreboot. Anyway, I don't want to distract you from your work. I
already said I wouldn't have believed this project possible if this team
hadn't made it real. Thanks.
And thank you very much for your time clarifying your views.
More information about the coreboot