LWN.net Logo

Debian goes to the polls

Debian goes to the polls

Posted Dec 18, 2008 2:10 UTC (Thu) by qg6te2 (guest, #52587)
Parent article: Debian goes to the polls

The entire hoopla around firmware is starting to resemble a circus. Assuming it's possible to get firmware source code for the majority of devices, we would require a specific compiler and/or assembler for every bizarre embedded cpu/controller out there. Furthermore, the source code might be using a particular dialect of, for example, C, that is different for each device. Is GCC up to this mammoth job?


(Log in to post comments)

tools for firmware

Posted Dec 18, 2008 2:25 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

As you say, there are a wide variety of devices. Many have an ARM processor and might well already use GCC; others are DSPs that are programmed in assembly language, and you'd need the right assembler; the GNU assembler has support for some of the more common DSPs. But certainly there are specialized processors for which no free tools exist.

Debian goes to the polls

Posted Dec 18, 2008 2:31 UTC (Thu) by mikov (subscriber, #33179) [Link]

I have always wondered about that. Note that the "firmware" source could even be in VHDL! Freedom or not, at this stage it is completely unrealistic to expect to be able to compile that entirely with free tools and upload it into commercial FPGAs.

In my mind the answer is clear: Nobody expects or requires open source design schematics for the hardware supported by the kernel, so it doesn't make sense to require it for the firmware either. The manner of distribution of the firmware is just a detail. Even if a binary firmware blob is linked into the kernel, it doesn't actually take away the users freedoms.

That said, I would rather have Debian reach any solution and move on, rather than waste time in flames.

Debian goes to the polls

Posted Dec 18, 2008 2:49 UTC (Thu) by clint (subscriber, #7076) [Link]

Another detail is that Debian doesn't distribute hardware. If it did, one might presume that that hardware must be free as well.

Debian firmware blobs

Posted Dec 19, 2008 21:40 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Nobody expects or requires open source design schematics for the hardware supported by the kernel, so it doesn't make sense to require it for the firmware either.
Another detail is that Debian doesn't distribute hardware. If it did, one might presume that that hardware must be free as well.

Right. Explaining further: Nobody suggests DFSG requires Debian to ensure source code is available for firmware in devices Debian uses. They suggest that Debian cannot distribute a binary firmware blob unless source code is available for that blob.

So the equivalent statement for design schematics is that Debian can't distribute a device if its schematics are not available.

I don't understand how people distinguish firmware blobs from, say, a binary only Linux device driver for DFSG purposes. All the arguments I see in favor of shipping Debian with the blobs are really just arguments against DFSG.

Debian goes to the polls

Posted Dec 18, 2008 3:50 UTC (Thu) by flewellyn (subscriber, #5047) [Link]

It seems almost like bikeshed painting, to me: the Debian team needs an issue to debate, because they have a need to debate an issue.

I won't say that they're master debaters, but they're getting close...

Debian goes to the polls

Posted Dec 18, 2008 11:57 UTC (Thu) by nye (guest, #51576) [Link]

> I won't say that they're master debaters, but they're getting close...

Possibly the best line I've ever read on LWN.

Debian goes to the polls

Posted Dec 18, 2008 11:16 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

A collection of packages from the Lenny main archive:

bcc - 16-bit x86 C compiler
confluence - language for synchronous reactive hardware
sdcc - Small Device C Compiler (DFSG version)
z88dk - a Z80 processor assembler and SmallC+ cross compiler

as31 - Intel 8031/8051 assembler
ava - Algebraical Virtual Assembler for Atmel's AVR MCUs
crasm - Cross assembler for 6800/6801/6803/6502/65C02/Z80
pasmo - An easy to use Z80 cross-assembler
picasm - Assembler for the Microchip PIC-family Microcontrollers
pocketpc-gas - The GNU assembler for Pocket PC
uisp - Micro In-System Programmer for Atmel's AVR MCUs
xa65 - cross-assembler and utility suite for 65xx/65816 processors
z80asm - assembler for the Zilog Z80 microprocessor

gnusim8085 - Graphical Intel 8085 simulator, assembler and debugger
piklab - IDE for PIC-microcontroller development

freehdl - VHDL simulator for Linux
ghdl - VHDL compiler/simulator using GCC technology

I mst point out I'm not familiar with just about any of those.

gcc supports a wide range of processors, but there are other CCs around. From the little I know those won't easily build all the available firmware. But hey, Linux distributers managed to tame OpenOffice.org into a beast that builds automatically, so I think that there's still some hope :-)

Debian goes to the polls

Posted Dec 18, 2008 17:49 UTC (Thu) by mb (subscriber, #50428) [Link]

Right, I also don't see the problem to have firmware tools (assembler or whatever) for each device.
Note that for devices like Broadcom wireless, we _do_ have a _complete_ assembler/disassembler (created by reverse engineering) for the firmware under GPL license. (We also started GPL firmware, but that doesn't quite work, yet.)

So, for one I think we _should_ go toward encouraging open firmware and reverse engineering of firmware. However, I think it's just stupid to delay releases due to firmware licensing issues.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds