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 simulator. > 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > Regards, Cascardo.
signature.asc
Description: Digital signature
