Date: Tue, 27 Dec 2011 18:45:52 -0500 From: "Dieter BSD" <dieterbsd@engineer.com> To: freebsd-drivers@freebsd.org Subject: Re: Attempting to add support for RS-232 card, need help Message-ID: <20111227234554.218240@gmx.com>
next in thread | raw e-mail | index | archive | help
>> I am attempting to add support for a PCI RS-232 card. >> >> http://www.newegg.com/Product/Product.aspx?Item=N82E16815124082 >> >> "PCI two serial ports card with SystemBase Chipset SB16C1052PCI >> Easy Plug & installation automatically selects IRQ and I/O address >> Fully compliant with PCI Local Bus Specification Revision 2.3 >> Supports PCI power management Supports PCI IRQ sharing >> feature, saves valuable resources for other add-on cards Compatible >> with industrial standard 16C550 UART On-chip" >> >> FreeBSD 8.2 >> amd64 >> >> pciconf says: >> none5@pci0:1:10:0: class=0x070002 card=0x4d0214a1 chip=0x4d0214a1 rev=0xb0 hdr=0x00 >> vendor = 'Systembase Co Ltd' >> class = simple comms >> subclass = UART >> bar [10] = type I/O Port, range 32, base 0xa400, size 16, enabled >> bar [14] = type I/O Port, range 32, base 0xa000, size 64, enabled >> cap 01[40] = powerspec 3 supports D0 D3 current D0 >> >> Adding the following to pucdata.c gets it partly working >> >> { 0x14a1, /* vendor - card vendor ID */ >> 0x4d02, /* device - card ID */ >> 0x14a1, /* subvendor - card vendor ID */ >> 0x4d02, /* subvendor - card ID */ >> "Systembase Co Ltd", /* desc */ >> DEFAULT_RCLK, /* clock */ >> PUC_PORT_2S, /* number of ports */ >> 0x10, /* rid - Rid of first port */ >> 0, /* d_rid - Delta rid of next ports */ >> 8, /* d_ofs - Delta offset of next ports */ >> /* config_function */ >> }, >> >> <Systembase Co Ltd> port 0xa400-0xa40f,0xa000-0xa03f irq 17 at device 10.0 on pci1 >> puc0: DEBUG puc.c puc_get_bar(rid=16) Get an unused entry for us to fill. >> puc0: DEBUG puc.c puc_get_bar(rid=-1) found BAR entry >> puc0: DEBUG puc.c puc_get_bar(rid=16) returning bar=0xffffff0001c7b418 >> puc0: DEBUG puc.c puc_get_bar(rid=16) found BAR entry >> puc0: [FILTER] >> uart2: DEBUG rx fifo count = 64 >> uart2: DEBUG rx fifo count = 64 >> <16750 or compatible> on puc0 >> uart2: [FILTER] >> uart3: DEBUG rx fifo count = 64 >> uart3: DEBUG rx fifo count = 64 >> <16750 or compatible> on puc0 >> uart3: [FILTER] >> >> devinfo says: >> puc0 pnpinfo vendor=0x14a1 device=0x4d02 subvendor=0x14a1 subdevice=0x4d02 class=0x070002 at slot=10 function=0 >> Interrupt request lines: >> 17 >> I/O ports: >> 0xa400-0xa40f >> uart2 >> puc0 I/O port mapping: >> 41984-41991 >> puc0 port numbers: >> 1 >> uart3 >> puc0 I/O port mapping: >> 41992-41999 >> puc0 port numbers: >> 2 >> >> cu to the port toggles RTS and DTR. And they go back when exiting cu. >> But if I connect the port to another system (CTS on, CD off), then >> cu hangs when exiting so I have to kill the process. Also, no data >> is transmitted or received, not even garbled data from an incorrect >> baud rate, the TD LED doesn't flicker. The fifo is supposed to be >> 256 bytes but the kernel says 64 (see above debugging printf output). >> >> The mainboard's 2 RS-232 ports work fine. >> >> Is puc the correct driver for this card? >> Do I need a config_function? >> What does [FILTER] (in dmesg) mean? > > You may need to adjust the RCLK for this device. The rest looks correct... I was thinking I might need to change the clock to get correct baud rates, but it affects more than that. I tried all the values found in pucdata.c: 0 doesn't even match card DEFAULT_RCLK * 4 doesn't even match card (seems odd) -1 attach fails -3 attach fails DEFAULT_RCLK attaches, RTS & DTR toggle DEFAULT_RCLK * 8 attaches, RTS & DTR toggle, 1 brief flash of data DEFAULT_RCLK * 10 attaches, RTS & DTR toggle, 1 brief flash of data I also tried DEFAULT_RCLK * 2 attaches, RTS & DTR toggle, 1 brief flash of data DEFAULT_RCLK * 16 attaches, RTS & DTR toggle, 1 brief flash of data DEFAULT_RCLK * 32 attaches, RTS & DTR toggle, 1 brief flash of data 58985400 attaches, RTS & DTR toggle, 1 brief flash of data DEFAULT_RCLK * 32 and 58985400 give different dmesg: uart2: DEBUG rx fifo count = 0 uart2: DEBUG rx fifo count = 0 <Non-standard ns8250 class UART with FIFOs> on puc0 uart2: [FILTER] uart3: DEBUG rx fifo count = 0 uart3: DEBUG rx fifo count = 0 <Non-standard ns8250 class UART with FIFOs> on puc0 uart3: [FILTER] I connected the two ports together with a null modem, and enabled getty on one port. Cu to the other port and the LEDs are all correct. If I then (on another xterm window) cat a big file to the port I get a brief flash on the data LED. But this only works once after a reboot. Even hitting return once at the cu is enough to keep the data line from flashing. (It might be flashing from the return, but too briefly to be visible.) Catting the big file must fill up some buffer, because after that, writes to the port hang. Since I'm using the two ports on the same card, if the baud rate is off it should be off the same on both ports so it should work. Once everything else works I'll check with another port to make sure the baud rates are correct. I suspect that DEFAULT_RCLK will also give the brief flash of data, but the ok-to-reboot window has closed. Is there some way other than trial and error to find out what the clock should be?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111227234554.218240>