I am in the process of implementing PowerSpan PCI support into the 8260 PPC
tree. It appears that all the translations are working but when I try to use
the SYM53C8XX SCSI driver, it fails during the script execution for the
snoop test. I have tried both versions of the SCSI driver with the same
results. The ncr_snoop() test terminates with a script execution error.
Below is a log of the boot messages with debug statements. If anything looks
out of the ordinary please let me know.
======== Log messages =========
isa_io_base 0x00000000, isa_mem_base 0x48000000, pci_dram_offset 0x40000000
Memory BAT mapping: BAT2=128Mb, BAT3=0Mb, residual: 0Mb
/* BAT setup for PCI base = 0x40000000, len = 0x10000000 */
est8260_pci:in sbs8260_find_bridges()
est8260_pci:powerspan_bridge_init
EST8260_PCSR_BASE_ADDR 0x30000000
PCI_ISA_IO_ADDR 0x40000000
PCI_ISA_IO_SIZE 0x08000000
PCI_ISA_MEM_ADDR 0x48000000
PCI_ISA_MEM_SIZE 0x08000000
PCI_DRAM_OFFSET 0x40000000
est8260_pci:powerspan_bridge_init
Setup PCSR registers
/* PCSR setup moves CSR from 0x30000000 -> 0xfe800000 */
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 = 0x40000000
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
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()
Fixup res 0 (101) of dev 00:0f.0: 7ffff00 -> 47ffff00 (I/O)
Fixup res 1 (200) of dev 00:0f.0: 7fffc00 -> 4ffffc00 (Mem)
Fixup res 2 (200) of dev 00:0f.0: 7ffc000 -> 4fffc000 (Mem)
pcibios_allocate_bus_resources()
pcibios_allocate_bus_resources()
pcibios_allocate_resources()
PCI:00:00.0: Resource 1: 78000000-78000fff (f=200)
PCI: Cannot allocate resource region 1 of device 00:00.0 (N/A)
PCI:00:00.0: Resource 2: 88000000-97ffffff (f=1208)
PCI: Cannot allocate resource region 2 of device 00:00.0 (N/A)
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()
PCI: Failed to allocate resource 2(50000000-4fffffff) for 00:00.0
PCI class: 0x0100
SCSI subsystem driver Revision: 1.00
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
sym53c8xx: 0x404ba000 = vtobus(0xc04ba000)
sym53c8xx: 0x404bd800 = vtobus(0xc04bd800)
sym53c8xx: np->base2_ba = 0x07ffc000 /* as read from BAR */
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) /* just byte swapping */
sym53c8xx: enter ncr_regtest()
sym53c8xx: snooptest() pc = 0x404bddc0, np->reg = 0x4ffffc00
CACHE TEST FAILED: DMA error (dstat=0x81). /* Script exec error */
snooptest = 0x404bddc0, pc = 0x404bc008, end = 0x404bdde0
CACHE INCORRECTLY CONFIGURED.
sym53c895a-0: giving up ...
On 5 Aug, this message from acurtis@directvinternet.com echoed through cyberspace:
[snip]
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These two overlap. Firmware in Intel mode with separate IO and mem
spaces?
Fixup res 0 (101) of dev 00:0f.0: 7ffff00 -> 47ffff00 (I/O)
Fixup res 1 (200) of dev 00:0f.0: 7fffc00 -> 4ffffc00 (Mem)
Fixup res 2 (200) of dev 00:0f.0: 7ffc000 -> 4fffc000 (Mem)
OK, now they don't overlap anymore.
sym53c8xx: at PCI bus 0, device 15, function 0
sym53c8xx: 0x07fffc00 = pci_get_base_address(base)
sym53c8xx: 0x07ffc000 = pci_get_base_address(base_2)
What's it doing with these values? Where does it get them from? Those
are the original, un-moved addresses. Both BAR and pci_dev should have
been changed by pcibios_fixup_resources(). Have a look at that code and
see why the corrected base addresses are not written back.
sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
^^^^^^^^^^^^^^^^^^^^^^^^^^
Sym seems to always do this. Not sure it is OK to set it when the
underlying bus doesn't support parity, as in PowerMacs... Could be OK
here, though.
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
^^^^^^^^^^^^
Nope, wrong again.
sym53c8xx: np->base2_ba = 0x07ffc000 /* as read from BAR */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Well, BAR is wrong then. This has been remapped elsewhere.
sym53c8xx: 0x4fffc000 = remap_pci_mem(0x4fffc000, 0x00002000)
^^^^^^^^^^
Ah? Now it's right??
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) /* just byte swapping */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I hope it's not byteswapping an address here?
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/
quoted
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These two overlap. Firmware in Intel mode with separate IO and mem
spaces?
It would appear that these overlap but since we are talking about base
addresses on the PCI bus and different types of bus cycles, it is ok.
quoted
sym53c8xx: at PCI bus 0, device 15, function 0
sym53c8xx: 0x07fffc00 = pci_get_base_address(base)
sym53c8xx: 0x07ffc000 = pci_get_base_address(base_2)
What's it doing with these values? Where does it get them from? Those
are the original, un-moved addresses. Both BAR and pci_dev should have
been changed by pcibios_fixup_resources(). Have a look at that code and
see why the corrected base addresses are not written back.
On the PCI bus itself the Memory and I/O addresses are 0 based so these BAR
values are ok. From the host bus the addresses are 0x4ffffc00 and
0x4fffc000.
quoted
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
^^^^^^^^^^^^
Nope, wrong again.
Yup, these are the BAR's. The host addresses to the PCI bus are translated
into 0 based addresses on the bus.
quoted
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) /* just byte swapping */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I hope it's not byteswapping an address here?
That is a good question. PCI is little-endian, PowerPC is big-endian. When
should the addresses be swapped. When aren't they swapped by the lower
levels?
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On 5 Aug, this message from acurtis@directvinternet.com echoed through cyberspace:
quoted
quoted
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These two overlap. Firmware in Intel mode with separate IO and mem
spaces?
It would appear that these overlap but since we are talking about base
addresses on the PCI bus and different types of bus cycles, it is ok.
Yes, as long as the bridge maps memory and IO to different,
non-ovrlapping memory ranges on the CPU side...
quoted
quoted
sym53c8xx: at PCI bus 0, device 15, function 0
sym53c8xx: 0x07fffc00 = pci_get_base_address(base)
sym53c8xx: 0x07ffc000 = pci_get_base_address(base_2)
What's it doing with these values? Where does it get them from? Those
are the original, un-moved addresses. Both BAR and pci_dev should have
been changed by pcibios_fixup_resources(). Have a look at that code and
see why the corrected base addresses are not written back.
On the PCI bus itself the Memory and I/O addresses are 0 based so these BAR
values are ok. From the host bus the addresses are 0x4ffffc00 and
0x4fffc000.
Hmm, wondering who is supposed to adjust for the offset between CPU and
PCI bus....
quoted
quoted
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
^^^^^^^^^^^^
Nope, wrong again.
Yup, these are the BAR's. The host addresses to the PCI bus are translated
into 0 based addresses on the bus.
OK, but the driver should not use PCI-view addresses, but CPU-view ones.
quoted
quoted
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) /* just byte swapping */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I hope it's not byteswapping an address here?
That is a good question. PCI is little-endian, PowerPC is big-endian. When
should the addresses be swapped. When aren't they swapped by the lower
levels?
You _never_ swap addresses. It's not the address that's different on
little- or big-endian systems, it's the ordering of multi-byte data
values.
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/