Re: adding devices to puc(4)

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On May 13, 10:13pm, John Nemeth wrote:
} On May 7,  6:01pm, Masanobu SAITOH wrote:
} } On 2018/05/07 16:38, John Nemeth wrote:
} } >       I'm trying to add an Oxford Semiconductor 4-port serial card
} } > to puc(4).  Using the datasheet, I've gotten to the point where
} } > all four serial ports are probed and attached.  However, I don't
} } > seem to be able to communicate through the ports.  And, there
} } > doesn't seem to be any real documentation on puc(4).  I'm trying
} } > to figure out what the various flags mean.  A URL for the datasheet
} } > is:
} } > 
} } > https://www.semiconductorstore.com/pdf/newsite/oxford/OXPCIe954_ds.pdf
} } 
} }   It seems that the Legacy mode (e.g. I/O mapped) of OXPCIe952 is removed
} } from OXPCIe954. It also seems it has no INTx support, right? Are the device's
} 
}      The datasheet says that INTx is supported.  It also says that
} it is MSI/MSI-X compatible.
} 
} } com registers not 4 byte stride but 1 byte stride?
} 
}      It says that the UARTs are register compatible with the 16C450,
} 16C550, 16C654, and 16C750 UARTs.  After reset, it comes up in
} 16C450 mode.
} 
}      I don't understand the question about stride.  The original
} 8250 used eight I/O ports one after the other.  The OXPCIe954 when
} in the default 16C450 mode has the same set of registers packed
} together one after the other.
} 
}      The dmesg output looks like:
} 
} puc0 at pci9 dev 0 function 0: Oxford Semiconductor OXPCIe954 UART (com, com, com, com)
} com2 at puc0 port 0 (16550-compatible): interrupting at ioapic0 pin 18
} com2: ns16550a, working fifo
} com3 at puc0 port 1 (16550-compatible): interrupting at ioapic0 pin 18
} com3: ns16550a, working fifo
} com4 at puc0 port 2 (16550-compatible): interrupting at ioapic0 pin 18
} com4: ns16550a, working fifo
} com5 at puc0 port 3 (16550-compatible): interrupting at ioapic0 pin 18
} com5: ns16550a, working fifo
} 
} } > Here are the patches that I used to get it started:
} } > 
} } > Index: pcidevs
} } > ===================================================================
} } > RCS file: /cvsroot/src/sys/dev/pci/pcidevs,v
} } > retrieving revision 1.1333
} } > diff -u -r1.1333 pcidevs
} } > --- pcidevs	3 May 2018 04:21:10 -0000	1.1333
} } > +++ pcidevs	7 May 2018 07:58:28 -0000
} } > @@ -6280,6 +6280,7 @@
} } >   product OXFORDSEMI OXPCIE952_4	0xc141	OXPCIe952
} } >   product OXFORDSEMI OXPCIE952_5	0xc144	OXPCIe952
} } >   product OXFORDSEMI OXPCIE952_6	0xc145	OXPCIe952
} } > +product OXFORDSEMI OXPCIE952_7	0xc208	OXPCIe952
} } 
} } Not 952 but 954
} 
}      Oops, right, patch updated.
} 
} } >   /* Packet Engines products */
} } >   product PACKETENGINES GNICII	0x0911	G-NIC II Ethernet
} } > 
} } > Index: pucdata.c
} } > ===================================================================
} } > RCS file: /cvsroot/src/sys/dev/pci/pucdata.c,v
} } > retrieving revision 1.101
} } > diff -u -r1.101 pucdata.c
} } > --- pucdata.c	13 Apr 2018 07:57:04 -0000	1.101
} } > +++ pucdata.c	7 May 2018 07:58:53 -0000
} } > @@ -1108,6 +1108,19 @@
} } >   	    },
} } >   	},
} } >   
} } > +	/* Oxford Semiconductor OXPCIe952 PCIe UARTs */
} } > +	{   "Oxford Semiconductor OXPCIe952 UART",
} } > +	    {	PCI_VENDOR_OXFORDSEMI, PCI_PRODUCT_OXFORDSEMI_OXPCIE952_7,
} } > +		0, 0 },
} } > +	    {	0xffff,	0xffff,	0,	0	},
} } > +	    {
} } > +		{ PUC_PORT_TYPE_COM, PCI_BAR0, 0x1000, COM_FREQ },
} } > +		{ PUC_PORT_TYPE_COM, PCI_BAR0, 0x1200, COM_FREQ },
} } > +		{ PUC_PORT_TYPE_COM, PCI_BAR0, 0x1400, COM_FREQ },
} } > +		{ PUC_PORT_TYPE_COM, PCI_BAR0, 0x1600, COM_FREQ },
} } > +	    },
} } > +	},
} } > +
} } >   	/* Oxford Semiconductor OXmPCI952 PCI UARTs */
} } >   	{   "Oxford Semiconductor OXmPCI952 UARTs",
} } >   	    {	PCI_VENDOR_OXFORDSEMI,	PCI_PRODUCT_OXFORDSEMI_EXSYS_EX41092,
} } > 
} } 
} }   It seems FreeBSD's puc(4) support OXPCIe954, so it will help
} } to see FreeBSD's sys/dev/puc/pucdata.c.
} 
}      Didn't really help as their puc(4) seems to have diverged
} quite a bit from ours.  The struct used to add devices is quite
} different.

     I'm going to take this part back.  After looking at FreeBSD's
