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.
Attachment:
signature.asc
Description: This is a digitally signed message part