PCI lookup issue: 3c905C-TX not found by RTEMS.

[gregory.menke at gsfc.nasa.gov]

Karel Gardas writes:
 > On Mon, 24 Jan 2005, Joel Sherrill <joel at OARcorp.com> wrote:
 > 
 > > > As far as I know the pc386 pci support has been stable for some time,
 > > > so I think you could do it either way.  I imagine it might be better
 > > > to work off the cvs head in case you come up with enhancements that
 > > > you'd like to commit.
 > >
 > > That's the right answer. :)
 > 
 > OK, but I have 4.6.x up'n'running so if PCI is nearly the same, I will use
 > this for debugging.
 > 
 > And I have first debugging success to report here:
 > I don't know why things were even so good working so far, but pcibios.c
 > initialization seems to be broken at least to my C++ distributed
 > applications programmer eyes. There is `pcibInitialized' static variable
 > which is initialized to 0 and in pcib_init is switched to 1. pcib_init
 > function looks if PCI bios is presented and do very important
 > initialization of `pcibEntry' static variable, which is then used
 > by *_conf_read/write* functions and others.
 > The problem was that pcib_init function was never called which means
 > pcibEntry was not initialized which means all functions using its value to
 > obtain something from PCI bios used completely wrong memory part. When I
 > hack
 > 
 > if (!pcibInitialized)
 >    pcib_init();
 > 
 > into BSP_pciFindDevice function, I'm able to get completelly different
 > values than before and even I'm able to find 10B7/9200 as my NIC. :-)
 > 
 > Well, then the only other issue is that RTEMS after printing:
 > 
 > etherlink: device '3Com 3c905C-TX Fast Etherlink XL', name 'elnk1', pci
 > 00:08.00, 16 rx.16 tx buffers
 > 

Cool.  It sounds like you're getting there- it might not be as big a
problem as it seems.

Since the driver is still hanging, it suggests the address ranges
aren't set up yet.  For the next test, before you try starting the
driver, use the BSP_pciFindDevice function to identify the card and
print the IO base address and interrupt as seen in the lines 3320 thru
24.  The pci operations shown there do reads of the PCI chipset on the
card, returning the IO address and interrupt vector that the 3com
device will be using.  If they aren't set up properly, the board can't
work.

If those values come back reasonable, then I suggest we probe the bus
for bridges and see if they're configured properly.

Gregm