PCI enlightenment follow-up

PCI enlightenment follow-up

[Allen Curtis]

Can anyone tell me what is wrong with the following PCI configuration. The
board configuration and the corresponding boot log has been attached. There
must be a subtle error that I just can not see. At the end of the boot
messages you will find sym53c8xx SCSI device driver initialization messages.
They are not both included in the same build but included here for
completeness.

TIA

BTW: Thanks for all the feedback!

======= Board specs ========
Host phys: 0x40000000 - 0x47ffffff	=>
PCI I/O space 0x00000000 - 0x07ffffff

Host phys: 0x48000000 - 0x4fffffff =>
PCI Memory space 0x00000000 - 0x07ffffff

PCI phys: 0x40000000 -  0x47ffffff =>
Host Memory 0x00000000 - 0x07ffffff

Host Memory:
phys: 0x00000000
virt: 0xc0000000
size: 0x08000000

PCI BAR: (only 1 bus)
Memory: 0x00000000
I/O:    0x00000000

========== Boot Messages ===========
isa_io_base 0x00000000, isa_mem_base 0x48000000, pci_dram_offset 0x40000000
est8260_pci:in sbs8260_find_bridges()
est8260_pci:powerspan_bridge_init
PowerSpan_Bridge_Init()
Setup PCSR registers
setup_powerspan_pci (in): cfg_addr=0xfe800290  cfg_data=0xfe800294
setup_powerspan_pci (out): hose->cfg_addr=0xfe800290
hose->cfg_data=0xfe800294
powerspan_bridge_init() complete.
io_base_virt = 40000000 /* phys == virt due to 1-to-1 BAT mapping for PCI */
est8260_pci: do pciauto_bus_scan()
PCI Autoconfig: Device 15, Vendor 0x1000, Class 0x1000001
PCI Autoconfig: Found Bus 0, Device 15, Function 0
PCI Autoconfig: BAR 0x10, I/O, size=0x100, address=0x7ffff00
PCI Autoconfig: BAR 0x14, Mem size=0x400, address=0x7fffc00
PCI Autoconfig: BAR 0x18, Mem size=0x2000, address=0x7ffc000
est8260_pci:pciauto_bus_scan done
est8260_pci:powerspan_bridge_init
  PCI_ISA_IO_ADDR  0x40000000
  PCI_ISA_IO_SIZE  0x08000000
  PCI_ISA_MEM_ADDR 0x48000000
  PCI_ISA_MEM_SIZE 0x08000000
  PCI_DRAM_OFFSET  0x40000000
  hose->io_resource.start  0x00000000
  hose->io_resource.end    0x07ffffff
  hose->io_space.start     0x00000000
  hose->io_space.end       0x07ffffff
  hose->io_base_phys       0x40000000
  hose->io_base_virt       0x40000000
  isa_io_base              0x00000000
  hose->mem_resources[0].start    0x48000000
  hose->mem_resources[0].end      0x4fffffff
  hose->mem_space.start           0x00000000
  hose->mem_space.end             0x07ffffff
  hose->pci_mem_offset            0x48000000
  isa_mem_base                    0x48000000
  pci_dram_offset                 0x40000000

/* isa_io_base is 0 above so fixup works
 * if (isa_io_base == hose->io_base_virt)
 *    then offset == 0 in fixup and nothing is done
 */

PCI: Probing PCI hardware
pcibios_fixup_resources()
Fixup res 1 (200) of dev 00:00.0: 30000000 -> 78000000
Fixup res 2 (1208) of dev 00:00.0: 40000000 -> 88000000
pcibios_fixup_resources()
/* If (isa_io_base == io_base_virt) then
 *    the I/O fixup does not happen here.
 */
Fixup res 0 (101) of dev 00:0f.0: 7ffff00 -> 47ffff00
Fixup res 1 (200) of dev 00:0f.0: 7fffc00 -> 4ffffc00
Fixup res 2 (200) of dev 00:0f.0: 7ffc000 -> 4fffc000
pcibios_fixup_bus()
Installing Powerspan ERROR handler
PCI ERRCS: MultiErr Cmd: 0xa AERR:0x0002000c
  P1CSR: Rcv_MstrAbort
  P1err: PB_ERR

/* Now that fixup is done set isa_io_base to hose->io_base_virt */
Setting isa_io_base to 0x40000000

pcibios_allocate_bus_resources()
pcibios_allocate_bus_resources()
pcibios_allocate_resources()

