From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 6 19:06:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A40237B401 for ; Wed, 6 Aug 2003 19:06:00 -0700 (PDT) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2127343F3F for ; Wed, 6 Aug 2003 19:05:57 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: from freebsd1.cimlogic.com.au (localhost.cimlogic.com.au [127.0.0.1]) by cimlogic.com.au (8.12.9/8.12.9) with ESMTP id h77278AW010907; Thu, 7 Aug 2003 12:07:08 +1000 (EST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.12.9/8.12.9/Submit) id h77278jg010906; Thu, 7 Aug 2003 12:07:08 +1000 (EST) Date: Thu, 7 Aug 2003 12:07:08 +1000 From: John Birrell To: "M. Warner Losh" Message-ID: <20030807120707.C7321@freebsd1.cimlogic.com.au> References: <40313.1060165108@critter.freebsd.dk> <20030806.175045.73337045.imp@bsdimp.com> <20030807113011.B7321@freebsd1.cimlogic.com.au> <20030806.194532.21929682.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030806.194532.21929682.imp@bsdimp.com>; from imp@bsdimp.com on Wed, Aug 06, 2003 at 07:45:32PM -0600 cc: freebsd-hackers@freebsd.org cc: phk@phk.freebsd.dk cc: ticso@cicely.de Subject: Re: How to get a device_t X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2003 02:06:00 -0000 On Wed, Aug 06, 2003 at 07:45:32PM -0600, M. Warner Losh wrote: > Well, I don't know. The PC Cards that we have in the system are > mapped into the I/O and memory ranges traditionally reserved for the > ISA bus. In ISA systems, this made sense because pccard was attached > to pcic was attached to isa. However, now we have situations where > pccard is attached to cbb which is attached to pci. There may be a > isab device with isa bus hanging off of it that makes the relationship > between the pccard devices cousins rather than nephews in the tree. > And there isn't any harm from that. Wouldn't this be a similar > situation? The flash I'm talking about is not pccard related. Sorry if I gave that impression. The SC520 has onboard support to control 3 flash chips. The board I have has 2 Mb NOR flash chip containing BIOS plus a DOS file system (at the moment) where I keep a copy of an etherboot executable. The board also has a 64Mb NAND flash chip which I've written a FreeBSD UFS image into. Our standard bootloader happily loads the kernel from that. Now I need to get a flash driver working for the root file system. I've got an existing read-only flash driver that I used to use on an Intel 386EX board, but that had the entire flash chip memory mapped. This new board maps the NAND flash in 4K pages. > : >From my reading of the AMD docs, only the CPU core is identifiable > : via the CPUID instruction. The docs say that the first two bytes of > : the MMCR are the REVID and those can be used to "identify the device > : itself". The second byte is set to zero to "identify the product as > : the ElanSC520 microcontroller". So if you know the MMCR is there, > : you can go to that byte and get confirmation! Thanks AMD. It seems > : that the discovery via the host to PCI bridge is the only reliable > : way to go. > > Can you send me a URL for that document? I thought I understood > things, but making sure by reading it would sure help. This URL lists the relevent docs: The ones you want are the "ElanSC520 Users Manual" and "ElanSC520 Register Set Manual" >From what I can see, all the SC520 specific things are accessed via the MMCR registers. The direct mapped registers are only for PC/AT compatible stuff, so they are of no help. Then there are the PCI things. To be PCI compatible, AMD *had* to give the host bridge a device ID. That is the _only_ thing given an ID. > But adding it as a child of nexus in the host bridge code wouldn't > make it probe any earlier. To do that you'd need to make it a true > child of nexus with a identify routine that would go out and try to > find the host bridge at a certain address and use the right kind of > bridge there to add the device. You could then map the mmcr space to > a convenient location, and then dole it out to child drivers such that > the bus_space macros would do the right thing. Since it is memory > mapped, this would be relatively easy to do. This would also allow > you to make it known earlier in the boot process. This is also very > much analygous to what pccard and cardbus does. You wouldn't have the > problems that we have with picking resources in the cardbus bridge > code because it looks like the mmcr is at a fixed address (either by > design of the chip or by phk's big stick). > > If you'd like, I can sketch out in code what I'm trying to say in > words here. If you have time, I'd be interested. This is a hot topic for me because it is exactly where I'm up to. I have everything else working on the board. -- John Birrell