In article <20010624092100.ECA8E1E4C8@thoreau.thistledown.com.au>
simonb@wasabisystems.com writes:

> From what I understand, arc doesn't use pciconf.c - that's only used
> when you have the PCI_NETBSD_CONFIGURE option in your kernel config.

Yes, I know. BTW, I tried PCI_NETBSD_CONFIGURE on arc,
but it calls pci_decompose_tag(). Of course we can add
it into pci/necpb.c and machine/pci_machdep.h, but
sys/arch/alpha/include/pci_machdep.h claims that
pci_decompose_tag() should not be used in MI code.
Is this comment still correct?

> I'm not that PCI savvy - is the expansion ROM expected to contain x86
> code, and hence is useless on other architectures (unless they supply
> an x86 emulator like Alpha SRM does for vga initialisation)?

Some PCI cards for macppc have the Openfirmware to boot,
so the expansion ROM is used on other than x86 architecture.
I guess the firmware should check if the expansion ROM contains
valid code for the machine before executing/using it.

> Also, given that at least (some?) sip's and siop's are affected, I'm
> wondering if disabling all ROM mapping is the simplest answer (for the
> walnut port).

I'm not sure, but I guess remapping it to proper address is
better answer in general.

> It also begs the questions of why this works on some architectures and
> not others, and what the expansion ROM mapping looks like on those
> architectures where it does and doesn't work.

I think it depends the firmware of machines.
If some machine require BIOS ROM, its firmware would set up
and check it correctly. Maybe some other machines would not.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp