Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Cannot get multiport serial card working with puc driver

47 views
Skip to first unread message

Barry Mishler

unread,
Jan 11, 2008, 1:20:09 AM1/11/08
to freebsd-...@freebsd.org
I have a 4-port serial card (REX-PCI64) made by RATOC Systems that is
apparently only available in Japan. It's based on the EXAR XR17C154
chip. I'd like to use it with tip(1) to support console access to
various Cisco devices.

I've seen posts indicating that the card works natively on NetBSD
because it's already defined in their /sys/dev/pci/pucdata.c file. Yet
I've been completely unable to get it working with any version of
FreeBSD, even after adding an entry to FreeBSD's /sys/dev/puc/pucdata.c
(shown below). I'm currently working with 7.0-RC1.

First of all, it's not clear to me whether I want the uart or sio
driver. I thought sio was the standard but I can only get uart to
attach itself to the device... though I've failed to get anything but
garbage out of a tip session.


I've recompiled the kernel and rebooted countless times in an effort to
understand the process. And so far, this is what I've found:

o The card is probed by the ppc, uart, and sio drivers. Both the
uart and sio drivers fail to enable port mapping, yet the uart driver
succeeds in enabling memory mapping (sio doesn't attempt memory
mapping).

o The pci_enable_io_method (in /sys/dev/pci/pci.c) uses
pci_set_command_bit to enable port mapping by setting the
PCIM_CMD_PORTEN bit, but the following call to PCI_READ_CONFIG says that
the PCIM_CMD_MEMEN bit is instead set, indicating (I suppose) a failure.

o In /sys/dev/uart/uart_dev_ns8250.c, the ns8250_probe function
checks the modem control register (REG_MCR) against a mask of 0xe0. But
this card is (incorrectly?) setting bit 6 of the MCR causing the check
to fail and resulting in the uart driver's decision to not bid on the
device. The docs for the card claim that bit 6 will be 0 so I'm not
sure what to make of this.


If I change ns8250_probe to ignore the fact that bit 6 of the MCR is
set, then I can get the uart driver to attach which provides me with my
/dev/cuau[0-3] entries. But using tip with a real Cisco router just
displays a few hundred 0xff characters on the terminal.


I'm using a GENERIC kernel to which I only added the following two
lines:
options COM_MULTIPORT
device puc

This is what I added to the puc_pci_devices array definition in
pucdata.c:
{ 0x13a8, 0x0154, 0xffff, 0,
"Exar 4-port-PCI XR17C154",
DEFAULT_RCLK,
PUC_PORT_4S, 0x10, 0, -1,
.config_function = puc_config_exar
},
The numbers are derived from NetBSD's data.
The puc_config_exar function appears to be necessary in order to
generate the port offsets. It's identical to the puc_config_cronyx
function and only includes the following code:
if (cmd == PUC_CFG_GET_OFS) {
*res = port * 0x200;
return (0);
}


I'm not sure the full dmesg would provide much useful information, but
at least here's snippet of a verbose boot that looks interesting:

pci4: <ACPI PCI bus> on pcib4
pci4: domain=0, physical bus=4
found-> vendor=0x13a8, dev=0x0154, revid=0x04
domain=0, bus=4, slot=0, func=0
class=07-00-02, hdrtype=0x00, mfdev=0
cmdreg=0x0102, statreg=0x0080, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=11
map[10]: type Memory, range 32, base 0xfe6ff800, size 11, enabled
pcib4: requested memory range 0xfe6ff800-0xfe6fffff: good
pcib4: matched entry for 4.0.INTA
pcib4: slot 0 INTA hardwired to IRQ 16
puc0: <Exar 4-port-PCI XR17C154> mem 0xfe6ff800-0xfe6fffff irq 16 at device 0.0 on pci4
puc0: failed to enable port mapping!
puc0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfe6ff800
puc0: [FILTER]

My main questions at this point are:

1. Do I need the sio driver? Am I wasting my time on the uart driver?
2. Is port mapping necessary? Will memory mapping not give me what I
need?


Any help or hints would be greatly appreciated. I've already spent an
embarrassing amount of time on this and I don't plan on giving up.

Thanks,
Barry

____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

Boris Samorodov

unread,
Jan 11, 2008, 11:25:48 AM1/11/08
to Barry Mishler, freebsd-...@freebsd.org

You didn't show an ARCH you are using (is it amd64?). I've seen
the same message (failed to enable port mapping) only once. The
hardware was an AMD64 processor/motherboard using an i386-FreeBSD-7
(just fine). But when I tried to install and amd64-FreeBSD-7, then it
failed with this diagnostic message (though it was a disc controller
which failed). After some investigation I found a suspiciuos BIOS
option (don't remember for sure, but something like) "enable memory
remapping". That was it -- after enabling, amd64-FreeBSD-7 was
installed.

> puc0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfe6ff800
> puc0: [FILTER]

> My main questions at this point are:

> 1. Do I need the sio driver? Am I wasting my time on the uart driver?

I had to disable sio driver at the kernel config (and add
puc_load="YES" to /boot/loader.conf) to get my card (NetMos 9845 6-x
serial ports) working.

> 2. Is port mapping necessary? Will memory mapping not give me what I
> need?


> Any help or hints would be greatly appreciated. I've already spent an
> embarrassing amount of time on this and I don't plan on giving up.


HTH and WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD committer, http://www.FreeBSD.org The Power To Serve

Boris Samorodov

unread,
Jan 11, 2008, 1:00:57 PM1/11/08
to Barry Mishler, freebsd-...@freebsd.org
On Fri, 11 Jan 2008 19:25:48 +0300 Boris Samorodov wrote:

> > 1. Do I need the sio driver? Am I wasting my time on the uart driver?

> I had to disable sio driver at the kernel config (and add
> puc_load="YES" to /boot/loader.conf) to get my card (NetMos 9845 6-x

Uh, sorry, my memory has faulted here. Loading a module did't help
me. Only did defining puc at a kernel config.

> serial ports) working.

0 new messages