Date: Thu, 10 Apr 2003 15:34:41 -0400 From: Charles Owens <owensc@enc.edu> To: hackers@freebsd.org Cc: jay desjardins <desjardj@enc.edu> Subject: limits of ucom / uplcom functionality; vmware serial mucking Message-ID: <3E95C751.8050201@enc.edu>
next in thread | raw e-mail | index | archive | help
Hi folks... long time no post.
I'm trying to make use of ucom as I would a normal sio port and am
having only partial success. Hopefully someone here can help me
understand what's really going on.
Overview:
* Goal: use ucom0 with vmware2
o (I can do this with an sio(4) port just fine using /dev/cuaa#)
* Problem: vmware fails (with error message) when guest attempts to
open port
* Hardware
o Bafo BF-810 USB-Serial adapter...
+ Detected (properly, I believe) via uplcom(4):
uplcom0: Prolific Technology PL2303 Serial adapter (ATEN/IOGEAR
UC232A), rev 1.10/2.02, addr 2
o For testing: Null serial cable between COM1 (ttyd0) and
BF-810 adapter's DB9 port
* Software
o FreeBSD 4.7
o getty as dummy test target
o tip / vmware2 (from ports) as local serial app
Experiments:
1. getty running on ttyd0, tip to ucom0
* SUCCESS (can login just fine)
2. getty running on ucom0, tip to cuaa0
* FAILURE -- Repeated on-the-fly adjustment of ucom0 baud rate
allows brief spurts of functionality. Rate changed from
9600 bps to 19200 and then back using stty(1):
stty -f /dev/ucom0 speed {RATE}
3. getty running on ttyd0, vmware guest using ucom0 as its COM1
* FAILURE -- upon launch of virtual machine vmware spits out
error message: "Failed to configure physical device ucom0:
Invalid argument \nFailed to connect serial0..."
* Again, this set up has been proven to work just fine:
o serial cable server COM1 to some other serial device (eg:
console port on another server)
o vmware guest using cuaa0 as its COM1
The obvious questions:
* Why won't vmware open ucom0?
* Am I doing something wrong or is it related to the basic nature of
ucom and/or uplcom? If the latter, is there a workaround?
* Is it likely that some other USB-Serial adapter would work
differently (better)? (this would suggest that the problem is not
due to issues with ucom(4) itself).
* Is this the best list for posting this question?
Musings:
* I am thinking that this problem may relate to ucom(4) not really
providing full sio(4)-like (I think this is the case anyhow)
functionality. The ucom(4) man page says it behaves like
tty(4).... am I doomed just right off the bat because of this?
* I am not sure how the port should best be configured. There
appears to be nothing like sio(4)'s initial-state and lock-state
devices. I've been able to config ucom0 with stty(1), but only
while it is open by an application. All config changes are lost
as soon as the application closes the port.
* I thought perhaps that there might be some support for callout /
callin /dev entries, similar to sio(4). Digging in
/sys/dev/usb/ucomvar.h revealed:
#define UCOM_CALLOUT_MASK 0x80
#define UCOMUNIT_MASK 0x3ff7f
#define UCOMDIALOUT_MASK 0x80000
#define UCOMCALLUNIT_MASK 0x40000
o The device file minor number is by default
UCOM_CALLOUT_MASK + unit_number
o I tried creating device files with minor numbers of both
0x80000 and 0x80080 but attempt to open produce the error
message "device not configured."
So ... that's that story. Any and all help is greatly appreciated.
Thanks much,
--
-------------------------------------------------------------------------
Charles N. Owens Email: owensc@enc.edu
http://www.enc.edu/~owensc
Senior Technology Officer
Information Technology Services Eastern Nazarene College
-------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E95C751.8050201>