Device shows up in Linux as /dev/ttyUSB0, but not in FreeBSD. Suggestions?

A device (a stepper motor controller) shows up as /dev/ttyUSB0 when plugged into a Linux machine. I cannot find any such entry (I'm looking for /dev/ttyUx) when I plug it into my FreeBSD machine. It only registers it under ugen3.3.

Surely it can't be too difficult to get it working under FreeBSD?

What information should I gather (with lsusb(8) etc) about the device while I've got it plugged into the Linux machine that would help me get it working on FreeBSD?

Cheers.
 
wblock said:
Since it shows up as a TTY, presumably a serial port, see uftdi(4) and uplcom(4). See ucom(4) for a full list.

I somehow knew you'd be the first to reply to this post wblock :)

Can I get you to clarify what you're saying? Are you saying to look at those man pages and see if the device is supported, and if not, I'm out of luck?
 
caesius said:
I somehow knew you'd be the first to reply to this post wblock :)

Yes, SirDice must be on vacation.

Look at those man pages, load some or all of the USB serial drivers, and see if /dev/cuaU0 appears when the device is connected. If you knew what type of USB-to-serial adapter chip is used, it would narrow down the choice of drivers.
# usbconfig -d 2.3 dump_device_desc
might be helpful.
Some vendors like FTDI have customizable IDs. That could require adding those IDs to the FreeBSD driver, but that's not too hard.
 
wblock said:
If you knew what type of USB-to-serial adapter chip is used, it would narrow down the choice of drivers.
Guess I could pry the enclosure off and look. I assume the name on the chip will be sufficient to identify it? It's moot at the moment as it is stuck at University. There's been a few quakes in my part of the world (CHCH, NZ) and University was evacuated after the latest aftershock, no time to gather belongings etc... And they won't let us it to retrieve anything until all buildings have been checked! No word on how long that will take...

wblock said:
# usbconfig -d 2.3 dump_device_desc
might be helpful.
Cool thanks, as soon as I get my hands on the device I'll give it a whirl.
 
Ok, just got back in to retrieve my things.

Here's the output of
$ usbconfig -d 3.3 dump_device_desc
Code:
> usbconfig -d 3.3 dump_device_desc
ugen3.3: <Arcus-USB ARCUS> at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0110 
  bDeviceClass = 0x0000 
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x1589 
  idProduct = 0xa101 
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  <ARCUS>
  iProduct = 0x0002  <Arcus-USB>
  iSerialNumber = 0x0003  <2ED00>
  bNumConfigurations = 0x0001

There is nothing new under /dev except for the ugen device.

I've loaded all of the drivers in ucom(4) that weren't already in the kernel but still no luck.

How do I find the driver being used if I plug it into a Linux box?
 
You should also try not to use a HUB in the USB chain. Maybe the device will show up then.

I learned this the hard way when I spent some days cursing the USB printer my wife uses when the ulpt driver alsways killed the process talking to it. Yes, an [cmd=]echo HELLO > /dev/ulpt0[/cmd] would log you out. Some of the higher level drivers seem to have problems with HUBs in between, maybe the timing is a bit narrow?

But directly talking to /dev/ugen3.3 may well have to be changed when the system reboots as the device may register at a different point in time then, resulting in a different ID.
 
UPDATE: I was incorrect - this does NOT show up as ttyUSB0 under Linux (I was told it did). However it does work on Linux with the Linux driver they provide (apparently).

I think I have a bigger issue if I want to use FreeBSD for this project.

For context, I've been given the following (all for Linux):

1. A header file
2. A shared object.

I obviously can't hack the code because I can't see it. When I run one of the functions I'm given, it comes back with:
Code:
> ./test 
This kernel version is not compatible with this library.
Your system information follows:
Sytem: FreeBSD
Release: d64
error in [FILE]fnPerformaxComGetNumDevices[/FILE]

Where is the function likely to be pulling this information from? And how could I trick it into thinking it's running on Linux (when I don't have access to the source?)

Cheers.
 
wblock said:
Two ideas: Linux Binary Compatibility, and running a real Linux in VirtualBox with the new USB support.

Cheers wblock, yes I've tried the first idea. Problem is the function is pulling info from the system and it knows it's running FreeBSD not Linux, so it exits. I suspect it's using uname(3) to figure out the environment. Is there some way of spoofing uname for a program?

Yes VirtualBox sounds like a good idea.

Cheers.
 
caesius said:
Cheers wblock, yes I've tried the first idea. Problem is the function is pulling info from the system and it knows it's running FreeBSD not Linux, so it exits. I suspect it's using uname(3) to figure out the environment. Is there some way of spoofing uname for a program?

Don't know. Maybe chroot into /compat/linux?
Code:
% /compat/linux/bin/uname -a
Linux lightning 2.6.16 FreeBSD 8.2-STABLE #0: Fri Jun 17 05:36:33 MDT 2011 i686 i686 i386 GNU/Linux

But what version of Linux kernel does it want? Some inspection of the blob like richardpl suggests could show that. An email to the company is worthwhile.

Yes VirtualBox sounds like a good idea.

And now I remember that USB support may not work except for Windows VMs. Sorry about that.
 
caesius said:
This kernel version is not compatible with this library.
Code:
Your system information follows:
Sytem: FreeBSD
Release: d64
error in [FILE]fnPerformaxComGetNumDevices[/FILE]

It says kernel version and not kernel.

Searching web for this function reveals interesting PDFs documents.

You can look what that function does in editors/hte but you will need to learn assembly first.

I hope you were not asked to accept some kind of agreement when playing with those blobs or you may get in jail.
 
Thanks for replies guys, I assure you I'll slowly work through them.

I'm trying the chroot(8) idea. Didn't get far. This is from a chrooted environment (/compat/linux)

Code:
sh-3.2# /opt/64-bit/test 
ELF interpreter /libexec/ld-elf.so.1 not found
Aborted
sh-3.2#

I know it's not there. How do I get it there?
 
richardpl said:
Have you installed one of linux_base ports?

Yup. I started linking the local copies of things it wanted into /compat/linux but then I ran into my original problem; it knows that it's running on FreeBSD, even when chrooted :/

Thanks for all your help guys, looks like I'm just going to have to install Linux as this is a Uni project and it's getting harder and harder to justify the hold up getting things to work on FreeBSD :)

Cheers.
 
Back
Top