Date: Mon, 22 Aug 2011 00:20:33 +0200 From: Greg Byshenk <freebsd@byshenk.net> To: David Wood <david@wood2.org.uk> Cc: freebsd-stable@freebsd.org, Greg Byshenk <freebsd@byshenk.net> Subject: Re: Serial multiport error Oxford/Startech PEX2S952 Message-ID: <20110821222033.GH92605@core.byshenk.net> In-Reply-To: <kI9Z%2BkE54WUOFA36@wood2.org.uk> References: <20110821154249.GE92605@core.byshenk.net> <kI9Z%2BkE54WUOFA36@wood2.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 21, 2011 at 09:44:41PM +0100, David Wood wrote:
> I wrote and contributed the support code for the OXPCIe95x serial chips
> - and just happened to notice your report.
Thanks for the response.
> 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"?
I will rebuild my kernel and try.
> >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
Interestingly, it -is- a no-op on the device, which I hadn't noticed.
But trying to set it on the .init fails:
# stty -f /dev/cuau2.init speed 115200
stty: /dev/cuau2.init isn't a terminal 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: <Oxford Semiconductor OXPCIe952 UARTs> mem 0xf9dfc000-0xf9dfffff,0xfa000000-0xfa1fffff,0xf9e00000-0xf9ffffff irq 30 at device 0.0 on pci4
puc0: 2 UARTs detected
uart2: <16950 or compatible> at port 1 on puc0
uart3: <16950 or compatible> at port 2 on puc0
> >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.
I'm rebuilding the kernel, and will try tomorrow with the new version.
I think I'll also try setting the speed on the other end to 9600
(which is what stty reports as the speed) to see if that makes any
difference.
I'll follow up tomorrow. Thanks.
--
greg byshenk - freebsd@byshenk.net - Leiden, NL
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110821222033.GH92605>