From owner-freebsd-i386@FreeBSD.ORG Sat Nov 18 21:20:36 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0768416A407 for ; Sat, 18 Nov 2006 21:20:35 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id D979643D6A for ; Sat, 18 Nov 2006 21:20:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAILKLd5003390 for ; Sat, 18 Nov 2006 21:20:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAILKLeI003384; Sat, 18 Nov 2006 21:20:21 GMT (envelope-from gnats) Date: Sat, 18 Nov 2006 21:20:21 GMT Message-Id: <200611182120.kAILKLeI003384@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: puc-art@oldach.net (Helge Oldach) Cc: Subject: Re: i386/105616: UART PCI device just silent... X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Helge Oldach List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 21:20:36 -0000 The following reply was made to PR i386/105616; it has been noted by GNATS. From: puc-art@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: 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 . 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