--- wikisrc/users/rkujawa/g-rex.mdwn	2012/07/06 20:00:55	1.6
+++ wikisrc/users/rkujawa/g-rex.mdwn	2012/07/07 11:27:29	1.7
@@ -19,6 +19,9 @@ In case you've noticed an error in this 
 
 # 1. Theory of operation
 
+G-REX is connected to local expansion slot present on CyberStorm PPC and 
+Blizzard PPC.  
+
 G-REX 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
@@ -33,9 +36,13 @@ All memory spaces of G-REX are directly 
 space, unlike in Mediator. Firmware allocates memory space as needed, depending
 on what cards are installed.
 
+Blizzard PPC hardware revision 0 is not compatible with G-REX
+(which revisions are compatible?). 
+
 # 2. Memory map
 
-G-REX is configured as multipie AutoConf boards. Confusingly, they all have the same vendor (8512) and product (101).
+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.
 
@@ -93,20 +100,41 @@ Offset - meaning
 No need to fiddle with these registers, as they've been already configured 
 properly by the firmware.
 
-# 3. Reconfiguring the bus
+# 3. Detecting the G-REX
+
+Since AutoConf entries are created by the firmware, G-REX needs a special 
+firmware for CyberStorm PPC and Blizzard PPC. Known CSPPC firmware revisions 
+supporting G-REX include 44.69 and 44.71.
+
+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
+expained above.
+
+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). 
 
-# 4. Interrupts
+# 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).
 
-# 5. DMA
+# 6. DMA
 
 The bridge is certainly capable of real busmaster DMA, but it needs further 
 reverse engineering.
@@ -119,7 +147,7 @@ to detect revision of the G-REX in softw
 
 G-REX 4000D probably has busmaster DMA capability in all slots.
 
-# 6. Sample PCI bridge driver implementation
+# 7. Sample PCI bridge driver implementation
 
 The NetBSD [[p5pb|http://netbsd.gw.com/cgi-bin/man-cgi?p5pb+4.amiga+NetBSD-current]] 
 driver serves as an example driver implementation. It was written using the 
@@ -135,7 +163,7 @@ The driver consists of several files in 
 
 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).
 
-# 7. Thanks
+# 8. Thanks
 
 [[AmiBay|http://www.amibay.com]] users d0pefish and ramborolf helped testing 
 early versions of p5pb driver. Without their help this document would not