[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [DRAFT] resolving DFSG violations

On Mon, Oct 27, 2008 at 08:30:38PM -0700, Jeff Carr wrote:
> I guess it's really hard to explain because there is a massive gap; I
> can't teach you to be an electrical engineer or logician here :) I

You are assuming there is gap when there may be not.

> think if you had the time to go through and synthesize "firmware
> blobs" for some chips then you would see why this doesn't make sense.
> It would also expose you to the tools that the hardware and logic
> engineers use to do this process. It would also expose you to the

Would those be tools like a Verilog or VHDL synthetizer distributed by a
FPGA manufacturer? Considering the hardware is FPGA, of course. In the
case it is not, I assume there would still be procedures like logic
design, routing, etc.

> pre-requisite knowledge of the board design (layout, etc) that you
> have to have. Then I think it would make sense to you why this
> conversation doesn't make sense right now. It's that these "binary
> only blobs" only make sense to the chip. It's like they are a map of

So, why do they only make sense to the chip? Is it because there is no
current implementation of a software simulator? And why would a software
simulator not be feasible? The binary blobs would make sense to the

> how the transistors are to function -- an oversimplification -- but
> generally that's the nature of it. *
> For example, lets say you have a pci device. If you don't load the
> firmware blob, the pins will just remain in an uninitialized state.
> That is; the chip default. Programming in the firmware blob will tell
> the chip how to work as a pci bus. Now you are good to go. It's now
> possible to write a pci device & there are registers, etc. As a
> hardware engineer I can give you all the registers and an API and even
> some sample GPL code so you can write a device driver. Now, some
> people are smucks like nvidia and they don't give out diddly. Still,
> the firmware blob that you load into the chip isn't x86 code for the
> host -- it's raw junk for the chip. It's a totally different issue

If it's not clear by now, people are not arguing that hardware should
not be used if it is not free hardware (either it is feasible or not to
distribute or exist source code). The matter is whether source for code
that will not execute in the main CPU is needed for those codes in the
main section. So, your point that it is not x86 code is moot in the case
"firmware" is considered to be the same as other software in Debian. If
source code isn't available or "possible" for the chip carries the same
requirements for DFSG as the case would be for the x86 code, in the case
"firmware" should still follow DFSG.

> than distributing a binary only nvidia driver. That's not what I'm
> talking about here. I'm only trying to explain there are binary only
> firmware blobs for most chips, you have them for most of the chips on
> your motherboard and in many cases, there is no human readable form.

Even machine readable form would still be considered source if its
interpretation by the machine could be presented to someone to make
modifications to it. If it is not modifiable for some reason and every
design should be done from scratch, perhaps there is a problem with the
tools and/or processes used.

> Even the chip manufacturers don't know what they are. It's totally
> machine generated chip garbage as far as they are concerned. Once you

Which machines do generate this "garbage"? Do they do it all by
themselves? Are there machines designing new hardware now without human
intervention? Or are those chips magically enhanced so they could make
some sense of any random bitstream and there is no real mistery in
generating this "garbage"?

If the manufacturers are unaware of it, I doubt the designer is unaware
of it.

> have the chip initialized then you can hook it up to an oscilloscope
> to debug it (or maybe you're lucky and you can already talk to it from
> your device driver).
> * http://en.wikipedia.org/wiki/Floorplan_(microelectronics)
> * http://en.wikipedia.org/wiki/Logic_synthesis
> * http://en.wikipedia.org/wiki/Place_and_route
> -- 
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Attachment: signature.asc
Description: Digital signature

Reply to: