Serial hub firmware and Debian 3.1

Serial hub firmware and Debian 3.1

[Wilbert Knol]

Not strictly a linux-hams issue  - although it has put me off the 
air ;-) I have hit the wall with this one, and I know there are 
experienced Debian users out there.

Recently, I  migrated to Debian 3.1, and I am impressed with it, 
except for one thing: my 4-port RS232 USB hub no longer works.

This is a Keyspan USB49WLC outboard USB hub that I need for Hamlib rig 
control, TNC access (DX-Cluster), CW-keying (cwdaemon) and PTT-keying 
on the digi-modes.

The keyspan driver loads, but syslog complains that 'the firmware is 
unavailable'. 

I have brewed up my own 2.6.8 kernel *(using Debian supplied 2.6.8 
kernel sources) but there does not seem to be a way to build firmware 
images.

The Keyspan device driver compiles (and loads) but firmware is still 
'unavailable' and the hub remains QRT.

Any pointers are appreciated.

Wilbert, ZL2BSJ

Re: Serial hub firmware and Debian 3.1

[Dave Platt]

> The keyspan driver loads, but syslog complains that 'the firmware is 
> unavailable'. 
> 
> I have brewed up my own 2.6.8 kernel *(using Debian supplied 2.6.8 
> kernel sources) but there does not seem to be a way to build firmware 
> images.

Hmmm.  In the 2.4 kernel series, the kernel configuration for USB
serial devices allows you to specify the Keyspan USA-xxx driver, and
then specify which versions of the firmware you want to build.

I suppose it's possible that this capability was removed from 2.6 (not
sure why) or is not present in the Debian-provided kernel sources.
The Keyspan firmware code is provided in the form of a .h file which
contains binary data - it's not the original Keyspan source code,
which Keyspan declines to release.  I suppose it's possible that this
inclusion of binary-only firmware may have conflicted with Debian's
quite stern open-source-licensing rules, even though it contains a
license grant to use in Linux by Keyspan.

First thing I'd do is check your kernel sources (look in
drivers/usb/serial/).  See if the "keyspan_usa49wlc_fw.h" file is
present, and if the Config.in file in that directory provides an
option to enable the building of the firmware.

Another possibility is that you need to include the Debian "hotplug"
package, in order to enable hot-plugging with firmware loading.
This might not have been provided by default.

Re: Serial hub firmware and Debian 3.1

[Hamish Moffatt]

On Mon, Jul 25, 2005 at 03:56:42AM -0000, Dave Platt wrote:
> I suppose it's possible that this capability was removed from 2.6 (not
> sure why) or is not present in the Debian-provided kernel sources.

Yes, it's been removed from the Debian source tree. See
/usr/share/doc/kernel-image-`uname -r`/Debian.src.changelog.gz.
It was removed in 2001.

> quite stern open-source-licensing rules, even though it contains a
> license grant to use in Linux by Keyspan.

A license grant is not actually as good as source code though.

Remember - although your device doesn't work, at least your freedom is
intact. Or at least until you build your own kernel from kernel.org
sources.


Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Re: Serial hub firmware and Debian 3.1

[Wilbert Knol]

Many thanks to Dave and Hamish for pointing me in the right direction.

Hotplug was already installed, but the firmware wasn't in the source 
tree. I went hunting and spotted the comment in the Debian ChangeLog.

So...keyspan_usa49WLC_fw.h was dropped in from an old kernel.org 
2.4.10 source tree I had lying around. Next, I had to hack out the 
conditional #IFDEF statement from keyspan.h to make sure the firmware 
image was #INCLUDED. After a kernel recompile && reinstall - using 
the snazzy 'make-kpg' command - the serial hub roared into life.

Hmm...I can understand Keyspan not wanting to release the driver 
sources for the chipset, and I can see why the Debian people won't 
distribute non-GPL code.

Wilbert, ZL2BSJ

Re: Serial hub firmware and Debian 3.1

[Jeremy Utley]

> Hmm...I can understand Keyspan not wanting to release the driver
> sources for the chipset, and I can see why the Debian people won't
> distribute non-GPL code.
> 
> Wilbert, ZL2BSJ

A little off topic for the list, I know, but why can you understand a
manufacturer not releasing driver sources?

a)  The driver sources are no good unless you already have the hardware
b)  A manufacturer *SHOULD* want to allow people to use their hardware

Therefore, it's in *EVERY* manufacturer's best interests to release
driver source.  Keep in mind we're not talking about the ARCHITECTURE
of the device - I can easily see why someone would want to protect
that...but the protocols used in communicating with that device,
there's absolutely ZERO reason to keep those closed - because of a)
above.

Jeremy, NW7JU

Re: Serial hub firmware and Debian 3.1

[Dave Platt]