/* These are for the PowerSpan and not necessary for operation */
PCI:00:00.0: Resource 1: 78000000-78000fff (f=200) /* I2O BAR */
PCI: Cannot allocate resource region 1 of device 00:00.0
PCI:00:00.0: Resource 2: 88000000-97ffffff (f=1208) /* Reg BAR from PCI */
PCI: Cannot allocate resource region 2 of device 00:00.0

/* SCSI controller resource allocation is fine */
PCI:00:0f.0: Resource 0: 47ffff00-47ffffff (f=101)
PCI:00:0f.0: Resource 1: 4ffffc00-4fffffff (f=200)
PCI:00:0f.0: Resource 2: 4fffc000-4fffdfff (f=200)
pcibios_allocate_resources()
pcibios_assign_resources()
  PCI class: 0x0680
pcibios_update_resource()

/* Not sure where this is coming from */
PCI: Failed to allocate resource 2(50000000-4fffffff) for 00:00.0
  PCI class: 0x0100

/* ==== sym53c8xx version 2 output ==== */
SCSI subsystem driver Revision: 1.00
sym.0.15.0: setting PCI_COMMAND_PARITY...
sym0: <895a> rev 0x1 on pci bus 0 device 15 function 0 irq 19
sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking

/* SCSI initialization fails due to script error, not PCI address access */
CACHE TEST FAILED: DMA error (dstat=0x81).sym0: CACHE INCORRECTLY
CONFIGURED.
sym0: giving up ...

/* ==== sym53c8xx version 1 output ==== */
sym53c8xx: at PCI bus 0, device 15, function 0
sym53c8xx: 0x07fffc00 = pci_get_base_address(base)
sym53c8xx: 0x07ffc000 = pci_get_base_address(base_2)
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: 53c895a detected
sym53c895a-0: rev 0x1 on pci bus 0 device 15 function 0 irq 19
sym53c8xx: device->slot.base = 0x07fffc00
sym53c8xx: device->slot.base_2 = 0x07ffc000
sym53c895a-0: ID 7, Fast-40, Parity Checking
/* vtobus() mapping looks ok */
sym53c8xx: 0x404ba000 = vtobus(0xc04ba000)
sym53c8xx: 0x404bd800 = vtobus(0xc04bd800)
sym53c8xx: np->base2_ba = 0x07ffc000
/* 1-to-1 BAT mapping */
sym53c8xx: 0x4fffc000 = remap_pci_mem(0x4fffc000, 0x00002000)
sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
sym53c8xx: 0xf0ccff07 = cpu_to_scr(0x07ffccf0)
/* ncr_regtest() looks ok */
sym53c8xx: enter ncr_regtest()
sym53c8xx: snooptest() pc = 0x404bddc0, np->reg = 0x4ffffc00
CACHE TEST FAILED: DMA error (dstat=0x81).
  snooptest = 0x404bddc0, pc = 0x404bc008, end = 0x404bdde0
  dmode = 0x00, dcntl = 0x00, ccntl0 = 0x00, ccntl1 = 0x00
CACHE INCORRECTLY CONFIGURED.


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

Re: PCI enlightenment follow-up

[Michel Lanners]

On   6 Aug, this message from Allen Curtis echoed through cyberspace:
> ======= Board specs ========
> Host phys: 0x40000000 - 0x47ffffff	=>
> PCI I/O space 0x00000000 - 0x07ffffff
>
> Host phys: 0x48000000 - 0x4fffffff =>
> PCI Memory space 0x00000000 - 0x07ffffff
>
> PCI phys: 0x40000000 -  0x47ffffff =>
> Host Memory 0x00000000 - 0x07ffffff
>
> Host Memory:
> phys: 0x00000000
> virt: 0xc0000000
> size: 0x08000000
>
> PCI BAR: (only 1 bus)
> Memory: 0x00000000
> I/O:    0x00000000
>
> ========== Boot Messages ===========
> /* SCSI controller resource allocation is fine */
> PCI:00:0f.0: Resource 0: 47ffff00-47ffffff (f=101)
> PCI:00:0f.0: Resource 1: 4ffffc00-4fffffff (f=200)
> PCI:00:0f.0: Resource 2: 4fffc000-4fffdfff (f=200)

OK, obviously, the pci_dev resource regions get set up with the
necessary offset to get to the right address on the PCI bus.

