Re: [DRAFT] resolving DFSG violations
On Mon, Oct 27, 2008 at 18:41, Ben Finney <ben+debian@benfinney.id.au> wrote:
> Whoever the copyright holder of that work is (I read your remark above
> to mean that the hardware manufacturer is that copyright holder),
> there must be a "preferred form of the work for making modifications
> to it". What form is that? *Someone* must have it, in order to make
> modifications that become new releases of the work to run on the same
> hardware.
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
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
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
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
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 the chip manufacturers don't know what they are. It's totally
machine generated chip garbage as far as they are concerned. Once you
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
Reply to: