Date: Mon, 22 Aug 2011 10:33:36 +0200 From: Greg Byshenk <freebsd@byshenk.net> To: freebsd-stable@freebsd.org Cc: David Wood <david@wood2.org.uk> Subject: Re: Serial multiport error Oxford/Startech PEX2S952 Message-ID: <20110822083336.GI92605@core.byshenk.net> In-Reply-To: <20110821222033.GH92605@core.byshenk.net> References: <20110821154249.GE92605@core.byshenk.net> <kI9Z%2BkE54WUOFA36@wood2.org.uk> <20110821222033.GH92605@core.byshenk.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. 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@byshenk.net - Leiden, NL
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110822083336.GI92605>