On Tue, Oct 28, 2008 at 8:38 AM, Simon Richter <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> At least, that's my understanding of some of the use cases presented
>> here: that even the vendors of those blobs routinely modify the binary
>> blob directly to generate a new version of it, much like
>> bit-manipulating a machine-code executable and running it.
>
> No, it's more a case of there not being any free compiler available that
> could produce a working blob.
> (snip)
> Almost the same thing goes for FPGAs, which need to be optimized for the
> specific chip.
> (snip)
>
> We do have compilers for these systems, but they will not generate code
> that can fit into the actual hardware.
>
> The commercial compilers that can handle this are not free software.
>
>> My opinion is that recipients of Debian should have unfettered access
>> to exercise the freedoms of running/performance, inspection,
>> modification, and redistribution of the entirety of Debian, using
>> nothing but operating system tools that are similarly unfettered and
>> hardware that's commonly used for such activities.
>
> We cannot provide that even with the consent, however unlikely, of hardware
> manufacturers, simply because their tools are not free software, so at the
> current time lobbying for free firmware is a pretty pointless effort.
>
> The only thing that will give us free firmware is actually writing it, and
> writing the tools to compile it; the thing we need from hardware vendors
> has not changed: documentation for the interfaces from the programmable to
> the hardwired bits.
>
> Simon
>
I'm not a DD and didn't want to jump into the middle of what had been
a heated discussion, but I've done a bunch of hardware work and I've
realized reading related discussions over the past week that many DD's
might not be familiar with some of the lower-level complexities.
Simon mentioned that free compilers aren't available for many devices.
Of course the next logical question is: why not create a free
compiler? It isn't that easy (and in some cases impossible because at
least Xilinx and Altera are very unlikely to cooperate, as Simon
alludes).
In the FPGA/CPLD world, Xilinx and Altera are the top vendors. VHDL
source code to run on their chips would be better than a binary blob.
As Simon mentions, although there are free tools for synthesizing VHDL
("synthesizing" is the English term usually used for "compiling"
VHDL), those tools won't produce anything that will run on Xilinx or
Altera FPGAs. You must use the manufacturers' own non-free (except
sometimes for student editions), non-open tools to synthesize your
VHDL.
The format of the final blob is something those two manufacturers
treat as proprietary. Knowing the structure of a Xilinx or Altera
binary blob would give their "Hertz vs. Avis" competitor insight into
their devices' low-level chip architecture. Without the binary blob
structure being public knowledge, you'll never see open tools to
synthesize VHDL that will actually run on these devices.
But at least if you could get the VHDL source, it would be an
improvement over just a binary blob. You'd then have something you
could maintain, albeit with non-free tools. On the flip side, this
also means that nobody can just tweak some values in a binary file for
a Xilinx or Altera device -- the VHDL source must exist somewhere.
Many non-FPGA microprocessors load programs and otherwise update
EEPROM locations using the Intel Hex File format. In this case,
source code for a program probably exists written in assembler or some
higher-level language. However, it is reasonable for a vendor to use
a raw Intel Hex File to modify a few parameter values at specific
EEPROM locations on their device once the main program is loaded. The
only other case I can think of a vendor _maybe_ writing a raw Intel
Hex File instead of at least assembly language source might be to
create a highly optimized, very tiny bootloader. But even then, they
should be able to get the smallest machine code possible using a good
assembler.
So for a tiny bootloader or to just modify some parameters stored at
fixed EEPROM addresses, it is reasonable for a vendor to only use a
binary blob (Intel Hex File or some equivalent). From the point of
view of long-term maintenance though, any sane vendor should be
maintaining anything larger than that in some type of source code
form.
FWIW, PostScript can at times be considered a proper source language.
Along the lines of "when all you have is a hammer everything looks
like a nail," since I know PostScript I've often directly written
PostScript programs to generate graphics images, calendars, etc.
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." -- George Bernard Shaw
Paul Hardy
GPG Key ID: E6E6E390
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
