OpenBSD Journal

Call for help: Contact TI to change their firmware licensing for wireless drivers

Contributed by grey on from the let's get calling and writing!!! dept.

You can read Ryan McBride's post to misc@ detailing the need for appropriately licensed firmware for Texas Instruments' ACX100 chips here. Additionally, Theo has contributed his worthwhile input on this issue here.

Let's let these guys know how we feel about this issue. To help our readers, you'll find each email address with a linked mailto: field if you expand this article.

Here is the current list of contacts available at TI with linked mailto: fields for their email addresses. But let's not forget about making use of the phone numbers where provided.

Bill Carney <bcarney@ti.com> +1 707 521 3069
Mr Taketo Fukui <fukui@ti.com> 81-3-4331-2060
Dr John T Coffey <coffey@ti.com> +1 707 284 2224
Mr Srikanth Gummadi <sgummadi@ti.com> +1 707 284 2209
Dr Srinath Hosur <hosur@ti.com> (214) 480-4432
Dr Jie Liang <jliang@iee.org> (214) 480-4105
Mr Joe Mueller <mueller@ti.com> 858 646 3358
Mr Lior Ophir <lior.ophir@ti.com> (972) 9 970-6542
Dr Stephen Pope <spp@ti.com> (510) 841-8315
Mr Yoram Solomon <yoram@ti.com> (408) 965-2196
Tim Riker <tim@ti.com>
DuVal, Mary" <m-duval@ti.com>
Anand Dabak <dabak@ti.com>
"Anand G. Dabak" <dabak@hc.ti.com>
Tim Schmidl <schmidl@ti.com>
Sean Coffey <coffey@ti.com>
Srikanth Gummadi <sgummadi@ti.com>
Srinath Hosur <hosur@ti.com>
Muhammad Ikram <mzi@ti.com>
Joseph Mueller <mueller@ti.com>
Lior Ophir <lior.ophir@ti.com>
Stephen Pope <spp@ti.com>
Ian Sherlock <isherlock@ti.com>
Manoneet Singh msingh@ti.com>
Richar Williams richard@ti.com>
Hirohisa Yamaguchi <h-yamaguchi4@ti.com>

