Date: Fri, 3 Jun 2011 21:00:09 +0200 From: Willy Offermans <Willy@Offermans.Rompen.nl> To: John Baldwin <jhb@freebsd.org> Cc: Marcel Moolenaar <marcel@freebsd.org>, freebsd-stable@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: modem support MT9234ZPX-PCIE-NV Message-ID: <20110603190009.GA5809@vpn.offrom.nl> In-Reply-To: <201106030948.26246.jhb@freebsd.org> References: <20110521092037.GB3271@vpn.offrom.nl> <201105311101.23905.jhb@freebsd.org> <20110603123454.GB3433@vpn.offrom.nl> <201106030948.26246.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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.
--
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@Offermans.Rompen.nl
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110603190009.GA5809>