Programming the G-REX PCI bridge
document version 0.4
# 0. Introduction
This document describes software/hardware interface of the G-REX PCI bridge
for Amiga computers. What you're reading is a result of reverse engineering,
which was long and difficult process.
Next time when you're going to buy a hardware product for your Amiga, don't
forget to ask the vendor to make the programming documentation publicly
available! Remeber that hardware without software is just a piece of junk...
and you can't write software without hardware documentation.
In case you've noticed an error in this document please let me know.
# 1. Theory of operation
# 1a. Hardware
Three versions of G-REX exist:
* G-REX 1200 (for Amiga 1200 equipped with BlizzardPPC)
* G-REX 4000D (for Amiga 4000 equipped with CyberStormPPC)
* G-REX 4000T (for Amiga 4000T equipped with CyberStormPPC)
There were at least two different revisions of G-REX 1200. Later revision
(marked "Neue Version") probably does support DMA in first two slots. I'm not
sure if it is possible to detect revision of the G-REX in software.
Blizzard PPC hardware revision 0 is not compatible with G-REX
(revision 2 is certainly compatible, not sure about revision 1).
There's a rumor that most G-REX 4000T were recalled due to hardware problem.
G-REX is connected to local expansion slot present on CyberStorm PPC and
Blizzard PPC. These slots have different physical connectors but signals seem
to be mostly the same.
The bridge itself is an evolution of PCI bridge used previously on
CyberVisionPPC and BlizzardVisionPPC cards. These products share a lot of
similiarities (at least when it comes to PCI interface). In fact CVPPC/BVPPC
can be treated as a special one-slot version of G-REX. Maybe actually it's the
other way around ;-).
All memory spaces of G-REX are directly visible and addressable in Amiga memory
space, unlike in Mediator. Firmware allocates memory space as needed, depending
on what cards are installed.
# 1b. Firmware
G-REX firmware is a part of Flash ROM present on Blizzard PPC and CyberStorm
PPC boards. Known CSPPC firmware revisions supporting G-REX include 44.69 and
It does the dirty job of assigning PCI resources (BARs, interrupt lines,
etc.) before the OS is running. Therefore G-REX does not need any special
# 2. Memory map
G-REX is configured as multipie AutoConf boards. Confusingly, they all have the
same vendor (8512) and product (101).
0xFFFA0000 - PCI I/O register space, 64KB.
0xFFFC0000 - PCI configuration space, 128KB.
0xFFFE0000 - Bridge configuration registers, 4kB.
0x80000000 - PCI memory space, variable size and number of boards, depending on cards installed.
# 2a. PCI configuration space (0xFFFC0000)
Access to configuration space is a bit tricky. Be warned that access to
addresses not used by G-REX generates bus error (esp. to configuration
locations which are unused because there is no card in the slot). Depending on
how these errors are supported in your OS, it may be important to trap them and
Configuration data for first slot (device 0) is accessible at offset +0x1000,
location for the next slots can be obtained by shifting the bit:
Configuration space address + (offset << device number)
For example to obtain configuration space for the second slot (device 1):
0xFFFC0000 + (0x1000 << 1) = 0xFFFC2000
For the third slot (device 2):
0xFFFC0000 + (0x1000 << 2) = 0xFFFC4000
and so on.
How to access device functions is not well analyzed, however funtion 0 is
always available at address computed by the above equation. Function 1 is
available at offset +0x100. One could assume that accessing the next
device functions is possible by shifting the bit (as with device access),
but that was not tested, becasue cards with more than two functions are not
On CVPPC/BVPPC configuration space is accessible at offset +0x0 (but there
are also mirrors through whole configuration space).
See [[p5pb_pci_conf_read()|http://nxr.netbsd.org/xref/src/sys/arch/amiga/pci/p5pb.c#p5pb_pci_conf_read]] and [[p5pb_pci_conf_write()|http://nxr.netbsd.org/xref/src/sys/arch/amiga/pci/p5pb.c#p5pb_pci_conf_read]] functions.
# 2b. PCI I/O registers space (0xFFFA0000)
This space offers access to I/O registers of all PCI cards.
On G-REX BAR addresses in this space are treated as absolute.
On CVPPC/BVPPC BAR addresses in this space are treated as relative to
0xFFFA0000. Card with I/O BAR set to 0x100 will actually be available
# 2c. PCI memory space (0x80000000)
This space offers access to memory (and memory-mapped registers) of PCI cards.
Each PCI memory BAR is assigned a separate AutoConf board during firmware
For example Voodoo 3, which has two 32MB memory BARs, will be visible as
two 8512/101 boards somewhere at 0x80000000 (or later).
Addresses in this space are treated as absolute. Memory BAR register set to
0x80000000 means it is configured at this address.
On CVPPC/BVPPC this space is present at different address - 0xE0000000.
# 2d. Bridge configuration registers (0xFFFE0000)
Offset - meaning
0x0000 - Endianness swapper mode, write 0x02 to switch bridge into
big endian mode
0x0010 - Interrupt enable, write 0x01 to enable interrupts (INT2 on Amiga side)
No need to fiddle with these registers, as they've been already configured
properly by the firmware.
# 3. Detecting the G-REX
Since AutoConf entries are created by the firmware, it is not possible to
detect G-REX easily if the correct firmware is not installed.
Detecting the G-REX is done by looking for Phase5 vendor ID (8512) and product
ID 101. Keep in mind that there will be more than one such board present, as
It is possible to misdetect CVPPC/BVPPC as G-REX, since it uses the same vendor
and product ID if G-REX firmware is installed. With older firmware versions
these cards have no associated AutoConf entries.
Differentiating between CVPPC/BVPPC and G-REX in this situation is possible
by looking for Texas Instruments TVP4020 vendor and product ID at the beginning
of PCI configuration space. Configuration data for Permedia 2 chip will be
available at offset 0x0 on CVPPC/BVPPC, but on G-REX first slot is located
at offset 0x1000. See [[p5pb_identify_bridge()|http://nxr.netbsd.org/xref/src/sys/arch/amiga/pci/p5pb.c#p5pb_identify_bridge]]
and [[p5pb_cvppc_probe()|http://nxr.netbsd.org/xref/src/sys/arch/amiga/pci/p5pb.c#p5pb_cvppc_probe]] functions
in the NetBSD driver.
# 4. Reconfiguring the bus
If needed, it's possible to reconfigure bus just by writing new values into
configuration space. Keep in mind that any previously initialized chips will
need to be reset and initialized again (for example 3Dfx Voodoo 3, which is
initialized by the firmware so it can display early startup menu).
# 5. Interrupts
All interrupts are converted into Amiga INT2 interrupt. There's no such thing
as interrupt acknowledge register. However, there seems to be an interrupt
enable register (see "Bridge configuration registers" above).
# 6. DMA
The bridge is certainly capable of real busmaster DMA, but it needs further
[TO BE COMPLETED]
G-REX 4000D probably has busmaster DMA capability in all slots. G-REX 1200 has
busmaster DMA in first or two first slots depending on hardware revision.
# 7. Sample PCI bridge driver implementation
The NetBSD [[!template id=man name="p5pb" section="4" arch="amiga"]]
driver serves as an example driver implementation. It was written using the
same knowledge that went into this document.
The driver consists of several files in [[src/sys/arch/amiga/pci|http://nxr.netbsd.org/xref/src/sys/arch/amiga/pci/]] directory.
* p5membar.c - Dummy driver handling AutoConf resources.
* p5membarvar.h - Structures used by the p5membar.
* p5pb.c - Main driver code.
* p5pbreg.h - Inlcude file containing register locations.
* p5pbvar.h - Structures used by the p5pb.
The p5pb does attach on top of p5bus, however p5membar drivers attach on top of zbus (since 8512/101 entries are seen as Zorro boards).
# 8. Thanks
[[AmiBay|http://www.amibay.com]] users d0pefish, ramborolf and hese helped
testing early versions of p5pb driver. Without their help this document would
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb