Am 17.04.2012 01:48, schrieb xdrudis:
In the past I've bought hardware believing it was likely to work with free firmware by looking at what coreboot supports.
We already have some notebooks in the tree that require embedded controller firmware that you can't replace - it's not just an inconvenience that can be fixed by using the right DRM/GEM/Gallium/DDI/whatever driver, but their absense actually breaks the boot process.
Sorry, this was simply a wrong assumption, and for a long time.
otherwise, it will be like what linux has become, you no longer know much by the statement that linux runs on something.
coreboot is not a free software certification process. Never was.
It is pervasive, it has a big growth, it has many users. Yet it doesn't give them quite enough freedom.
What does that tell us?
Coreboot may choose to go that route or may try to go the way of many other free software projects (GCC, Apache, debian...)
Apache is hardly a free software project (it's open source - the Android "issue" you lament exists for a large part because they use the _Apache_ license).
So the big question is really do we allow chipset support that requires the use of binary blobs in coreboot.
I don't. I try to find chipsets that don't require that.
Then current Intel chipsets aren't for you: Sandybridge requires (besides the MRC binary) a MEI binary, for the embedded controller in the chipset.
Without a proper MEI firmware, the CPU won't even start executing x86 opcodes. The MEI firmware is signed (with some private Intel key). You (or someone) might be able to reimplement the raminit part. Good luck cracking the key to MEI firmware signatures.
It gets better: Intel TXT (some security feature) uses another signed bit of code. This time for x86 (yes, ran on the CPU. Look up Invisible Things Labs, they explain why this is a stupid idea even without regard for any notion of "freedom"). Again signed with some private Intel key. You can argue that TXT doesn't matter for you, but then why buy it (and support a company producing such things)?
There's another vendor, a bit smaller, but with slightly more sensible design decisions, that might suit your needs better.
I don't think such a limited port is worth people's efforts, but that's for each one to decide, of course. There are other propietary BIOSes around for that hardware, a free port to any hardware is worthwhile, a greenwashed half baked port of something that used to be free is not a big deal.
Sandybridge support was never "free" (it wasn't there in the first place), and I doubt that the intention was "greenwashing".
and the propietary BIOS you got preinstalled from factory does the job,
coreboot _is_ the firmware preinstalled from factory on those boards. I truly hope it does the job.
coreboot users have usually assumed they had permission to distribute the tree freely under GPL, not necessarily sending people to a single repository because the parties with distribution rights have designated it as distribution means. I mean people can publish their git trees anywhere, can't they? Must they now prune the blobs or ask intel for permission ?
That's why we discussed moving the file into a separate repository, "just to be sure" (and avoid annoying discussions about the DFSG down the road).
Others can claim coreboot compatibility
That first has to be desirable to vendors before I care.
I guess it's better to just stop buying hardware, if you can't even rely on a FSF priority project to get free software.
coreboot is no FSF project. Any such labelling is on their part. Sorry if they misled you.
Conformism with blobs seems to be so pervasive...
While mrc.bin matches pretty much every definition of the term "blob", the FSF muddying the waters wasn't exactly helpful to keep that term meaningful.
Patrick