Date: Wed, 22 Nov 2006 04:50:23 GMT From: puc-uart@oldach.net (Helge Oldach) To: freebsd-i386@FreeBSD.org Subject: Re: i386/105616: UART PCI device just silent... Message-ID: <200611220450.kAM4oNPW012458@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/105616; it has been noted by GNATS.
From: puc-uart@oldach.net (Helge Oldach)
To: xcllnt@mac.com (Marcel Moolenaar)
Cc: FreeBSD-gnats-submit@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@mac.com> from Marcel Moolenaar at "Nov 18, 2006 10:31:52 am"
>To: xcllnt@mac.com (Marcel Moolenaar)
>Date: Sat, 18 Nov 2006 22:16:56 +0100 (CET)
>Cc: FreeBSD-gnats-submit@FreeBSD.org
>From: puc-art@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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611220450.kAM4oNPW012458>