Sunix 4056A PCI 4 port RS-232 card - only 2 ports configured
John Baldwin
jhb at freebsd.org
Thu May 26 15:39:19 UTC 2011
On Thursday, May 26, 2011 9:42:11 am N.J. Mann wrote:
> Hi Marcel,
>
>
> In message <803C09E5-8E10-4289-A8B3-952E8A72C7A1 at xcllnt.net>,
> Marcel Moolenaar (marcel at xcllnt.net) wrote:
> >
> > On May 25, 2011, at 6:46 AM, John Baldwin wrote:
> >
> > *snip*
> >
> > >> For the two devices that fail, ns8250_bus_probe() fails on the first
> > >> call:
> > >>
> > >> UART4
> > >> -----
> > >> ns8250_bus_probe:: entry
> > >> ns8250_probe::uart_getreg REG_IIR = 1
> > >> ns8250_probe::uart_getreg REG_MCR = 64
> > >> ns8250_bus_probe::ns8250_probe returned 6
> > >>
> > >> UART5
> > >> -----
> > >> ns8250_bus_probe:: entry
> > >> ns8250_probe::uart_getreg REG_IIR = 1
> > >> ns8250_probe::uart_getreg REG_MCR = 64
> > >> ns8250_bus_probe::ns8250_probe returned 6
> > >>
> > >> The value returned for the read of REG_MCR is 64, or 0x40, which causes
> > >> the premature exit:
> > >>
> > >> static int
> > >> ns8250_probe(struct uart_bas *bas)
> > >> {
> > >> u_char val;
> > >>
> > >> /* Check known 0 bits that don't depend on DLAB. */
> > >> val = uart_getreg(bas, REG_IIR);
> > >> if (val & 0x30)
> > >> return (ENXIO);
> > >> val = uart_getreg(bas, REG_MCR);
> > >> if (val & 0xe0)
> > >> return (ENXIO);
> > >>
> > >> return (0);
> > >> }
> > >>
> > >> Do you need to know the contents of 'bas'?
> > >
> > > This goes beyond my level of knowledge. I've cc'd Marcel (author of
uart) who
> > > can hopefully help with this more.
> >
> > The ns8250 family of UARTs typically have bits 5, 6 and 7 of the
> > MCR register reserved and thus hardwired to 0. The probe function
> > checks for that to make sure that the hardware looks enough like
> > a UART that we can claim it without hosing the box.
> >
> > That said: newer chips in the family, like the ST16C850/XR16C850,
> > have given those bits a function:
> > bit 5 - Xon-Any enable
> > bit 6 - Infrared enable
> > bit 7 - Clock pre-scaler
> >
> > It's unclear to me whether those bits are consistently defined
> > across the different implementations (for some reason I think
> > not) and it's also unclear to me whether the device will work
> > correctly with FreeBSD if we simply ignore those bits (again I
> > don't think this is always the case).
> >
> > I think the first order of business from an architectural point
> > of view is to determine how much value register probing still has
> > on modern hardware. In the good old days, this was needed. If
> > we think it's not really needed anymore, then it makes sense to
> > loosen the grip so to speak.
> >
> > For you, the first thing is to see whether the UART ports work
> > if you tweak the probe functions, like so:
> >
> > Index: uart_dev_ns8250.c
> > ===================================================================
> > --- uart_dev_ns8250.c (revision 222217)
> > +++ uart_dev_ns8250.c (working copy)
> > @@ -243,7 +243,7 @@
> > if (val & 0x30)
> > return (ENXIO);
> > val = uart_getreg(bas, REG_MCR);
> > - if (val & 0xe0)
> > + if (val & 0xa0)
> > return (ENXIO);
> >
> > return (0);
>
> I tried this and the result is that ports 3 and 4 now attach okay.
> However, the baud rate of these two is wrong. If I select 9600 they
> actually send and receive at 1200, i.e. eight times slower. The speed
> setting for the first two ports is correct. (I checked all four ports at
> 9600, 38400 and 115200.)
Ah, there are other reports of this:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056533.html
I think this patch should fix the timing issue:
Index: pucdata.c
===================================================================
--- pucdata.c (revision 222285)
+++ pucdata.c (working copy)
@@ -1292,6 +1292,12 @@ puc_config_timedia(struct puc_softc *sc, enum puc_
uint16_t subdev;
switch (cmd) {
+ case PUC_CFG_GET_CLOCK:
+ if (port < 2)
+ *res = DEFAULT_RCLK * 8;
+ else
+ *res = DEFAULT_RCLK;
+ return (0);
case PUC_CFG_GET_DESC:
snprintf(desc, sizeof(desc),
"Timedia technology %d Port Serial", (int)sc->sc_cfg_data);
--
John Baldwin
More information about the freebsd-hardware
mailing list