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-art 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: Sat, 18 Nov 2006 22:16:56 +0100 (CET)

 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