From owner-freebsd-sparc64@FreeBSD.ORG Mon Jun 9 16:58:42 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44F0737B401; Mon, 9 Jun 2003 16:58:42 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C927643FDD; Mon, 9 Jun 2003 16:58:40 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h5A0UIvm020314; Mon, 9 Jun 2003 20:30:19 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h59NwcSI094334; Mon, 9 Jun 2003 16:58:38 -0700 (PDT) (envelope-from jmg) Message-ID: <20030609165838.32044@hydrogen.funkthat.com> Date: Mon, 9 Jun 2003 16:58:38 -0700 From: John-Mark Gurney To: freebsd-sparc64@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Bk0ad3yNHWXBV/QO" X-Mailer: Mutt 0.69 Organization: Cu Networking X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2003 23:58:42 -0000 --Bk0ad3yNHWXBV/QO Content-Type: text/plain; charset=us-ascii Hello, I've recently started work on making FreeBSD work better on a sparc64 box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz). So far I have found out that the pci bus numbering has problems. We don't attach pci busses as they are numbered in the bridge/OFW info. This causes problems with pciconf -l and pciconf -{w,r} not agreeing. It isn't too hard to tie down the busses to make pciconf agree with itself. The second problem is that this has two SME2300BGA chips on it. They are combo ebus/usb/1394/ethernet chips. The problem is that SUN in order to only have one ebus on the machine, removed function 0 of the device from probing. This means that the other functions of the pci card never get probed. This can be fixed by making sure we probe all the functions on all the devices on the PCI buses. This then gets the second ethernet and USB to probe and attach. Of course the correct way to fix it would be to mirror the OFW tree, and then probe any devices that exist in the OFW tree, but not in our device tree. Attached are the two patches to fix both the issues. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --Bk0ad3yNHWXBV/QO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pci.patch" Index: pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.214 diff -u -r1.214 pci.c --- pci.c 2003/04/16 03:15:08 1.214 +++ pci.c 2003/06/09 23:35:56 @@ -825,7 +825,15 @@ ("dinfo_size too small")); maxslots = PCIB_MAXSLOTS(pcib); for (s = 0; s <= maxslots; s++) { +#ifdef __sparc64__ + /* + * XXX - some sparc hardware has valid hardware when the + * function 0 doesn't probe. Scan all functions. + */ + pcifunchigh = PCI_FUNCMAX; +#else pcifunchigh = 0; +#endif for (f = 0; f <= pcifunchigh; f++) { dinfo = pci_read_device(pcib, busno, s, f, dinfo_size); if (dinfo != NULL) { --Bk0ad3yNHWXBV/QO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="apb.patch" Index: apb.c =================================================================== RCS file: /home/ncvs/src/sys/sparc64/pci/apb.c,v retrieving revision 1.4 diff -u -r1.4 apb.c --- apb.c 2002/03/24 02:10:56 1.4 +++ apb.c 2003/06/09 23:33:07 @@ -207,9 +207,11 @@ * number, we should pick a better value. One sensible alternative * would be to pick 255; the only tradeoff here is that configuration * transactions would be more widely routed than absolutely necessary. + * + * If we don't hardware the bus down, pciconf gets confused. */ if (sc->secbus != 0) { - child = device_add_child(dev, "pci", -1); + child = device_add_child(dev, "pci", sc->secbus); if (child != NULL) return (bus_generic_attach(dev)); } else --Bk0ad3yNHWXBV/QO--