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

[gregory.menke at gsfc.nasa.gov]

Karel Gardas writes:
 > 
 > Hello Gregory,
 > 
 > On Wed, 19 Jan 2005 gregory.menke at gsfc.nasa.gov wrote:
 > 
 > >  > At least I have tried to return 0/8/0 in pbus/pdev/pfun(as OpenBSD dmesg
 > >  > advices me) from BSP_pciFindDevice when it tries to find first instance of
 > >  > 10b7/9200 device and now I'm able to get:
 > >  >
 > >  > etherlink: device '3Com 3c905C-TX Fast Etherlink XL', name 'elnk1', pci
 > >  > 00:08.00, 16 rx/16 tx buffers
 > >  >
 > >  > output and then RTEMS freeze. I guess rtems/pci is simply kind of broken
 > >  > on my board and so later (in rtems_elnk_driver_attach function) PCI usage
 > >  > probably returns incorrect values for ioaddr, interrupt and such. The only
 > >  > question is if I hack whole rtems_elnk_driver_attach and set all required
 > >  > parameters manually inside it, if the whole thing will run well and
 > >  > results in elink correctly initialized and attached -- i.e. I don't know
 > >  > anything about PCI bus initialization...
 > >
 > > This means the pci bus tree is not being configured by your bios.
 > > Since the i386 RTEMS bootloader doesn't configure the bus tree, then
 > > the pci address spaces and/or interrupts are not being configured and
 > > the card cannot work.  Simply assuming base address values is probably
 > > not going to help because the pci bus bridges have not been configured
 > > and your i/o transactions will not even make it to the card, and even
 > > if they do, the interrupt vector has not been configured either.
 > 
 > you are probably right, only one thing makes me wonder, my BIOS prints
 > listing of PCI devices together with assigned IRQ before booting OS.
 > 

Thats a good sign.  What I'd try to do now is use the pci read/write
functions you see in pcibios.c to probe the bus, retrieving the device
type, interrupt vector and base addresses.  For pci bridges, you can
look beyond them for other devices on the bus.

Your approach to use Linux/bsd to get bus & slot numbers is good, you
will be able to confirm what your tests show.

To do this, you will need to understand the pci bus a little better;
how the address ranges and configuration transactions work.  If you
look at the pci support in the motorola_shared bsp, you'll see the
routine it uses to compute interrupt vectors, which should be of some
help as far as how config registers are retrieved and updated.  The
motorola_shared bootstrap code handles configuring ranges which might
also be helpful.

Good luck!

Gregm