From owner-freebsd-hardware@FreeBSD.ORG Sun Jan 25 05:10:36 2004 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3230316A4CE for ; Sun, 25 Jan 2004 05:10:36 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3637D43D60 for ; Sun, 25 Jan 2004 05:10:20 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i0PDA5LE004097; Mon, 26 Jan 2004 00:10:05 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i0PDA3Ef027468; Mon, 26 Jan 2004 00:10:04 +1100 Date: Mon, 26 Jan 2004 00:10:04 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Rick C. Petty" In-Reply-To: <20040125044712.GA20903@megan.kiwi-computer.com> Message-ID: <20040125234651.D31199@gamplex.bde.org> References: <20040125044712.GA20903@megan.kiwi-computer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hardware@freebsd.org Subject: Re: Conexant HCF 56k PCI modem help X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2004 13:10:36 -0000 On Sat, 24 Jan 2004, Rick C. Petty wrote: > For a project, our customer wants to use these 56k PCI modems from > Creative. Although not my first choice, I did some research and discovered > that the modems use a Conexant Systems, Inc. (vendor id 0x14F1) SmartHCF > 56k chip (device id 0x1059). It is not a "winmodem"; the HCF family is > "Controllerless" vs. the HSF "software" chipsets. > ... > I started by adding the following entry to the top of src/dev/puc/pucdata.c: > > { "HCF 56k Data/Fax/Voice Modem (Worldwide)", > NULL, > { 0x14F1, 0x1059, 0x148D, 0x1059 }, > { 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF }, > { > { PUC_PORT_TYPE_UART, 0x10, 0x00, 0, 0 }, > }, > }, > > and the kernel detected the device (puc0) an bootup, but was unable to > attach because it "could not get resource". That last line in the struct > was pure guesswork, based on many other entries. I tried it with > PUC_PORT_TYPE_COM and had the same error. Digging through puc.c I tried > adding PUC_FLAGS_ALTRES to the flags and it found the device, although > sometimes would hang on boot [I guessed various numbers for the "bar" > parameter with varying levels of bootability], so I tried another > approach.. It probably needs mainly the correct "bar" and "offset", and PUC_PORT_TYPE_COM and a nonzero frequency. The "bar" can be inferred from verbose boot messages or "pciconf -r selector 0:0x3f" output (look for nonzero address-like values at offsets 0x10, 0x14, ... up to about 0x24. The "offset" is harder to determine (map the memory pointed to by the bars somehow and look at what is in it) but is usually 0 for the first port. Bruce