> /* ==== sym53c8xx version 1 output ==== */
> sym53c8xx: at PCI bus 0, device 15, function 0
> sym53c8xx: 0x07fffc00 = pci_get_base_address(base)
> sym53c8xx: 0x07ffc000 = pci_get_base_address(base_2)

sym should _not_ play with these bus-view addresses. Have a look at the
driver where it gets these from.

> sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
> sym53c8xx: 53c895a detected
> sym53c895a-0: rev 0x1 on pci bus 0 device 15 function 0 irq 19
> sym53c8xx: device->slot.base = 0x07fffc00
> sym53c8xx: device->slot.base_2 = 0x07ffc000

Should contain the offset from host to PCI bus. With these addresses,
there's no way to access the SCSI card from the driver.

> sym53c895a-0: ID 7, Fast-40, Parity Checking
> /* vtobus() mapping looks ok */
> sym53c8xx: 0x404ba000 = vtobus(0xc04ba000)
> sym53c8xx: 0x404bd800 = vtobus(0xc04bd800)

Where do these come from? Is that DMA memory?

> sym53c8xx: np->base2_ba = 0x07ffc000
> /* 1-to-1 BAT mapping */
> sym53c8xx: 0x4fffc000 = remap_pci_mem(0x4fffc000, 0x00002000)

This looks good indeed.

> sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
> sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
> sym53c8xx: 0xf0ccff07 = cpu_to_scr(0x07ffccf0)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nope, reversed address. That will not work. Don't touch the address,
touch the data if necessary. What needs to be swapped is data going
_over_ the little-endian PCI bus. Addreses don't go _over_ the bus, they
address resources _on_ the bus.

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

Re: PCI enlightenment follow-up

[Benjamin Herrenschmidt]

>sym should _not_ play with these bus-view addresses. Have a look at the
>driver where it gets these from.

I think it has to. From what I remember the author of the driver told
me, the card need to be programmed to point to it's own memory
or something like that.

>> sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
>> sym53c8xx: 53c895a detected
>> sym53c895a-0: rev 0x1 on pci bus 0 device 15 function 0 irq 19
>> sym53c8xx: device->slot.base = 0x07fffc00
>> sym53c8xx: device->slot.base_2 = 0x07ffc000
>
>Should contain the offset from host to PCI bus. With these addresses,
>there's no way to access the SCSI card from the driver.
>
>> sym53c895a-0: ID 7, Fast-40, Parity Checking
>> /* vtobus() mapping looks ok */
>> sym53c8xx: 0x404ba000 = vtobus(0xc04ba000)
>> sym53c8xx: 0x404bd800 = vtobus(0xc04bd800)
>
>Where do these come from? Is that DMA memory?

Looks like. It's correct provided the infos Allen gave us regarding
his bridge setup are correct.

>> sym53c8xx: np->base2_ba = 0x07ffc000
>> /* 1-to-1 BAT mapping */
>> sym53c8xx: 0x4fffc000 = remap_pci_mem(0x4fffc000, 0x00002000)
>
>This looks good indeed.
>
>> sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
>> sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
>> sym53c8xx: 0xf0ccff07 = cpu_to_scr(0x07ffccf0)
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Nope, reversed address. That will not work. Don't touch the address,
>touch the data if necessary. What needs to be swapped is data going
>_over_ the little-endian PCI bus. Addreses don't go _over_ the bus, they
>address resources _on_ the bus.

Sure of that ? First let's look at what the driver actually does in that
routine. I know that the NCR chips are have bus-masterers ;)

Ben.

>Cheers


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

Re: PCI enlightenment follow-up

[Matt Porter]

On Tue, Aug 06, 2002 at 11:09:17PM +0200, Benjamin Herrenschmidt wrote:
>
> >sym should _not_ play with these bus-view addresses. Have a look at the
> >driver where it gets these from.
>
> I think it has to. From what I remember the author of the driver told
> me, the card need to be programmed to point to it's own memory
> or something like that.

I can confirm that this is true from first-hand experience on embedded
PReP memory map systems (the same non 1:1 CPU<->PCI situation).  In
order to load the scripts the driver must write the PCI address of
the on-chip SRAM to the 53c8xx chip.  In addition, the chip is provided
the bus address of the scripts in system memory and then is commanded to
bus master the load of the scripts into it's on-chip SRAM.  That is
why the PCI bus address is necessary...a long time ago this was all
hacked because most systems (x86, CHRP, etc.) had the simplified world
of having 1:1 mapped CPU<->PCI addresses.  In the past, the pcivtobus
macro was loaded with an architecture specific function to convert
a resource to a PCI bus address...in the current scheme we seem to
have gone backwards (though still functional) to where the driver
get his base address cookie but also directly reads the BAR to get
his PCI base address.  Looks like all is well and good from my
understanding of the world.

