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

[gregory.menke at gsfc.nasa.gov]

Karel Gardas writes:
 > On Tue, 18 Jan 2005, Karel Gardas wrote:
 > 
 > > > If neither helps, then I think we'll have to modify things to
 > > > inventory each bus you can talk to, looking for bridges and then
 > > > looking behind them.  We might run across something disabled which is
 > > > limiting access to some downstream busses.  I guess we'll essentially
 > > > be debugging the hack-ed in functions.
 > >
 > > I'm for going this route, since basicaly I would like to use this machine
 > > for RTEMS netwroking testing, as Qemu does not seems to be good for
 > > networking... So any hack how to make 3com NIC recognized is highly
 > > welcome here.
 > 
 > 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.  This
is not the fault of the driver, it assumes the pci bus hardware has
been configured by a previous step in the boot process.

Assuming the diagnostics are correct so far, you have three
alternatives;

- get your motherboard to configure the entire pci bus.  If its
  possible, this will be some setting related to PNP and auto/manual
  resources.  If its not possible to get your motherboard to do this,
  then you may have to use a different motherboard.

- lobby and/or provide resources to enhance the pci support on the x86
  bsp's so a full bus recursion and configuration is done.

- incorporate the pci bus config code from the motorola_shared bsp
  into the x86 bootloader.  It does a full configuration of all
  busses, mapping all hardware and assigning irq's- not unlike what
  Linux/BSD do.  THis is a fairly large project and will probably
  require attention from the respective bsp maintainers.

Gregm