i386/105616: UART PCI device just silent...

[Helge Oldach]

The following reply was made to PR i386/105616; it has been noted by GNATS.

From: puc-uart at oldach.net (Helge Oldach)
To: xcllnt at mac.com (Marcel Moolenaar)
Cc: FreeBSD-gnats-submit at FreeBSD.org
Subject: Re: i386/105616: UART PCI device just silent...
Date: Tue, 21 Nov 2006 21:16:39 +0100 (CET)

 Helge Oldach:
 >From hmo Sat Nov 18 22:16:56 2006
 >Subject: Re: i386/105616: UART PCI device just silent...
 >In-Reply-To: <04C70C67-60DD-4CF8-A624-E76AC92D5F42 at mac.com> from Marcel Moolenaar at "Nov 18, 2006 10:31:52 am"
 >To: xcllnt at mac.com (Marcel Moolenaar)
 >Date: Sat, 18 Nov 2006 22:16:56 +0100 (CET)
 >Cc: FreeBSD-gnats-submit at FreeBSD.org
 >From: puc-art at oldach.net (Helge Oldach)
 
 >Hi Marcel,
 >
 >Marcel Moolenaar:
 >>On Nov 18, 2006, at 10:14 AM, Helge Oldach wrote:
 >>> So I understand no specific puc(4) attribution needs to be made for
 >>> this card. It is already properly recognized, albeit with misleading
 >>> text in pucdata.c:
 >>>
 >>>         {   "Dolphin Peripherals 4036",
 >>>             {   0x1409, 0x7168, 0,      0       },
 >>>             {   0xffff, 0xffff, 0,      0       },
 >>>             {
 >>>                 { PUC_PORT_TYPE_COM, 0x10, 0x00, COM_FREQ * 8 },
 >>>                 { PUC_PORT_TYPE_COM, 0x10, 0x08, COM_FREQ * 8 },
 >>>             },
 >>>         },
 >>
 >>Hmmm, if puc currently has a clock of 8 times the default, then
 >>we may have another problem. Could you check if puc got it
 >>wrong as it is?
 >
 >Yes, this is the case. I tried with the original pucdata.c as well as
 >original uart_bus_pci.c. I forgot to mention that I am running a rather
 >recent STABLE. CTM'ed just a week ago.
 >
 >I tried to attach with all speeds to cuau2, using cu -s <speed>. This
 >should be a 9600 baud port (it talks to a standard Cisco router console
 >port and works fine at 9600 Baud with sio). Particularly, neither 1200
 >nor 115200 work.
 >
 >I also changed the "COM_FREQ * 8" to just "COM_FREQ", and retried the
 >exercise. Same result: the ports just stay silent.
 >
 >BTW, I would be rather astonished if the latter exercise would change
 >things, as the board works fine under sio(4) attached to puc(4), hence
 >"COM_FREQ * 8" is probably the Right Thing.
 >
 >I also tried swapping the ports (just in case sio and uart disagree on
 >the numbering) - same. Actually I have a Palm serial cradle on the other
 >port, and attaching with cu to it outputs some blank lines immediately
 >after I hit the sync button on the cradle. This is the same port that
 >sio(4) recognizes as "the Palm port".
 >
 >>>> Note also that I have not heard of uart(4) being wrong in
 >>>> classifying the type as 16550, 1660 or otherwise.
 >>> Fine with me. I am not claiming the source mentioned is correct. I
 >>> just say there appears to be some disagreement.
 >>The disagreement may be important. Maybe your card has "false" PCI ids
 >>and is recognized for something it isn't.
 >
 >Well... guessing from the box that it shipped with and the documentation
 >(which labels the board as a #4037 type board) there is indeed a little
 >room for a mismatch. The box says "two 16C550 UART with 32 Byte FIFO"
 >while the documentation says "two 16C650 32FIFO". I suspect the box's
 >mentioning of 16550 is simply marketing blurb.
 >
 >The PCI/UART combo chip is a SUN1889 which AFAIK is indeed specified
 >with 32 Byte FIFO. The serial driver chip is a TI-75232. This appears
 >pretty identical to what the above source mentions. I can send you
 >photos if you like. :-)
 >
 >>Of course, there may also be bugs in the source code that exhibit them-
 >>selves this way. It would be good to find out what it is...
 >
 >Just advise, I can play with this box as I prefer... What strikes me
 >is that sio(4) (also attached to puc(4)) supports the board just fine,
 >while uart(4) apparently doesn't.
 >
 >Regards,
 >Helge
 >