> >> sym53c8xx: np->base2_ba = 0x07ffc000
> >> /* 1-to-1 BAT mapping */
> >> sym53c8xx: 0x4fffc000 = remap_pci_mem(0x4fffc000, 0x00002000)
> >
> >This looks good indeed.

Except he's got the 1:1 BAT in the middle of default user task space.
Unless he's used an advanced kernel option tweak to shrink TASK_SIZE,
this will cause problems.

> >> sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
> >> sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
> >> sym53c8xx: 0xf0ccff07 = cpu_to_scr(0x07ffccf0)
> >             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >Nope, reversed address. That will not work. Don't touch the address,
> >touch the data if necessary. What needs to be swapped is data going
> >_over_ the little-endian PCI bus. Addreses don't go _over_ the bus, they
> >address resources _on_ the bus.
>
> Sure of that ? First let's look at what the driver actually does in that
> routine. I know that the NCR chips are have bus-masterers ;)

This is definitely correct. The script engine expects everything little
endian and so on a BE system you see it defined as cpu_to_le32.

It still feels like an address translation issue despite things
looking good from the data we have.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Re: PCI enlightenment follow-up

[Benjamin Herrenschmidt]

>
>> >> sym53c8xx: np->base2_ba = 0x07ffc000
>> >> /* 1-to-1 BAT mapping */
>> >> sym53c8xx: 0x4fffc000 = remap_pci_mem(0x4fffc000, 0x00002000)
>> >
>> >This looks good indeed.
>
>Except he's got the 1:1 BAT in the middle of default user task space.
>Unless he's used an advanced kernel option tweak to shrink TASK_SIZE,
>this will cause problems.

Good spot. Well... I hate those BATs used to map IOs, they just
confuse things a bit more. I've gotten rid of them on pmac
for a long time.

>> >> sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
>> >> sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
>> >> sym53c8xx: 0xf0ccff07 = cpu_to_scr(0x07ffccf0)
>> >             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >Nope, reversed address. That will not work. Don't touch the address,
>> >touch the data if necessary. What needs to be swapped is data going
>> >_over_ the little-endian PCI bus. Addreses don't go _over_ the bus, they
>> >address resources _on_ the bus.
>>
>> Sure of that ? First let's look at what the driver actually does in that
>> routine. I know that the NCR chips are have bus-masterers ;)
>
>This is definitely correct. The script engine expects everything little
>endian and so on a BE system you see it defined as cpu_to_le32.
>
>It still feels like an address translation issue despite things
>looking good from the data we have.


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

RE: PCI enlightenment follow-up

[Allen Curtis]

> >Except he's got the 1:1 BAT in the middle of default user task space.
> >Unless he's used an advanced kernel option tweak to shrink TASK_SIZE,
> >this will cause problems.
>
> Good spot. Well... I hate those BATs used to map IOs, they just
> confuse things a bit more. I've gotten rid of them on pmac
> for a long time.

Where can I find an updated memory map for PPC? The memory configuration
outlined worked fine with 2.4.2. It can be changed easy enough.


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

RE: PCI enlightenment follow-up

[acurtis]

> > ======= Board specs ========
> > Host phys: 0x40000000 - 0x47ffffff	=>
> > PCI I/O space 0x00000000 - 0x07ffffff
> >
> > Host phys: 0x48000000 - 0x4fffffff =>
> > PCI Memory space 0x00000000 - 0x07ffffff
> >
> > PCI phys: 0x40000000 -  0x47ffffff =>
> > Host Memory 0x00000000 - 0x07ffffff
> >
> > Host Memory:
> > phys: 0x00000000
> > virt: 0xc0000000
> > size: 0x08000000
> >
> > PCI BAR: (only 1 bus)
> > Memory: 0x00000000
> > I/O:    0x00000000
> >
> > ========== Boot Messages ===========
> > /* SCSI controller resource allocation is fine */
> > PCI:00:0f.0: Resource 0: 47ffff00-47ffffff (f=101)
> > PCI:00:0f.0: Resource 1: 4ffffc00-4fffffff (f=200)
> > PCI:00:0f.0: Resource 2: 4fffc000-4fffdfff (f=200)
>
> OK, obviously, the pci_dev resource regions get set up with the
> necessary offset to get to the right address on the PCI bus.

Yes, but I am beginning to suspect that this is where the problem is. If the
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?

> > /* ==== sym53c8xx version 1 output ==== */
> > sym53c8xx: at PCI bus 0, device 15, function 0
> > sym53c8xx: 0x07fffc00 = pci_get_base_address(base)
> > sym53c8xx: 0x07ffc000 = pci_get_base_address(base_2)
>
> sym should _not_ play with these bus-view addresses. Have a look at the
> driver where it gets these from.

These are coming directly from the BAR addresses of the device. PCI
configuration space macros. Good addresses for a PCI master to use.

> > sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
> > sym53c8xx: 53c895a detected
> > sym53c895a-0: rev 0x1 on pci bus 0 device 15 function 0 irq 19
> > sym53c8xx: device->slot.base = 0x07fffc00
> > sym53c8xx: device->slot.base_2 = 0x07ffc000
>
> Should contain the offset from host to PCI bus. With these addresses,
> there's no way to access the SCSI card from the driver.

These only need to be offset if you are accessing an external resource.
These values are just fine if you are a PCI bus master, which the SCSI chip
is, and you want to access your own memory.

> > sym53c895a-0: ID 7, Fast-40, Parity Checking
> > /* vtobus() mapping looks ok */
> > sym53c8xx: 0x404ba000 = vtobus(0xc04ba000)
> > sym53c8xx: 0x404bd800 = vtobus(0xc04bd800)
>
> Where do these come from? Is that DMA memory?

vtobus() == virt_to_bus()
PCI_TO_SYS_DRAM = 0x40000000
SYS_DRAM_VIRT   = 0xc0000000
This translation looks fine.

> > sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
> > sym53c8xx: ncr_script_copy_and_bind(src 0xc04f7ce0, dst 0xc04be054)
> > sym53c8xx: 0xf0ccff07 = cpu_to_scr(0x07ffccf0)
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Nope, reversed address. That will not work. Don't touch the address,
> touch the data if necessary. What needs to be swapped is data going
> _over_ the little-endian PCI bus. Addreses don't go _over_ the bus, they
> address resources _on_ the bus.

The SCSI controller is a PCI bus master and script processing engine. The
scripts are retrieved from system memory. The snoop script, for instance, is
constructed by the PPC in system memory and then points the SCSI controller
at it for processing. If you assume that the SCSI contoller is
little-endian, then any addresses need to be byte swapped by the PPC before
the scripts engine can use them. This looks like a SCSI memory location. If
all these assumptions are correct, then this code looks fine too.


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

Re: PCI enlightenment follow-up

[Matt Porter]

On Wed, Aug 07, 2002 at 09:03:53AM -0700, acurtis@directvinternet.com wrote:
>
> > > ======= Board specs ========
> > > Host phys: 0x40000000 - 0x47ffffff	=>
> > > PCI I/O space 0x00000000 - 0x07ffffff
> > >
> > > Host phys: 0x48000000 - 0x4fffffff =>
> > > PCI Memory space 0x00000000 - 0x07ffffff
> > >
> > > PCI phys: 0x40000000 -  0x47ffffff =>
> > > Host Memory 0x00000000 - 0x07ffffff
> > >
> > > Host Memory:
> > > phys: 0x00000000
> > > virt: 0xc0000000
> > > size: 0x08000000
> > >
> > > PCI BAR: (only 1 bus)
> > > Memory: 0x00000000
> > > I/O:    0x00000000
> > >
> > > ========== Boot Messages ===========
> > > /* SCSI controller resource allocation is fine */
> > > PCI:00:0f.0: Resource 0: 47ffff00-47ffffff (f=101)
> > > PCI:00:0f.0: Resource 1: 4ffffc00-4fffffff (f=200)
> > > PCI:00:0f.0: Resource 2: 4fffc000-4fffdfff (f=200)
> >
> > OK, obviously, the pci_dev resource regions get set up with the
> > necessary offset to get to the right address on the PCI bus.
>
> Yes, but I am beginning to suspect that this is where the problem is. If the
> 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.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Re: PCI enlightenment follow-up

[Allen Curtis]

> > Yes, but I am beginning to suspect that this is where the problem is. If
the
> > 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
consult?

TIA

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