Re: Re: more evil firmwares found
I'm not subscribed to the debian-devel list... feel free to repost to
the list if this bounces.
I've been browsing the kernel firmware threads in the archives, and felt
the need to throw in my 2c.
I have at various times worked on firmware for custom hardware. This
often involved large sequences of hand coded hex. It also often included
binary blobs for which the concept of "source code" was not really
On Sun, 18 Apr 2004, Don Armstrong wrote:
> On Sun, 18 Apr 2004, Adam Majer wrote:
> > the binary blob is *the only* way to distribute the driver in the
> > kernel - pure source code will not compile.
> That's not terribly important for the issue at hand. The GPL doesn't
> require that the source code be able to compile... it merely requires
> the prefered form for modification along with whatever scripts are
> used to generate the compiled form. [Read GPL §3 very carefully.]
With things like gate arrays, the preferred form for modification often
is a large binary file. This file is "edited" using a large commercial
application, often provided by the gate-array manufacturer. Anyone who
has this application can "open" and modify this file. There is no source
or compiler as such; the binary file is directly modified and directly
loaded into the gate array. The format of this binary file is usually
documented in the gate array spec's, and in theory you could use any
tool to edit this file.
However, some of the more complex chips and/or tools do use hardware
programing languages and/or higher-level project files that are the
preferred form for modification. These files are often highly dependent
on the application that generates them, making them useless without that
Without details on the hardware, it would be nearly impossible to
determine if the binary file you have is or isn't the preferred form for
modification. You would have to take the distributors word on that. Even
if you do have the "preferred form for modification", these files cannot
be usefully modified without full specs on the hardware, and the
application used to modify them.
In one project I worked on, large firmware binary files were generated
from a learning algorithm that was fed extremely large training data
sets. The training data sets were themselves binary files generated from
a variety of sources. The learning algorithm ran nearly a week to
generate the firmware binary. After this binary was generated we
developed our own tool that could inspect and tweak the binary file
directly. The whole concepts of "source code" and "preferred form for
modification" are kind of not applicable. How would this firmware blob
be handled if it was up for inclusion in the kernel?
Firmware walks the grey line between hardware and software. The spirit
of the GPL is that the "software" must be made available in a form
useful for modification. With firmware, terms like "preferred form for
modification" are largely useless as no form is useful for modification
without the hardware specifications. This is why we need "Open
> > Hasn't anyone considered that maybe the binary blob *is* the source
> > code?
> Yes, and we've pretty much rejected it. While they might actually use
> ASM, I've yet to run into someone who regularly codes (and modifies
> their code) in machine language.
In firmware for custom hardware I've found it very common to have long
runs of hex data hand coded in C arrays. These arrays are the preferred
form for modification, and no scripts are used to generate them.
A typical example would be hardware with large numbers of configuration
registers (up to 256 registers would be fairly common, but I would not
be surprised if there was hardware out there with many K's worth of
registers). Each register needs to be loaded with specific values that
are evaluated by hand from the hardware's spec's. Evaluating many
hundreds of hex values and typing them into an array is painful, but it
only needs to be done once, so you do it by hand. During testing you
might find you need to tweak the values, which is again done by hand.
There are several reasons why a company providing "Open Source" like
this would not or could not explain where the numbers come from.
Sometimes, explaining the numbers would reveal more about the hardware
than they are prepared to reveal. Often they don't know; all they have
is the same source you do, and the incomprehensible scribbled
calculations of the engineer who wrote it were either filed in the
trash, or are buried in a working file somewhere with configuration
Donovan Baarda <firstname.lastname@example.org>
Obsidian Consulting Group