The current cardbus code, as I read it, only accesses the expansion rom
data if the configuration code (BIOS or elsewhere) writes a reasonable
address into the BAR register.  I think therefore that using the PCI
code I was suggesting will be OK.  (I.e. having it go ahead and map
expansion roms without enabling them.)


David Laight wrote:

>On Sat, Dec 17, 2005 at 04:02:45PM -0500, Allen Briggs wrote:
>  
>
>>Are the systems that have firmware initializing the bus at issue?
>>    
>>
>
>This is a bigger problem (even for cardbus) that it first appears.
>
>In order to assign some bus space to card (for any purpose) all the
>PCI bridges between the CPU and target must be configured to pass the
>relevant address range through to the actual PCI bus containing the card.
>
>Since PCI bridges (normally) only forward a single range (of each type)
>of addresses to the subsiduary bus, bus space required to map card
>resources must have been allocated when the PCI bridges were initialised.
>
>Unfortunately when OPB/BIOS initialises a system they tend to allocate
>the minimum of resource to each PCI bus.  This makes it very difficult
>to dynamically assign address space to cards for any purpose.
>  
>
It sounds like for these cases, the use of pciconf.c is a bad idea. 
And, frankly, quite likely, these systems do not use the PCI
configuration code that is in NetBSD, since firmware should have already
initialized everything.

>Typically there isn't even a reasonable amount of bus resource reserved
>for use by cardbus cards that are not present at boot time.
>If a cardbus card has a PCI bridge on it, you may well find that there
>are no spare bus-numbers to be assigned to its target bus [1].
>
>So you are unlikely (in general) to be able to find the 64k+ of address
>space on the required bus.
>
>Reworking the entire PCI bus resource allocation is also problematical,
>trying to reset the BAR registers of some VGA cards will lock the system.
>  
>
>Also the BIOS may have cached addresses - and BIOS code does run....
>  
>
Again, these systems have specific PCI configuration requirements, and
therefore should probably not be using the generic PCI configuration code.

Of course, why does BIOS run?  That's realmode stuff, isn't it?  (Now
OpenBoot, I understand.  We have drivers that talk to devices thru OBP. 
I don't know of similar code to do that thru x86 BIOS.)

The generic PCI configuration code that I'm talking about changing is
primarily used for systems without firmware that can assign reasonable
resources to PCI.

    -- Garrett

>	David
>
>[1] Look at the bus number assignments on the Tadpole Voyager and the
>Tadpole/RDI ultrabook(?) both use (much) the same bus structure, but
>have the two 33MHz busses swapped - so one of them (I've forgotten which)
>has no bus numbers assignable to the cardbus slots.
>
>  
>


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134