(Comments are closed)


  1. By Dan (38.113.22.50) on

    OK, I sent my email. Having support for more wireless chipsets in OpenBSD would be a really great thing, both at home and at work.

    1. By Andreas Mohr (212.144.175.56) on http://acx100.sf.net

      Hi all,

      sounds like a very good idea to try to get TI to license their binary firmware files for free distribution or distribution in specific useful ways.

      However, the current attempt seems a bit "rough", if you know what I mean ;-)
      OTOH, TI has been playing that "let's pretend you don't exist" game (very popular with way too many hardware manufacturers, it seems) for far too long, despite numerous attempts of acx1xx users to contact them (I haven't even attempted to contact them myself, since I knew that so many people were unsuccessful), so it could be quite justified after all.

      My driver chose to go the alternative download route at first, since it's not too much of a hassle to download files from some other site (this could be seen in a different light since the wireless connection at that moment doesn't work yet for rather obvious reasons, but OTOH you'd have to get the wireless driver by other means, too).

      Note that Tim Riker is Linux guy #1 at TI, according to his own homepage, so it might be worth contacting him first.

      Let's hope that this finally manages to improve some parts of the current extraordinarily messy TI hardware support situation. Nobody wants to force people to open up their specifications completely if they don't deem it useful, but that's certainly no excuse for throwing millions of el-cheapo cards into the market and then not cooperating in *ANY* way (minus the initial leaked random Linux binary versions, which helped a bit...).
      After this experience of TI "quality", I will think rather hard about using TI components in my current and future embedded systems related career.

      P.S.: in case you didn't know yet, I'm the main author of the ACX100 Linux driver... (if you need more info about getting some BSD driver finished for acx1xx, then please contact me, I'll try to help as far as I can)

      1. By Michael Knudsen (217.157.199.114) on

        I think Theo said it rather well in his post to tech@. Bob Beck said more or less the same, and he also gave the argument that we discourage users to buy unsupported equipment even if it's not to be used with OpenBSD.

        I know that Promise didn't want to speak to FreeBSD until Yahoo told them that they would buy a boatload of controllers if only FreeBSD supported them. We've got to do the same thing, except we've only got users, no Yahoo.

    2. By X (81.56.211.110) on

      I give todd of openbsd team this dlink type card some times ago, hope it will be usefull.

  2. By Anonymous Coward (213.23.141.182) on

    Sorry about the OT but is there any good resource (documentation, howto, tutorial, etc.) for driver development for OpenBSD on the net? Why says McBride that he needs a freely available firmware image or firmware binary blob from TI to make a driver? Is the hardware documentation not enough to make a working driver? Sorry for the dumb questions, just interested.

    1. By Michael Knudsen (217.157.199.114) on

      NetBSD has some nice resources on kernel programming. I found a guide to writing device drivers a few days ago which looks promising.

      The firmware is not needed to write a driver per se, but if you want the driver to do anything useful, you need to have the firmware loaded onto the NIC, otherwise it cannot do anything apart from adding to your electricity bill. The firmware is a piece of code which is executed on the NIC, not in the kernel, and this is why it doesn't matter a great deal if it's binary or not.

      Of course, it's possible to write our own firmware by disassembling the official firmware, but it's far from an easy task, and it's very likely to be extremely time consuming and just as error prone.

      However, this shouldn't be necessary at all. Call TI today, because noone else will.

      1. By Anonymous Coward (213.23.141.182) on

        > NetBSD has some nice resources on kernel programming. I found a guide > to writing device drivers a few days ago which looks promising.

        Thanks for the hint. Can docs on NetBSD driver development be used interchangeably for OpenBSD too or are there a lot of differences when it comes to specific kernel structures or architectural details?

        > The firmware is not needed to write a driver per se, but if you want
        > the driver to do anything useful, you need to have the firmware
        > loaded onto the NIC, otherwise it cannot do anything apart from
        > adding to your electricity bill. The firmware is a piece of code
        > which is executed on the NIC, not in the kernel, and this is why it
        > doesn't matter a great deal if it's binary or not.
        > Of course, it's possible to write our own firmware by disassembling
        > the official firmware, but it's far from an easy task, and it's very
        > likely to be extremely time consuming and just as error prone.

        But the firmware is usually located on the NIC already isn't it?
        The driver just communicates with the device directly. So wouldn't a fully documented hardware (i/o ports along with their functions, memory layout, etc.) suffice to make a fully fledged driver?
        Sorry, but i don't get the point on the (binary) firmware yet.

        > However, this shouldn't be necessary at all. Call TI today, because > noone else will.

        OK, will do!

        1. By tedu (66.93.171.98) on

          the firmware does not live on the card permanently. when the driver loads, it loads the firmware onto the card. when the card loses power, it loses the firmware. (so it's not exactly firmware. it's only semi-firm). you can think of it as flashing the firmware every reboot if you prefer.

          1. By Ryan McBride (207.232.103.53) on

            This is often done on less expensive hardware, because there is no need for EEPROM or flash memory.

          2. By Anonymous Coward (213.23.141.182) on

            Thanks! This does clarify the issue with the firmware to me.
            But if the firmware is available in binary form (although with a restricted license) wouldn't it suffice to use the binary firmware for loading/unloading onto the card and just requesting for a documentation about the interface to the firmware so that a custom written driver can communicate with it?
            Or is it absolutely required that also the source of the firmware is available for the public?

            1. By tedu (66.93.171.98) on

              read theo's post. how do you install over the network if we can't provide the firmware? we don't need the source (and it wouldn't be terribly useful if we did have it), but we do need to distribute the binary for the driver to be useful.

            2. By Ryan McBride (207.232.103.53) on

              We're not asking for the source for the firmware, just the right to redistribute the binary blob without stupid restrictions.

        2. By henning (80.86.183.227) on

          > But the firmware is usually located on the NIC already isn't it?

          this used to be the case, but nowadays vendors are pretty anal about saving 0.10$ worth of flash.

      2. By Anonymous Coward (217.148.68.113) on

        Interesting... Do u have more links?

    2. By Ryan McBride (207.232.103.53) on

      The firmware binary needs to be loaded onto the card to make the card work (actually, there's a firmware for the ACX100 chip and a separate firmware for whatever radio the card uses, the ACX100 supports different types of radio). The card internals are basically totally unknown, the firmware provides the interface for the operating system's driver.

      Also, in this case there is actually no documentation of the interface to this chip; we're working on porting a FreeBSD driver, which is based on a linux driver developed by reverse engineering a closed driver. Yes, this sucks. Of course we would like to get documentation. But what we are asking for now is much, much less than that:

      All we want is right to distribute the binary firmware (which comes on the CD with the card), so that the driver can be included in GENERIC. Whatever license the firmware is available under, it's not acceptable for OpenBSD to become less free if we include it. That criteria is not currently met.

      1. By Anonymous Coward (213.23.141.182) on

        Thanks Ryan!
        Now i understand the issue with the TI firmware totally (from a technical standpoint :) ).
        I can only say that i will support your intentions for a free (unencumbered) firmware from TI and of course a thorough documentation about that thingy too.

        Cause water oughta be free for all! ;)

  3. By halligas (24.106.61.109) on

    Theo also called for folks to get linux users on this bandwagon Here.

    Well, I know of one seething den of linux users. Slashdot.

    Anyone with a flair for writing Calls-to-arms care to submit this?

  4. By gwyllion (134.58.253.225) on

    Theo reports that there's a better person to email to: rrobertson@ti.com

    1. By gwyllion (134.58.253.225) on

      That should be

      rroberson@ti.com
      Randy Roberson
      GM of WNBU (2004-06-03)

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]