How to get a device_t

[John Birrell]

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:

<http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_8634_8635%5E8641,00.html>

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