PCI enlightenment follow-up

Allen Curtis acurtis at directvinternet.com
Thu Aug 8 09:10:03 EST 2002

> > Yes, but I am beginning to suspect that this is where the problem is. If
> > I/O addresses should not be translated because the in/out() functions
> > automagically add the offset, then perhaps the I/O regions should not be
> > fixed?
> Yep, that's a problem.  Your comment states that
> isa_io_base == io_base_virt.  Yet I see isa_io_base=0x00000000
> and io_base_virt=0x40000000.  You should have isa_io_base=0x40000000.
> You don't want those I/O BARs fixed up as you've suggested above.

I will give this a try but there are several things that bother me:
1. In the 2.4.2 version of this code that works, lspci shows that the I/O region
has been fixed-up.

2. It appears that the ncr_regtest() passes and I am getting reasonable values
from the DSP (script instruction pointer) when using I/O instructions.

3. isa_io_base is set to io_base_virt in pcibios_fixup_bus(). This gives the
fixup routines time to do their thing before the in/out functions reference these
values. (statement in the dump indicates this) I believe I have tested this with
the variable initialization in both places. I am not sure that I have tested it
with version 2 of the sym53c8xx driver, since version 1 is suspenct.

BTW: Could you elaborate on your statement about the 0x40000000 BAT being in the
middle of user task space. I thought all memory was at 0xc0000000. This is how it
is configured under 2.4.2 and it works fine. Is there an updated memory map to


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc-dev mailing list