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

[Peter Stuge]

Hi.

xdrudis wrote:
> Sorry for the rant, it's not aimed at any particular person, 
> just to blobs which I don't think should get into coreboot.

I'm afraid you seem quite disconnected from the reality of PC
firmware in the industry. If you haven't already read Svante's
thesis on the topic then I strongly urge you to do so. Even
better is of course actual OEM and ODM experience.


> capital to waste when changing directions

You imply that you experience a change in direction, but as I tried
to make clear already in my last email, I do not consider coreboot
to have changed direction at all. The recent progress is a leap
forward; as already confirmed by Andrew, coreboot is more valuable
with Sandy Bridge support.

You personally, and others with you, have a different view, and
thanks to coreboot being open and free you are still able to find a
solution which meets your requirements.


> if coreboot starts filling with blobs it will be just another BIOS,
> only somewhat delayed or playing catchup with some features.

I'm not sure if you realize how absurd that is. In case you didn't
notice, coreboot has been playing catchup with all hardware for the
first 12 years.

The progress that has been made in the project during the last few
years is amazing, and instead of ranting about blobs you really
should be celebrating, because coreboot is in better shape than ever
before. I'm sure you agree that this is a good thing.

Your experience from hardware vendor interaction tells you that open
source and free software can be challenging for many vendors, but at
the same time they find it exciting because of all the benefits it
brings, both inherently by being open and free, and through features
which all in all make open and free totally superior to proprietary.

You may think that 12 years is a long time for a project, but in fact
coreboot is only since a year or so, when AMD announced their
support, starting to grow up, and even then there are many things
that desperately require your contributions to increase it's success.

Ranting? Not very helpful.

Of course - if you can not support coreboot based on your ideology
then you can not contribute, and that's too bad, but maybe you will
discover that at some later time things have changed to where you
want them to be, and then you can join the project again. Or not.

As I've already written, you could also take the blob as a challenge
to implement native memory init for the platforms. I would welcome
that contribution very much. I expect the hardware to have become
obsolete since many years, by the time you have finished. But go
ahead, prove me wrong!

Or perhaps you can find another, more productive, way to support
coreboot.


> In the past I've bought hardware believing it was likely to work
> with free firmware by looking at what coreboot supports. Recently
> I thought I might buy a chromebook if they finally run coreboot.
> But if coreboot becomes a blob loader I won't buy any hardware 
> based on the fact that it runs coreboot.

"becomes a blob loader" is conveniently unspecific. As always with
open source or free software projects: YOU are reponsible for making
it work for YOU according to YOUR requirements.

OR - you can go to a vendor and pay them for the service of doing it
on your behalf. Currently there exists no such service for coreboot,
but the more popular coreboot becomes the more likely it is that such
a service provider (or several!) will appear.

YOU have to research details to ensure that YOUR requirements are met.

Blobs do not change this fundamental fact in any way. If there are no
blobs then your "zero blobs" requirement is very easy to check off
the list of requirements, while other metrics such as "computational
performance" or "power consumption" remain exactly as difficult to
check.

You have no right to spit on coreboot (which is what you say that you
would do if it became "a blob loader") just because one part of it
solves problems which you do not want to solve, while other parts
solve exactly the problems you do want to solve.


Further, as Ron already pointed out - and as you know from your
experience with PC bootstrapping, you can't really ignore that many
coreboot systems already depend on another blob during startup - the
VGA BIOS. It's not really related to coreboot, but to the way the PC
platform is expected to work by PC operating systems.

AFAIK there are exactly three exceptions to this:

1. Very old ATI graphics support no longer available
2. Geode LX
3. Luc's work on native init of graphics on K8M890 and similar

I think the only mainboard with the latter is the m2vmxse.

The exceptions also only hold true for very special operating system
cases. You can forget about running GNU/Hurd on a system without
a VGA BIOS. Isn't that ironic?


> it will be like what linux has become, you no longer know much by
> the statement that linux runs on something. If android is free
> software

Who has said that Android is free software? That's stupid. If you
want to discuss Linux not being free enough then you can always try
to take it up with Linus.


> Coreboot may choose to go that route

Third time: coreboot has never changed direction and I do not see any
reason to do so in the future.

Of course your perception of reality may be different.


> > So the big question is really do we allow chipset support that
> > requires the use of binary blobs in coreboot. 
> 
> I try to find chipsets that don't require that.

As a user of anything, be it hardware or software, that's the perfect
attitude! And it's exactly this that makes open source and free
software very very valuable: It allows users to find the solutions
that fit their needs. You can pretend that coreboot actually does not
support Sandy Bridge and Ivy Bridge at all, and you are still golden!


> I don't think such a limited port is worth people's efforts, but
> that's for each one to decide, of course.

Indeed it is. What you write is extremely offensive. You are
disrespecting the magnitude and excellence of the work that has been
contributed to the coreboot project by the Chromebook team and I just
find that to be really really poor form, regardless of your reasons.


> a greenwashed half baked port of something that used to be free is
> not a big deal.

What the fuck are you talking about? Push your free implementation
of Sandy Bridge and Ivy Bridge memory controller init to gerrit.


> I don't see much point in making or using a port.

That's fine. If you feel that coreboot is not for you then please
do not use it and do not complain that others do. Meanwhile,
consider that coreboot is not only about your system. It supports a
few hundred mainboards and I hope it will support many hundred more.


> Does someone else besides intel and google have permission to
> distribute the blobs?

Please see
http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure

I expect you to actually have solid knowledge of this already, since
you have already sent contributions.


> coreboot users have usually assumed they had permission to
> distribute the tree freely under GPL,

You speak for all of them? I am sure that you realize how absurd
that is. Noone can claim anything on behalf of "coreboot users."


> difficulty to grasp what the criteria is for accepting restricted
> code to enable hardware support, or for distributing the resulting
> material.

Ask away about anything that is unclear! Given your experience from
hardware vendor interaction you will know exactly which questions are
appropriate and how to ask them, as well as which questions are
embarrassing faux pas, or worse, for you, and for the project.


> claim coreboot compatibility with less disclosure

Reality check. Vendors are not fighting each other over who can be
more compatible with coreboot. For 12 years coreboot has been chasing
hardware. You need to understand the full impact of this.


> I guess it's better to just stop buying hardware,

Right, better not educate yourself about your options and better not
choose what fits you, but instead choose nothing. That's the perfect
way to consume.

Yes you have to make a big fucking effort to be a responsible
consumer OF ANYTHING so that you can sleep well at night and look
at yourself in the mirror every morning. NOONE frees you from this
responsibility (mind the pun) - not even the FSF.


> if you can't even rely on a FSF priority project to get free
> software.

As I am sure that you already know, coreboot is not an FSF project.

I will not bother biting on this last piece of flame bait. I am
confident that you understand that coreboot is more free than your
other options. If it's not free enough for you at this time then
please either go away or please help us out. In any case you are
*NOT* helping by complaining.


I'm very happy that the FSF agrees with the coreboot contributors
that it's important to work toward a viable open and free PC
firmware.

This was always the direction of coreboot, and it has not changed!


//Peter