Hi Greg,
I wrote and contributed the support code for the OXPCIe95x serial chips
- and just happened to notice your report.
In message <20110821154249.GE92605@core.byshenk.net>, Greg Byshenk
<freebsd@byshenk.net> writes>I'm having a problem with a StarTech PEX2S952 dual-port serial
>card.
>
>I believe that it should be supported, as it has this entry in
>pucdata.c
>
>[...]
> { 0x1415, 0xc158, 0xffff, 0,
> "Oxford Semiconductor OXPCIe952 UARTs",
> DEFAULT_RCLK * 0x22,
> PUC_PORT_NONSTANDARD, 0x10, 0, -1,
> .config_function = puc_config_oxford_pcie
> },
>[...]
It should be supported. The OXPCIe952 is more awkward to support than
the OXPCIe954 and OXPCIe958 because it can be configured in so many
different ways by the board manufacturer. However, 0xc158 is
configuration that is identical in arrangement as the larger chips, so
is the configuration I'm most confident of. I've just double-checked the
data sheets, and can't see any relevant differences between 0xc158
OXPCIe952 and the OXPCIe954 I tested the code with.
I use my OXPCIe954 board on FreeBSD 8.2, and have had success reports
from other OXPCIe954 and OXPCIe958 board users (including someone with a
16 port board based on dual OXPCIe958s). I have yet to try FreeBSD 9.x
on my hardware.
>And, while it is recognized at boot -- after adding
>
> device puc
> options COM_MULTIPORT
I'm 99% certain that "options COM_MULTIPORT" relates to the old
sio(4)
code - I certainly don't need it on 8.x. Does it make any difference if
you delete that line and just leave "device puc"?
>to my kernel, it doesn't seem to be working. The devices
'/dev/cuau2'
>and '/dev/cuau3' show up, and I can connect to them, but they
don't
>seem to pass any traffic. If I connect to the serial console of
>another machine (one that I know for certain is working), I get
>nothing at all.
Have you remembered to set the speed (and other relevant options) on the
.init devices? This is a feature (or is it a quirk) of the uart(4)
driver that catches many people out. Setting options on the base device
is normally a no-op.
For example, if the remote device on /dev/cuau2 operates at 115200 bps
with hardware handshaking, try:
stty -f /dev/cuau2.init speed 115200 crtscts
One frustrating aspect of adding puc(4) support for many devices is that
you can't be certain of the clock rate multiplier - the same device can
crop up on a different manufacturer's board with a different multiplier.
This problem doesn't occur with the OXPCIe95x devices as they derive
their 62.5MHz UART clock from the PCI Express clock. Consequently, the
problem can't be that your board inadvertently operating the UARTs at
the wrong speed.
>I suspect (?) that it may not be recognized as the proper card. Boot
>and pciconf messages are:
>
>puc0: <Oxford Semiconductor OXPCIe952 UARTs> mem
>0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq
>30 at device 0.0 on pci4
That is correct. Are there any more lines afterwards - especially one
giving the number of UARTs detected? That line is crucial, as, on these
chips, the number of UARTs has to be read from configuration space
because you can slave two chips together.
My OXPCIe954 board is recognised thus (FreeBSD 8.2 amd64):
puc0: <Oxford Semiconductor OXPCIe954 UARTs> mem
0xd5efc000-0xd5efffff,0xd5c00000-0xd5dfffff,0xd5a00000-0xd5bfffff irq 18
at device 0.0 on pci8
puc0: 4 UARTs detected
puc0: [FILTER]
uart2: <16950 or compatible> on puc0
uart2: [FILTER]
uart3: <16950 or compatible> on puc0
uart3: [FILTER]
uart4: <16950 or compatible> on puc0
uart4: [FILTER]
uart5: <16950 or compatible> on puc0
uart5: [FILTER]
>puc0@pci0:4:0:0: class=0x070002 card=0xc1581415 chip=0xc1581415
>rev=0x00 hdr=0x00
> vendor = 'Oxford Semiconductor Ltd'
> class = simple comms
> subclass = UART
> bar [10] = type Memory, range 32, base 0xf9dfc000, size 16384, enabled
> bar [14] = type Memory, range 32, base 0xfa000000, size 2097152,
enabled
> bar [18] = type Memory, range 32, base 0xf9e00000, size 2097152,
enabled
That is correct.
>The kernel is actually FreeBSD 9.0-BETA1 amd64, which is not quite
>'STABLE' yet, but I don't think that this should matter.
>
>Any advice would be much appreciated. The machine is still in
>test phase, so I can mess around with it as necessary.
Hopefully this gets your Startech board working. I look forward to your
feedback.
If all else fails, the board I'm using is Lindy 51189. It's a OXPCIe954
board, offering four ports via a breakout cable, and is normally pretty
cheap direct from lindy.com (quite possibly cheaper than your two port
Startech board!). However, this recommendation comes with the proviso
that I haven't yet tried it with FreeBSD 9.x.
With best wishes,
David
--
David Wood
david@wood2.org.uk