> A little off topic for the list, I know, but why can you understand a
> manufacturer not releasing driver sources?
> 
> a)  The driver sources are no good unless you already have the hardware
> b)  A manufacturer *SHOULD* want to allow people to use their hardware
> 
> Therefore, it's in *EVERY* manufacturer's best interests to release
> driver source.  Keep in mind we're not talking about the ARCHITECTURE
> of the device - I can easily see why someone would want to protect
> that...but the protocols used in communicating with that device,
> there's absolutely ZERO reason to keep those closed - because of a)
> above.

I can suggest at least four reasons, all of which I know to apply to
at least some of the "We won't release the firmware source code"
situations which have arisen.

Reason 1:  the hardware used in the system may in fact be fairly
generic.  It's possible to implement quite a bit of interesting
product technology by using some very generic peripheral hardware...
for example, there are some generic "8051 microprocessor with a
USB interface" chips on the market, which different manufacturers
have used as the basis of their USB peripheral devices.  In these
cases, the company which implements the firmware is the manufacturer
of the final device, not the manufacturer of the chip, and the
device manufacturer's "value add" is the firmware, packaging,
marketing, and support, and not the underlying hardware..  These
manufacturers may be more concerned about the risk of having their
firmware duplicated, and used by companies which make "knockoff"
copies of their hardware based on the same generic chips, then they
are about the possible loss of a small incremental market segment
which insists on open-source.

Reason 2: same scenario as Reason 1, but the device manufacturer
licenses the firmware from a third party.  The device manufacturer
may not have the legal right to distribute the firmware in source form,
if they've purchased a binary-only license from the party who
originally wrote it - and this party (not being a hardware
manufacturer) has no incentive to allow open-source distribution
and re-use of their firmware.

Reason 3: the firmware incorporates some very significant intellectual
property (e.g. customized DSP code), which the manufacturer feels gives
them a market advantage over their competition and which they may plan
to use in future products.  They don't want to give their algorithmic
secrets away to any Tom, Dick, and Harry.  This appears to be the
scenario for the products made by at least one major wireless-networking
company - their drivers and firmware have a lot of their in-house IP
and they are unwilling to give it away to their competitors.

Reason 4: regulatory.  Some wireless devices (e.g. Atheros 802.11 network
chips) qualify as "software-defined radios" under FCC rules, because
much of their behavior (e.g. frequency channels, power levels) are managed
by the driver software or firmware.  The radio hardware is capable of
transmitting on bands, and with power levels which are outside the limits
of various national rules... only the integrity of the software prevents
this from happening.  The FCC permits such software-defined radios to be
marketed and used, but only on the condition that they incorporate
safety measures which deter people from tampering with the settings and
using them outside the relevant limits.  Atheros releases a binary-only
HAL module which controls the hardware and enforces the limits, and enables
people to wrap this module in an OS-specific driver.  I believe they feel
that they cannot release the low-level HAL source code, without being
at risk of having the FCC forbid the sale of their chips and products
for violation of the SDR rules.

Unfortunately, it seems to be a fact of life that one or more of these
reasons-to-restrict-source-code will probably continue to arise in
various devices in the future.  Those who feel very strongly about
"completely open-source" can decline to buy or use such products, while
those who are willing to bend a bit in these cases do have that option.

Re: Serial hub firmware and Debian 3.1

[Michael Taylor]

On Mon, Jul 25, 2005 at 09:46:06PM -0700, Jeremy Utley wrote:
> A little off topic for the list, I know, but why can you understand a
> manufacturer not releasing driver sources?
> 
> a)  The driver sources are no good unless you already have the hardware
> b)  A manufacturer *SHOULD* want to allow people to use their hardware
 
Because increasingly "features" are not implemented in hardware but
in either programmable firmware or the drivers itself. The usage of
surplus CPU cycles on the motherboard means that less hardware is
needed on the device itself. This translates to fewer components,
lower costs, cheaper selling price, which in a post-Walmart world
means more sales and thus more profits.

Re: Serial hub firmware and Debian 3.1

[Wilbert Knol]

On Tuesday 26 July 2005 16:46, Jeremy Utley wrote:
> > Hmm...I can understand Keyspan not wanting to release the driver
> > sources for the chipset

I meant to say: 'firmware sources'.

The Keyspan device driver *is* open-source, and, I believe, was 
written by (or with assistance from) the manufacturer. This is why I 
purchased this particular gizmo.

Firmware is what programs up the chipsets inside the device.  By 
studying what registers are being written to, it would make it easier 
to reverse-engineer the hardware.

I have another USB<>RS232 converter (USB1000 single-port ) based on 
the FTDI chipset, which doesn't require a firmware download and works 
with out-of-the-box Debian 3.1

Wilbert, ZL2BSJ