pucdata.c again, I keyed in on "DEFAULT_RCLK * 0x22".  After setting
"COM_FREQ * 0x22" I was able to communicate with a device.  I guess
this task is done (apart from cvs ci and pullups) as long as there
isn't anything else special required.  Here are new patches:

Index: pcidevs
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1333
diff -u -r1.1333 pcidevs
--- pcidevs	3 May 2018 04:21:10 -0000	1.1333
+++ pcidevs	14 May 2018 06:24:41 -0000
@@ -6280,6 +6280,7 @@
 product OXFORDSEMI OXPCIE952_4	0xc141	OXPCIe952
 product OXFORDSEMI OXPCIE952_5	0xc144	OXPCIe952
 product OXFORDSEMI OXPCIE952_6	0xc145	OXPCIe952
+product OXFORDSEMI OXPCIE954	0xc208	OXPCIe954
 
 /* Packet Engines products */
 product PACKETENGINES GNICII	0x0911	G-NIC II Ethernet

Index: pucdata.c
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/pucdata.c,v
retrieving revision 1.101
diff -u -r1.101 pucdata.c
--- pucdata.c	13 Apr 2018 07:57:04 -0000	1.101
+++ pucdata.c	14 May 2018 06:25:17 -0000
@@ -1108,6 +1108,19 @@
 	    },
 	},
 
+	/* Oxford Semiconductor OXPCIe954 PCIe UARTs */
+	{   "Oxford Semiconductor OXPCIe954 UART",
+	    {	PCI_VENDOR_OXFORDSEMI, PCI_PRODUCT_OXFORDSEMI_OXPCIE954,
+		0, 0 },
+	    {	0xffff,	0xffff,	0,	0	},
+	    {
+		{ PUC_PORT_TYPE_COM, PCI_BAR0, 0x1000, COM_FREQ * 0x22 },
+		{ PUC_PORT_TYPE_COM, PCI_BAR0, 0x1200, COM_FREQ * 0x22 },
+		{ PUC_PORT_TYPE_COM, PCI_BAR0, 0x1400, COM_FREQ * 0x22 },
+		{ PUC_PORT_TYPE_COM, PCI_BAR0, 0x1600, COM_FREQ * 0x22 },
+	    },
+	},
+
 	/* Oxford Semiconductor OXmPCI952 PCI UARTs */
 	{   "Oxford Semiconductor OXmPCI952 UARTs",
 	    {	PCI_VENDOR_OXFORDSEMI,	PCI_PRODUCT_OXFORDSEMI_EXSYS_EX41092,

} }   If it's a PCIe addin card, could you tell me the product name?
} 
}     It's a StarTech.com PEX4S952.
} 
} } (I don't say I'll work to support it :))
} } 
} } FYI:
} } 		http://mail-index.netbsd.org/tech-kern/2014/02/09/msg016616.html
} } 
} } 	http://mail-index.netbsd.org/tech-kern/2014/01/23/msg016459.html
} } 	(If you're trying to use the device for console, you will modify
} } 	#if 0'd code in the diff.)
} 
}      I don't need to use it as console.
} 
} } sys/dev/ic/com.c has a lof of #ifdefs. Some of them should not be determined
} } at compile time (e.g. COM16650 and COM_REGMAP), but the change is not easy.
} } Please someone(TM) do it.
} } 
} }-- End of excerpt from Masanobu SAITOH
}-- End of excerpt from John Nemeth