[coreboot] [PATCH]Allow components to add files to CBFS
patrick at georgi-clan.de
Wed Dec 15 22:07:50 CET 2010
Am Mittwoch, 15. Dezember 2010, um 20:17:18 schrieb Xavi Drudis Ferran:
> If the later I don't like the idea and at least I would like a huge
> warning "BLOBS IN HERE !!!" at the end of the make output.
I avoid the term "blob" for two reasons:
1. "BLOBS" (in this context) is an FSF scare term. Free and Open Source
software had to endure FUD long enough, we should know better than to
participate in that.
2. "blob", as used by the FSF, is not cleanly defined, and their use of that
word or its predecessors changed over the years. It used to be that their main
issue was with binary components that are run by the CPU, but now it
encompasses much more.
I prefer the OpenBSD definition of "blob": binary components that run on the
CPU. That a clear line drawn in the sand, and a useful distinction, too.
Unfortunately GNU/blob spoiled that.
Applying the current FSF use of the word, a graphic rendered to png or jpeg
without the source material (vector graphic, gimp image with multiple layers,
...) shipped with it is a blob. We're lucky that we never added a default
bootsplash image to the tree!
I had to debate with GNU developers if the S-Boxes in AES are "blobs", and if
there's a "preferred format" for them (ie. if they could be calculated). They
can't be calculated (there are a couple of formulas to verify if an S-Box is
valid, but many are), but if you pick the wrong "valid" one, you get a
different (and probably less safe) algorithm.
The FSF meaning of the term only scares the same people who use it that way.
That there aren't any binary components in the tree is simply for the fact
that they're not redistributable: We usually scrap them from vendor BIOSes,
and they're not separately available.
That won't change.
(It would spark quite a debate when storing binaries in the tree would
actually be proposed, but we never even got that far for the stated reason)
The other fact: Hardware relies more and more on update-able components in
flash, without any knowledge of what this is.
Maybe it's 8051 code, maybe it's VHDL stuff of some sorts, maybe a table like
the S-Boxes, or a JPEG image.
There is no preferred format, there's usually no disassembler for the data, or
documentation that can be read outside the high security area at the vendor
(and very likely only in 5pt print, orange glyphs on red paper in the area, to
prevent anyone from making copies), but there's a single invariant for most of
them: Without the data around, your system won't boot - it's useless as a
brick, with the only feature that it sucks power.
For this reason, I'm thinking about adding a "thirdparty" directory, which
contains only a script. That script contains a list of hash values and "real
file names", and renames files within that directory which match a hash to the
The script would be a tool to simplify handling for users who have to scrape
their binary parts from BIOS images:
Fetch the data, put it in the directory, run the script. If the data is known,
it's automatically available for the board or chipset that needs it.
If you prefer to live without the file, simply don't put it in there. Your
board might be less useful than a brick, but that's your choice.
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.
It's also a safe default from an operation perspective, as the build will
break by default (we might have to tweak the buildbot a bit to be tolerant of
that, for example by seeding the thirdparty directory on the buildbot with
empty files of the right names and sizes)
This patch won't change anything in this regard. The plan with the script I
outlined is only where I see where this project is heading, for technical
What this patch does is eliminating a bottleneck: Right now we have to
maintain a list of files that can be added to the CBFS image at a central
location, and that won't scale in the future.
Nothing more, nothing less. No feature at coreboot runtime (or misfeature as
you'd probably see it) is added or dropped, it's just build system magic.
More information about the coreboot