Subject: Re: access to external proms for PCI
To: Allen Briggs <briggs@netbsd.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 12/17/2005 13:51:56
Allen Briggs wrote:

>On Sat, Dec 17, 2005 at 12:56:53PM -0800, Jason Thorpe wrote:
>  
>
>>>Actually, I'd kind of rather see:
>>>	PCI_CONF_MAP_ROM	maps but does not enable the ROM
>>>	PCI_CONF_ENABLE_ROM	implies PCI_CONF_MAP_ROM and also enables
>>>				the space
>>>	clear			Neither maps or enables the ROM
>>>      
>>>
>>How does this bring us closer to unifying PCI and CardBus?
>>
>>Also, this seems kind of bad for e.g. ports that don't use the  
>>kernel's PCI configuration code (relying on system firmware to do it,  
>>instead).  And, you can't really, at the system level, blindly set  
>>PCI_CONF_ENABLE_ROM anyway, because of the broken PCI device problem.
>>    
>>
>
>OK.  So how about just changing the PCI configuration code to not
>enable the ROM after it's mapped?
>  
>
I like this.  But then pci_mapreg_map() should go ahead and enable it if
PCI_MAPREG_TYPE_ROM is used.

>Are the systems that have firmware initializing the bus at issue?
>  
>
I can imagine one possible bad thing.  That is systems that use OpenBoot
and use OpenBoot proms.  On those systems, maybe the mapping for the
roms shouldn't be touched.  But one would guess that those systems maybe
shouldn't use the common pci bus configuration logic.

Also, I don't know if OpenBoot copies FCode from ROMs and caches it in
system memory or if it just loads it directly.  (In other words, how
would OBP be impacted.)

PC systems should not be using the BIOS at all, since we are running
fully protected mode.

Anyone know anything about PA-RISC systems?  This is the only other
architecture for which PCI specifies a ROM type.

>What would you suggest for bringing us closer to unifying PCI and CardBus?
>  
>
I think the cardbus code could just go ahead use pci_mapreg_map.  That
would should solve that particular problem.

    -- Garrett

>-allen
>
>  
>


-- 
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