[BACK]Return to g-rex.mdwn CVS log [TXT] [DIR] Up to [NetBSD Developer Wiki] / wikisrc / users / rkujawa

Diff for /wikisrc/users/rkujawa/g-rex.mdwn between versions 1.4 and 1.9

version 1.4, 2012/07/06 19:30:50 version 1.9, 2012/07/08 13:37:51
Line 2 Line 2
   
 Programming the G-REX PCI bridge  Programming the G-REX PCI bridge
   
 document version 0.1 - THIS IS A WORK IN PROGRESS!  document version 0.3 - THIS IS A WORK IN PROGRESS!
   
 # 0. Introduction  # 0. Introduction
   
Line 19  In case you've noticed an error in this  Line 19  In case you've noticed an error in this 
   
 # 1. Theory of operation  # 1. Theory of operation
   
 G-REX is an evolution of PCI bridge used previously on CyberVisionPPC and   # 1a. Hardware 
 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  
 ;-).   
   
 Firmware does the dirty job of assigning PCI resources (BARs, interrupt lines,   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 
   44.71.
   
   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   etc.) before the OS is running. Therefore G-REX does not need any special 
 initialization.  initialization.
   
 # 2. Memory map  # 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.  0xFFFA0000 - PCI I/O register space, 64KB.
   
Line 58  CVPPC/BVPPC there's aslo a mirror on +0x Line 90  CVPPC/BVPPC there's aslo a mirror on +0x
   
 This space offers access to I/O registers of all PCI cards.  This space offers access to I/O registers of all PCI cards.
   
 BAR addresses in this space are treated as relative to 0xFFFA0000. Card with   On G-REX BAR addresses in this space are treated as absolute.
 I/O BAR set to 0x100 will actually be available at 0xFFFA0100.   
   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 
   at 0xFFFA0100. 
   
 # 2c. PCI memory space (0x80000000)  # 2c. PCI memory space (0x80000000)
   
Line 71  For example Voodoo 3, which has two 32MB Line 106  For example Voodoo 3, which has two 32MB
 two 8512/101 boards somewhere at 0x80000000 (or later).  two 8512/101 boards somewhere at 0x80000000 (or later).
   
 Addresses in this space are treated as absolute. Memory BAR register set to   Addresses in this space are treated as absolute. Memory BAR register set to 
 0x80000000 means it is configured at this address.    0x80000000 means it is configured at this address.
   
   On CVPPC/BVPPC this space is present at different address - 0xE0000000.
   
 # 2d. Bridge configuration registers  # 2d. Bridge configuration registers (0xFFFE0000)
   
 Offset - meaning  Offset - meaning
   
Line 81  Offset - meaning Line 118  Offset - meaning
   
 0x0010 - Interrupt enable, write 0x01 to enable interrupts (INT2 on Amiga side)  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.  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, 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
   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   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   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  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).   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   All interrupts are converted into Amiga INT2 interrupt. There's no such thing 
 as interrupt acknowledge register.  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 DMA, but it needs further reverse   The bridge is certainly capable of real busmaster DMA, but it needs further 
 engineering.  reverse engineering.
   
 [TO BE COMPLETED]  [TO BE COMPLETED]
   
 There were at least two different revisions of G-REX 1200. Later revision   
 probably does support DMA in two slots.  
   
 G-REX 4000D probably has busmaster DMA capability in all slots.  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]]   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   driver serves as an example driver implementation. It was written using the 
Line 115  same knowledge that went into this docum Line 172  same knowledge that went into this docum
   
 The driver consists of several files in [[src/sys/arch/amiga/pci|http://nxr.netbsd.org/xref/src/sys/arch/amiga/pci/]] directory.  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.  * p5membar.c - Dummy driver handling AutoConf resources.
 p5membarvar.h - Structures used by the p5membar.  * p5membarvar.h - Structures used by the p5membar.
 p5pb.c - Main driver code.  * p5pb.c - Main driver code.
 p5pbreg.h - Inlcude file containing register locations.  * p5pbreg.h - Inlcude file containing register locations.
 p5pbvar.h - Structures used by the p5pb.  * 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).  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   [[AmiBay|http://www.amibay.com]] users d0pefish and ramborolf helped testing 
 early versions of p5pb driver. Without their help this document would not   early versions of p5pb driver. Without their help this document would not 
Removed from v.1.4  
changed lines
  Added in v.1.9

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb