Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment (Was: Proposal: The DFSG do not require source code for data, including firmware)
On Wed, Aug 30, 2006 at 09:36:53PM -0400, David Nusinow wrote:
> Hi Sven,
>
> On Wed, Aug 23, 2006 at 09:09:31AM +0200, Sven Luther wrote:
> > There is no way you can just decide that firmware is not code, especially as
> > there is overwhelming evidence in some case that it is indeed code (or
> > microcode as some call it), ranging from declaration on the LKML mailing list
> > by the drivers author, or when the peripheral processor holds a mips or arm or
> > whatever core. Sure, other firmware cases consist of only register dumps, but
> > my own involvement in hardware development shows me that the trend is more and
> > more for peripheral hardware with embedded processor cores, and the firmware
> > of those being actual processors, some of them could run some variant of linux
> > (or uclinux at least) in their own right. This is especially true for high-end
> > raid cards and wireless applications.
>
> Would you, or someone else, mind pointing out some examples of firmware
> with source? Preferrably with some of the breadth you refer to above? I
> understand firmware in concept, but beyond seeing it as a binary blob I've
> not really come seriously in to contact with it. If I'm going to vote on
> this issue, I'd really like to actually understand what I'm going to be
> voting on.
Ah, sorry, those i have access to and wroten kind of belong to my employers,
and those i have mentioned are not actual source code.
But some actual example of this can be found in, for example, the CSR
bluetooth bluecore4 chips, found in many popular usb bluetooth adapters, of
which documentation can be found here :
http://www.csrsupport.com/download/1956/BC419143B-ds-001Pe%20BlueCore4-Flash%20Plug-n-Go%20Data%20Sheet.pdf
Well, this is a bad example, since the firmware is actually hold in local
flash, but you will clearly see that this is actual code, page 32 showing you
a diagram of the device, which is not so different than some of the soc
(micro-)processors around there, and clearlt mentions a 'RISC
Microcontroller', altough it is a proprietary instruction set. Other bluetooth
solution from Philips (docs available only under NDA) and others hold an
actual arm (arm7 i believe in the Philips case).
Page 36, titled : "CSR bluetooth software stacks" and following, show a set of
examples of such firmwares, going from simple bluetooth HCI, to a virtual
machine, and also may include enough code to make a fully working standalone
application. I believe that this description makes it clear beyond any doubt
to anyone that firmware in this case is actualy a program.
Now, this chip, and those of its generation has builtin flash or rom, and thus
are of the not problematic case, but chips from other manufacturers, which are
cheaper or older, or technically less advanced, will hold an identic firmware
in the driver, thus sparing the on-die or external flash.
This is all about manufacturing price, and what you pay for the ever cheaper
going hardware stuff.
For information, the above CSR chip is a bit over 5 $ in 1000 unit quantities,
and you can get usb or serial modules of various qualities and interface for
15 to 35 $ for the same quantities.
Friendly,
Sven Luther
Reply to: