On Mon, Aug 22, 2011 at 12:20:33AM +0200, Greg Byshenk wrote:
> 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 at core.byshenk.net>, Greg Byshenk
> > <freebsd at 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 at 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.
Following up:
It appears that indeed, the "options COM_MULTIPORT" is unnecessary
for 9-BETA; I've rebuilt the kernel without it, and the card is
still recognized, along with the ports.
But all it not as it should be. I still can't set the speed on the
card.
> # stty -f /dev/cuau2.init speed 115200 crtscts
> stty: /dev/cuau2.init isn't a terminal
> #
And setting speed on the device itself remains a no-op:
# stty -f /dev/cuau2 speed 115200 crtscts
9600
#
That said, the card -does- seem to work, at least at some level.
With the speed issue pointed out, I set the connection on the
other end to 9600, and then it works. But I'd really like it to
be faster than that (it's just a serial console, so we could
probably live with 9600, though we wouldn't like it).
If there is reason to think that this could be a 9.x issue,
then I could try going to 8.x.
--
greg byshenk - gbyshenk at byshenk.net - Leiden, NL