Serial multiport error Oxford/Startech PEX2S952

[Greg Byshenk]

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