Date: Mon, 19 Jun 2006 07:34:07 -0700 From: "Rusty Biesele" <Rusty@takarus.com> To: <freebsd-hardware@freebsd.org> Subject: puc & SIIG & Baud Rates Message-ID: <55E8A262A88DE647A8CBFE4155F513BD534D4D@twinstar.research.takarus.com>
next in thread | raw e-mail | index | archive | help
=20
This is a follow-up to Douglas Rand's post which is=20
attached below. The question he posed was how to patch
pucdata.c for its 10X clock frequency without interfering
with other Oxford Semiconductor chip based cards. I found that
the secondary vendor for the Oxford Chip on the SIIG CyberSerial 4S
is 0x131f, the vendor code for SIIG. By inserting a more specific
entry for the Oxford chip recognizing the secondary vendor code
before the generic entry for the Oxford chips, the SIIG card can
be uniquely recognized without interfering with other manufacturer's
using the Oxford chip.
Here is the diff of my file against the release 6.0 code:
diff pucdata.c-orig pucdata.c
857a858,878
> /* NOTE: This entry must appear before the generic entry
> for the Oxford Semiconductor OX16PCI954 PCI UARTs.
> SIIG uses a non-standard crystal and these entries=20
> may not work with other implementations using Oxford
> chips. This more specific entry will be detected for=20
> SIIG boards and the more generic entry below for=20
> non-SIIG boards. Thanks to Douglas Rand
<rand@meridian-enviro.com>
> for figuring the 10x crystal problem out.=20
> Rusty Biesele <Rusty@takarus.com>.
> */
> { "SIIG Cyber Serial 4S with Oxford Semiconductor OX16PCI954
UARTs",
> { 0x1415, 0x9501, 0x131f, 0 },
> { 0xffff, 0xffff, 0xffff, 0 },
> {
> { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ*10 },
> { PUC_PORT_TYPE_COM, 0x10, 0x08, COM_FREQ*10 },
> { PUC_PORT_TYPE_COM, 0x10, 0x10, COM_FREQ*10 },
> { PUC_PORT_TYPE_COM, 0x10, 0x18, COM_FREQ*10 },
> },
> },
>=20
869d889
<=20
Date: Thu, 25 May 2006 15:20:44 -0500
Message-ID: <87slmxvotf.wl%rand@meridian-enviro.com>
From: "Douglas K. Rand" <rand@meridian-enviro.com>
To: freebsd-hardware@freebsd.org
I'm using a SIIG CyberPro PCI 4S serial card that has a 18.432 MHz
crystal on board rather than the if not standard, VERY common 1.8432
MHz crystal. After talking with SIIG support it seems that most of
their cards use the 10x crystal which cause baud rate mismatches.
I found the hint I needed from a (probably private) message by Kirk
McKusick that was included in this post to freebsd-stable:
=20
http://lists.freebsd.org/pipermail/freebsd-stable/2005-March/013183.html
Here's the pciconf details for the card:
puc0@pci0:13:0: class=3D0x070006 card=3D0x2051131f chip=3D0x95011415 =
rev=3D0x00
hdr=3D0x00
vendor =3D 'Oxford Semiconductor Ltd'
device =3D 'OX16PCI954 Quad UART'
class =3D simple comms
subclass =3D UART
none1@pci0:13:1: class=3D0x068000 card=3D0x0000131f =
chip=3D0x95101415
rev=3D0x00 hdr=3D0x00
vendor =3D 'Oxford Semiconductor Ltd'
device =3D 'OX16PCI954 PCI Interface (disabled)'
class =3D bridge
I tried the following patch to pucdata.c for the card:
--- pucdata.c-orig Thu May 25 15:11:08 2006
+++ pucdata.c Thu May 25 15:11:34 2006
@@ -623,14 +623,14 @@
/* SIIG Cyber 4S PCI 16C650 (20x family): 4S */
{ "SIIG Cyber 4S PCI 16C650 (20x family)",
{ 0x131f, 0x2051, 0, 0 },
{ 0xffff, 0xffff, 0, 0 },
{
- { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
- { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ },
- { PUC_PORT_TYPE_COM, 0x18, 0x00, COM_FREQ },
- { PUC_PORT_TYPE_COM, 0x1c, 0x00, COM_FREQ },
+ { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ * 10 },
+ { PUC_PORT_TYPE_COM, 0x14, 0x00, COM_FREQ * 10 },
+ { PUC_PORT_TYPE_COM, 0x18, 0x00, COM_FREQ * 10 },
+ { PUC_PORT_TYPE_COM, 0x1c, 0x00, COM_FREQ * 10 },
},
},
=20
/* SIIG Cyber 4S PCI 16C850 (20x family): 4S */
{ "SIIG Cyber 4S PCI 16C850 (20x family)",
which didn't do anything to help me. I finally realized that
pciconf -lv is reporting the chip details, not the card details. So, I
tried this patch:
--- pucdata.c-orig Thu May 25 15:11:08 2006
+++ pucdata.c Thu May 25 15:11:34 2006
@@ -858,14 +858,14 @@
/* Oxford Semiconductor OX16PCI954 PCI UARTs */
{ "Oxford Semiconductor OX16PCI954 UARTs",
{ 0x1415, 0x9501, 0, 0 },
{ 0xffff, 0xffff, 0, 0 },
{
- { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ },
- { PUC_PORT_TYPE_COM, 0x10, 0x08, COM_FREQ },
- { PUC_PORT_TYPE_COM, 0x10, 0x10, COM_FREQ },
- { PUC_PORT_TYPE_COM, 0x10, 0x18, COM_FREQ },
+ { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ * 10 },
+ { PUC_PORT_TYPE_COM, 0x10, 0x08, COM_FREQ * 10 },
+ { PUC_PORT_TYPE_COM, 0x10, 0x10, COM_FREQ * 10 },
+ { PUC_PORT_TYPE_COM, 0x10, 0x18, COM_FREQ * 10 },
},
},
=20
/* Oxford Semiconductor OX16PCI954 PCI UARTs */
{ "Oxford Semiconductor OX16PCI954 UARTs",
And this patch makes the card work for me. I also expect that this
patch will break all other vendors that use this Oxford chip on cards
with the 1.8432 MHz crystal. I was wondering if anybody might have
ideas on a better approach for the patch that will fix it for the
card.
I have a query into SIIG tech support for a list of their cards (and
the device IDs) that use the 18.432 crystal.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55E8A262A88DE647A8CBFE4155F513BD534D4D>