Simon Burge wrote:
> Izumi Tsutsui wrote:
>
>   
>> In article <444B9F98.601@tadpole.com>
>> garrett_damore@tadpole.com wrote:
>>
>>     
>>> Hmm... that's kind of a stumper.  Something must be wrong.  It shows up
>>> on my board:
>>>
>>> aupci0 at aubus0 addr 0x14005000: Alchemy Host-PCI Bridge, 66MHz
>>> pci0 at aupci0 bus 0
>>> pci0: i/o space, memory space enabled
>>> hptide0 at pci0 dev 11 function 0: PCI configuration registers:
>>>   Common header:
>>>     0x00: 0x00071103 0x02300147 0x01040002 0x00008800
>>>
>>> Can you add PCI_CONFIG_DUMP to your  options?
>>>       
>> Or lack of options PCI_NETBSD_CONFIGURE?
>> If it's enabled, it might help to set pci_conf_debug=1
>> in dev/pci/pciconf.c.
>> (is it better to move the option to std.alchemy?)
>>     
>
> Needing PCI_NETBSD_CONFIGURE is a function of what the firmware you have
> on the board does, so this should be a kernel config file option and
> not an std.alchemy option.  It's entirely possible that another Alchemy
> based board has firmware that sets up PCI nicely for us.
>   
Given what I've seen in the YAMON source code, I'd be shocked and amazed
if this were true.  That said, *I* made modifications to YAMON to do
just that, but even in this case I think PCI_NETBSD_CONFIGURE is OK,
because in the worst case the configuration will change between what the
PROM is using and what the kernel uses.  But this will happen after the
kernel is loaded (possibly from a PCI device) and before it starts using
PCI.


> That option (PCI_NETBSD_CONFIGURE) is in DBAU1550, so that shouldn't be
> the issue here.
>   

Yes.  (I had already thought of it and checked for it.)

    -- Garrett

> Cheers,
> Simon.
> --
> Simon Burge                            <simonb@wasabisystems.com>
> NetBSD Support and Service:         http://www.wasabisystems.com/
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191