On Sun, 2008-10-26 at 20:17 -0700, Jeff Carr wrote: [...] > If you did synthesize it, you might not have even "seen" it if you put > it on a cpld. Then you might have just thought you were "programming" > the chip. You have to synthesise *from* something, be that Verilog or VHDL or Handel-C. > No; you were just writing it to flash. Thus bypassing the > dilemma. If you build a product and don't want to pay to have the > extra chip onboard (common on cheap low end parts) then you have to > load it via software. Thus the firmware blob. And yes, for the 50th > time: THERE IS NOT SOURCE CODE. There can not be source code, it > didn't start as source code. You can't "compile" it because there > isn't a compiler. It's not instructions for a microprocessor -- in > your case -- it is the microprocessor itself. That's right, lets say > that again, the firmware blob is your 4 bit microprocessor. Sure, it's not a program in the usual sense, but there is a source for it. > So this whole free 4 bit microprocessor you just made, you can publish > the source and everything (see also: openrisc & opensparc). But, to > run it, you have to give people a firmware blob so they can run it. If people want microprocessors then they buy ASICs, which are much cheaper, faster, and power-efficient. So far as I can see, the major use for open hardware designs is as modules ("IP") in larger designs which will later be synthesised into ASICs. The people using them will need the source; they already have the synthesis tools. There aren't a whole lot of mass-produced devices using CPLDs or FPGAs either, as that doesn't usually make economic sense. > Perhaps you can't even make an installer for it because you can't > initialize the chip in the installer because you can't put the fimware > you need in the installer. I believe we can distribute firmware binaries in main if we can also distribute their sources. We might need to make an exception to the policy that we build all binaries using tools in main. > So you can only support hardware where you > can flash the firmware on the motherboard. Also not ideal because you > might have a version out of sync with the kernel device driver you > wrote. Great, thanks a lot freedom. > > So yes, I think most people aren't going to "get" the issue unless > they may have been firmware engineers. IANAFE, though I probably will be soon. Ben.
Description: This is a digitally signed message part