From owner-freebsd-hackers Sat Aug 25 17:47: 0 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 5D7D737B40C for ; Sat, 25 Aug 2001 17:46:56 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f7Q0prn21818; Sat, 25 Aug 2001 17:51:53 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108260051.f7Q0prn21818@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: djohnson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCI Enumeration In-reply-to: Your message of "Sat, 25 Aug 2001 08:31:31 MDT." <3B87B6C3.E5DDBB12@faradayco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Aug 2001 17:51:52 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I am working on an embedded FreeBSD (4.2) device with proprietary PCI > devices on the bus.. I don't have a FreeBSD background and am having > trouble finding the right underlying code to hook into, for what we need > to do. Basically two things need to happen: > > 1) Need to be able to enumerate the PCI bus and printf as much > information about bus devices as possible (sort of like what > pcisupport.c does). Preferrably this would do the enumeration without > going to BIOS for it, but BIOS calls may be acceptable. So, which of > the several (sort of undocumented) underlying pci code modules are > preferred, for: (a) getting the raw data, and (b) for converting it to > human form? It's not clear where exactly you want to do this, but look at the 'pciconf' utility, which already knows how to read PCI configuration space via the defined kernel interfaces. > 2) I also need to be able to perform basic write-read tests on devices > on the bus, both in memory space and I/O space. Upsetting the hardware > during these tests is acceptable. I/O space is easy, but memory space is hard. Userspace access to physical memory is a big no-no in the *nix world. Typically for this you'd want to write a device driver (build it as a loadable module) that attaches to the hardware you want to test. There are lots of examples of this in the system already. If you have more specific questions, feel free to ask them... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message