Re: adding devices to puc(4)

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

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.

}   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