modem support MT9234ZPX-PCIE-NV
John Baldwin
jhb at freebsd.org
Fri Jun 3 20:59:38 UTC 2011
On Friday, June 03, 2011 3:00:09 pm Willy Offermans wrote:
> Hello John and FreeBSD friends,
>
> On Fri, Jun 03, 2011 at 09:48:26AM -0400, John Baldwin wrote:
> > On Friday, June 03, 2011 8:34:54 am Willy Offermans wrote:
> > > Dear John and FreeBSD friends,
> > >
> > > On Tue, May 31, 2011 at 11:01:23AM -0400, John Baldwin wrote:
> > > > On Monday, May 30, 2011 5:25:14 am Willy Offermans wrote:
> > > > > Hello John and FreeBSD friends,
> > > > >
> > > > > On Fri, May 27, 2011 at 10:43:34AM -0400, John Baldwin wrote:
> > > > > > On Friday, May 27, 2011 10:38:02 am Willy Offermans wrote:
> > > > > > > Dear John and FreeBSD friends,
> > > > > > >
> > > > > > > On Fri, May 27, 2011 at 08:05:56AM -0400, John Baldwin wrote:
> > > > > > > > On Thursday, May 26, 2011 4:58:37 pm Mike Tancsa wrote:
> > > > > > > > > On 5/26/2011 4:12 PM, John Baldwin wrote:
> > > > > > > > > >
> > > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think this is a similar card. Had it laying about for a while
> > and
> > > > > > > > > popped it in. cu -l to it, attaches, but I am not able to
> > interact with it.
> > > > > > > > >
> > > > > > > > > none3 at pci0:5:0:0: class=0x070002 card=0x20282205
> > chip=0x015213a8
> > > > > > > > > rev=0x02 hdr=0x00
> > > > > > > > > vendor = 'Exar Corp.'
> > > > > > > > > device = 'XR17C/D152 Dual PCI UART'
> > > > > > > > > class = simple comms
> > > > > > > > > subclass = UART
> > > > > > > > > bar [10] = type Memory, range 32, base 0xe8950000, size
> > 1024, enabled
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > NetBSD supposedly has support for this card
> > > > > > > >
> > > > > > > > Oh, hmm, looks like the clock has an unusual multiplier. Does it
> > work if you
> > > > > > > > use 'cu -l -s 1200' to talk at 9600 for example? (In general use
> > speed / 8
> > > > > > > > as the speed to '-s'.)
> > > > > > > >
> > > > > > > > Also, is your card a modem or a dual-port card?
> > > > > > > >
> > > > > > > > --
> > > > > > > > John Baldwin
> > > > > > >
> > > > > > > It is a modem.
> > > > > > >
> > > > > > > As suggested:
> > > > > > >
> > > > > > > kosmos# cu -l /dev/cuau0 -s 1200
> > > > > > > Stale lock on cuau0 PID=3642... overriding.
> > > > > > > Connected
> > > > > > > at&F
> > > > > > > OK
> > > > > > > atdt0045*******
> > > > > > > NO DIALTONE
> > > > > >
> > > > > > Ok, try this updated patch. After this you should be able to use the
> > correct
> > > > > > speed:
> > > > > >
> > > > > > Index: uart_bus_pci.c
> > > > > > ===================================================================
> > > > > > --- uart_bus_pci.c (revision 222285)
> > > > > > +++ uart_bus_pci.c (working copy)
> > > > > > @@ -110,6 +110,8 @@ 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,
> > > > > > + 8 * DEFAULT_RCLK },
> > > > > > { 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
> > > > >
> > > > > The structure you have provided in your magic line would also need
> > > > > some explanation. The data concerns the description of the chip and the
> > > > > card I guess and can be gained by `pciconf -lv`
> > > > >
> > > > > uart0 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
> > > > >
> > > > >
> > > > > A more detailed explanation would not harm. The data 0x10 and
> > > > > 8 * DEFAULT_RCLK are still totally miraculous to me.
> > > >
> > > > 0x10 is the resource id for the first PCI BAR (rids for PCI device
> > resources
> > > > use the offset in PCI config space of the associated BAR). It would
> > perhaps
> > > > be more obvious if uart(4) and puc(4) used PCIR_BAR(0) rather than 0x10.
> > > > Bumping the clock by a multiple of 8 was based on looking at the change in
> > > > NetBSD that Mike Tancsa pointed to and that you verified by noting that
> > > > 'cu -s 1200' connected at 9600 (9600 / 1200 == 8).
> > > >
> > > > One question though, would you be able to test the patch for puc(4) that I
> > > > sent to Mike Tancsa to see if your modem works with puc(4)? The puc(4)
> > > > patch is more general and if it works fine for your modem I'd rather just
> > > > commit that.
> > > >
> > > > --
> > > > John Baldwin
> > >
> > > I have applied the suggested patch.
> > >
> > > The outcome was a new /usr/src/sys/dev/puc/pucdata.c file, which I have
> > > enclosed.
> >
> > Hmm, there was a newer puc patch. Please try this one instead:
> >
> > Index: pucdata.c
> > ===================================================================
> > --- pucdata.c (revision 222565)
> > +++ pucdata.c (working copy)
> > @@ -48,8 +48,8 @@ __FBSDID("$FreeBSD$");
> > #include <dev/puc/puc_bfe.h>
> >
> > static puc_config_f puc_config_amc;
> > -static puc_config_f puc_config_cronyx;
> > static puc_config_f puc_config_diva;
> > +static puc_config_f puc_config_exar;
> > static puc_config_f puc_config_icbook;
> > static puc_config_f puc_config_quatech;
> > static puc_config_f puc_config_syba;
> > @@ -548,11 +548,25 @@ const struct puc_cfg puc_pci_devices[] = {
> > PUC_PORT_8S, 0x18, 0, 8,
> > },
> >
> > + { 0x13a8, 0x0152, 0xffff, 0,
> > + "Exar XR17C/D152",
> > + DEFAULT_RCLK * 8,
> > + PUC_PORT_2S, 0x10, 0, -1,
> > + .config_function = puc_config_exar
> > + },
> > +
> > + { 0x13a8, 0x0154, 0xffff, 0,
> > + "Exar XR17C154",
> > + DEFAULT_RCLK * 8,
> > + PUC_PORT_4S, 0x10, 0, -1,
> > + .config_function = puc_config_exar
> > + },
> > +
> > { 0x13a8, 0x0158, 0xffff, 0,
> > - "Cronyx Omega2-PCI",
> > + "Exar XR17C158",
> > DEFAULT_RCLK * 8,
> > PUC_PORT_8S, 0x10, 0, -1,
> > - .config_function = puc_config_cronyx
> > + .config_function = puc_config_exar
> > },
> >
> > { 0x13a8, 0x0258, 0xffff, 0,
> > @@ -1014,28 +1028,28 @@ puc_config_amc(struct puc_softc *sc, enum puc_cfg_
> > }
> >
> > static int
> > -puc_config_cronyx(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
> > +puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
> > intptr_t *res)
> > {
> > + const struct puc_cfg *cfg = sc->sc_cfg;
> > +
> > if (cmd == PUC_CFG_GET_OFS) {
> > - *res = port * 0x200;
> > + if (cfg->subdevice == 0x1282) /* Everest SP */
> > + port <<= 1;
> > + else if (cfg->subdevice == 0x104b) /* Maestro SP2 */
> > + port = (port == 3) ? 4 : port;
> > + *res = port * 8 + ((port > 2) ? 0x18 : 0);
> > return (0);
> > }
> > return (ENXIO);
> > }
> >
> > static int
> > -puc_config_diva(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
> > +puc_config_exar(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
> > intptr_t *res)
> > {
> > - const struct puc_cfg *cfg = sc->sc_cfg;
> > -
> > if (cmd == PUC_CFG_GET_OFS) {
> > - if (cfg->subdevice == 0x1282) /* Everest SP */
> > - port <<= 1;
> > - else if (cfg->subdevice == 0x104b) /* Maestro SP2 */
> > - port = (port == 3) ? 4 : port;
> > - *res = port * 8 + ((port > 2) ? 0x18 : 0);
> > + *res = port * 0x200;
> > return (0);
> > }
> > return (ENXIO);
> >
> > --
> > John Baldwin
>
> The latter patch seems to work:
>
> From the boot.msg:
>
> <snip>
> ....
> puc0: <Exar XR17C/D152> mem 0xfbfffc00-0xfbffffff irq 16 at device 0.0 on pci6
> puc0: failed to enable port mapping!
> puc0: [FILTER]
> uart0: <16750 or compatible> on puc0
> uart0: [FILTER]
> uart1: <16750 or compatible> on puc0
> uart1: [FILTER]
> ....
> </snip>
>
> As I already pointed out, I do not have a line connected to the modem yet.
> This connection will hopefully be established tomorrow. After some rigorous
> testing I will post a mail with the on stream results. On the other hand,
> if someone knows some off stream testing procedures, then I'm happy to hear
> about that. For the time being I have started minicom and issued:
>
> AT
> AT&F
> ATI
>
> All with positive and already mentioned results.
Ok. So it looks like your modem does indeed have two functioning UARTs. Do
you have any idea what might be on the second UART?
--
John Baldwin
More information about the freebsd-stable
mailing list