[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sparc Ultra60 U2P chip bug
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: Sparc Ultra60 U2P chip bug
- From: wen-king@myri.com (Wen-King Su)
- Date: Sat, 12 Dec 98 19:13:57 PST
- Delivered-To: pcisig@teleport.com
- Resent-Date: Sun, 13 Dec 1998 11:55:28 -0800
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-ID: <"ZYCkM2.0.jv7.R1pSs"@electra.znyx.com>
- Resent-Sender: pci-sig-request@znyx.com
Hello all,
I have looked through sun web site but I couldn't figure out how to report
a hardware bug with the U2P chip. I figure I may get in touch with
somebody in sun through this list.
I have an ultra-60 clone from Tatung we received last week as part of our
64-bit PCI design effort. A 64-bit device samples the REQ64- signal on
the cycle PCI_RST- becomes deasserted. If REQ64- is found to be asserted,
the device assumes it is in a 64-bit slot. If REQ64- is found to be
deasserted, the device assumes it is in a 32-bit slot. I expect to see
something like this in a 64-bit slot:
PCI_RST-: 0000001111111111111111
REQ64- : 0000000111111111111111
This is what is I saw instead:
PCI_RST-: 0000001000011111111111
REQ64- : 0000000111111111111111
Consequently, a spec conforming 64-bit interface in a 64-bit ultra60 slot
will decide it is sitting on a 32-bit bus, and will not generate 64-bit
DMA transactions. Since both signals are generated from the U2P chip,
the problem most likely is in Sun's U2P chip, even if the machine itself
is a clone.
We are revising our design to add a software override register to force
the interface into 64-bit mode. We would like to know if the latter
versions of the U2P chip, or the ones used in higher end ultrasparcs have
the same problem.
- Wen