modem support MT9234ZPX-PCIE-NV
Willy Offermans
Willy at Offermans.Rompen.nl
Fri May 27 07:30:46 UTC 2011
Dear John and FreeBSD friends,
On Thu, May 26, 2011 at 04:12:40PM -0400, John Baldwin wrote:
> On Thursday, May 26, 2011 3:01:35 pm Willy Offermans wrote:
> > Dear John and FreeBSD friends,
> >
> > On Wed, May 25, 2011 at 12:36:30PM -0400, John Baldwin wrote:
> > > On Saturday, May 21, 2011 5:20:37 am Willy Offermans wrote:
> > > > Dear FreeBSD friends,
> > > >
> > > > I need support with a MultiTech modem, MT9234ZPX-PCIE-NV
> > > > (http://www.multitech.com/en_US/PRODUCTS/Families/MultiModemZPX/)
> > > >
> > > > The modem is recognised during the boot event:
> > > >
> > > > <snip>
> > > > pci6: <simple comms, UART> at device 0.0 (no driver attached)
> > > > </snip>
> > > >
> > > > and also appears in the list of found hardware over the PCI bus:
> > > >
> > > > <snip>
> > > > none1 at pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8
> > > rev=0x02 hdr=0x00
> > > > vendor = 'Exar Corp.'
> > > > device = 'XR17C/D152 Dual PCI UART'
> > > > class = simple comms
> > > > subclass = UART
> > > > </snip>
> > > >
> > > > However, as the boot process already mentions, there is no driver attached
> > > > and I cannot get the modem to appear as an accessible and functional
> > > > device. Is there someone, who can help me to get this modem to work?
> > >
> > > Try this patch to sys/dev/uart/uart_bus_pci.c:
> > >
> > > Index: uart_bus_pci.c
> > > ===================================================================
> > > --- uart_bus_pci.c (revision 222248)
> > > +++ uart_bus_pci.c (working copy)
> > > @@ -110,6 +110,7 @@ static struct pci_id pci_ns8250_ids[] = {
> > > { 0x1415, 0x950b, 0xffff, 0, "Oxford Semiconductor OXCB950 Cardbus 16950
> > > UART",
> > > 0x10, 16384000 },
> > > { 0x151f, 0x0000, 0xffff, 0, "TOPIC Semiconductor TP560 56k modem", 0x10 },
> > > +{ 0x13a8, 0x0152, 0x2205, 0x2026, "MultiTech MultiModem ZPX", 0x10 },
> > > { 0x9710, 0x9820, 0x1000, 1, "NetMos NM9820 Serial Port", 0x10 },
> > > { 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 },
> > > { 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10 },
> > >
> > > --
> > > John Baldwin
> >
> > I have applied your suggested patch.
> >
> > Upon reboot the system showed an extra serial device:
> > crw-rw---- 1 uucp dialer 0, 36 May 26 19:13 /dev/cuau0
> > crw-rw---- 1 uucp dialer 0, 37 May 26 19:00 /dev/cuau0.init
> > crw-rw---- 1 uucp dialer 0, 38 May 26 19:00 /dev/cuau0.lock
> > crw-rw---- 1 uucp dialer 0, 55 May 26 19:00 /dev/cuau1
> > crw-rw---- 1 uucp dialer 0, 56 May 26 19:00 /dev/cuau1.init
> > crw-rw---- 1 uucp dialer 0, 57 May 26 19:00 /dev/cuau1.lock
> > crw-rw---- 1 uucp dialer 0, 61 May 26 19:00 /dev/cuau2
> > crw-rw---- 1 uucp dialer 0, 62 May 26 19:00 /dev/cuau2.init
> > crw-rw---- 1 uucp dialer 0, 63 May 26 19:00 /dev/cuau2.lock
> >
> > the boot messages concerning uart were:
> >
> > uart0: failed to enable port mapping!
> > uart0: failed to enable port mapping!
> > uart0: <16750 or compatible> mem 0xfbfffc00-0xfbffffff irq 16 at device 0.0 on pci6
> > uart0: [FILTER]
>
> Hmm, can you get 'pciconf -lb' output?
>
> Hmm, wow, I wonder how uart(4) works at all. It tries to reuse it's softc
> structure in uart_bus_attach() that was setup in uart_bus_probe(). Since it
> doesn't return 0 from its probe routine, that is forbidden. I guess it
> accidentally works because of the hack where we call DEVICE_PROBE() again
> to make sure the device description is correct.
>
> --
> John Baldwin
I guess this is the interesting part:
uart0 at pci0:6:0:0: class=0x070002 card=0x20262205 chip=0x015213a8 rev=0x02 hdr=0x00
bar [10] = type Memory, range 32, base 0xfbfffc00, size 1024, enabled
--
Met vriendelijke groeten,
With kind regards,
Mit freundlichen Gruessen,
Willy
*************************************
W.K. Offermans
Home: +31 45 544 49 44
Mobile: +31 681 15 87 68
e-mail: Willy at Offermans.Rompen.nl
More information about the freebsd-stable
mailing list