OpenBSD Journal

Fun with Unsupported USB Devices

Contributed by dwc on from the plug-n-pray dept.

Lately, my boss and I have been wanting low power wireless communications. He's been playing with the XBee Dev Kit, and yesterday he brought me the USB version of the developer board. Plugging it in gave me the half-expected ugen(4) device. End of story? Not nearly.

The whole line is “ugen1: FTDI MaxStream PKG-U, rev 2.00/4.00, addr 2”, so I thought I'd do some digging on the web and in the source tree. It turns out there are other supported FTDI devices. Further the MaxStream site tells you (if you read hard enough) that you'll be talking directly to the onboard FTDI chip, which is the FT232BM. The FTDI site says this chip is the 2nd generation successor to the FT8U232AM. Hey, that's one of the kernel's supported devices! These chips are basically just UARTS over USB, so there's no reason the new chip wouldn't work as well.

My previous grepping had lead me to /usr/src/sys/dev/usb/, and the files usbdevs and uftdi.c. The first file is a formatted text file used to generate actual code. After modification, running make in that directory regenerates the files with the new information. Changes to the second .c file were trivial as well. Here are the diffs...

--- /usr/src/sys/dev/usb/usbdevs.orig	Sat Sep 16 12:54:13 2006
+++ /usr/src/sys/dev/usb/usbdevs	Tue Feb  6 13:57:56 2007
@@ -1047,6 +1047,7 @@
 product FTDI SERIAL_2232C	0x6010	2232C Serial
 product FTDI PS2KBDMS		0x8371	PS/2 Keyboard/Mouse
 product FTDI SERIAL_8U100AX	0x8372	Serial
+product FTDI SERIAL_232BM	0xee18	FT232BM Serial
 product FTDI MHAM_KW		0xeee8	KW
 product FTDI MHAM_YS		0xeee9	YS
 product FTDI MHAM_Y6		0xeeea	Y6
--- /usr/src/sys/dev/usb/uftdi.c.orig	Thu Aug 10 13:45:26 2006
+++ /usr/src/sys/dev/usb/uftdi.c	Tue Feb  6 14:03:04 2007
@@ -143,6 +143,7 @@
 	if (uaa->vendor == USB_VENDOR_FTDI &&
 	    (uaa->product == USB_PRODUCT_FTDI_SERIAL_8U100AX ||
 	     uaa->product == USB_PRODUCT_FTDI_SERIAL_8U232AM ||
+	     uaa->product == USB_PRODUCT_FTDI_SERIAL_232BM ||
 	     uaa->product == USB_PRODUCT_FTDI_SEMC_DSS20 ||
 	     uaa->product == USB_PRODUCT_FTDI_MHAM_KW ||
 	     uaa->product == USB_PRODUCT_FTDI_MHAM_YS ||
@@ -236,6 +237,7 @@
 		case USB_PRODUCT_FTDI_SEMC_DSS20:
 		case USB_PRODUCT_FTDI_SERIAL_8U232AM:
 		case USB_PRODUCT_FTDI_SERIAL_2232C:
+		case USB_PRODUCT_FTDI_SERIAL_232BM:
 		case USB_PRODUCT_FTDI_COASTAL_TNCX:
 		case USB_PRODUCT_FTDI_LCD_LK202_24:
		case USB_PRODUCT_FTDI_LCD_LK204_24:

After that, it's rebuild and copy in the new kernel, and then reboot. Presto chango, that worthless ugen turns into this...

uftdi0 at uhub2 port 1
uftdi0: FTDI MaxStream PKG-U, rev 2.00/4.00, addr 2
ucom0 at uftdi0 portno 1

So far so good, but does this actually work? This device should be easily accessed through cu/tip on ttyU0 or cuaU0. Sure enough, cu -l cuaU0 -s 57600 -h worked perfectly and I was able to do serial communications through the FTDI to the XBee to the remote hardware.

Is it always this easy to get unrecognized hardware working in OpenBSD? Hardly. But sometimes you get lucky with a newer version of an already supported product or chipset. A little willingness to do a bit of research and poking around can turn a show-stopper into a non-issue.

(Comments are closed)


Comments
  1. By DS (68.104.220.48) on

    Nice writeup, seems like there's a certain class of hardware that's "not quite supported but just needs a little nudging into being so."

    DS

  2. By TomazZ (193.95.206.48) tzveglic@email.si on

    Gr8 notes.

    Where/how did you get that number an what it means: 0xee18

    Thank you.
    TomazZ

    Comments
    1. By Jim Driscoll (84.9.187.181) on

      > Gr8 notes.
      >
      > Where/how did you get that number an what it means: 0xee18
      >
      > Thank you.
      > TomazZ

      It'll be akin to the trailing two bytes of a PCI ID (identifying the model rather than the manufacturer), I believe.

      Do "usbdevs -v":

      $ usbdevs -v -f /dev/usb0
      Controller /dev/usb0:
      addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), SiS(0x1039), rev 1.00
      port 1 powered
      port 2 addr 2: low speed, power 100 mA, config 1, Microsoft 3-Button Mouse with IntelliEye(TM)(0x0040), Microsoft(0x045e), rev 3.00
      port 3 powered
      $

      You should be able to spot the corresponding ID number from that (0x0040 in this case!).

      Comments
      1. By Darrin Chandler (dwc) on http://www.stilyagin.com/darrin/

        > $ usbdevs -v -f /dev/usb0

        Yes, I forgot to mention usbdevs in the article! That's how I found the product ID, of course. Thanks!

    2. By Anonymous Coward (193.195.0.102) on

      > Gr8 notes.
      >
      > Where/how did you get that number an what it means: 0xee18
      >
      > Thank you.
      > TomazZ

      usbdevs -v

      will give you a verbose list of usb devices with vendor and product identifiers. (They appear in brackets like this comment, next to the desc i.e.: WLAN(0x1723), Ralink(0x0b05) for my rum0 usb wifi device.

Latest Articles

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.]