[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.7 and 1.12

version 1.7, 2012/07/07 11:27:29 version 1.12, 2012/07/12 17:04:33
Line 2 Line 2
   
 Programming the G-REX PCI bridge  Programming the G-REX PCI bridge
   
 document version 0.2 - THIS IS A WORK IN PROGRESS!  document version 0.4
   
 # 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 connected to local expansion slot present on CyberStorm PPC and   # 1a. Hardware 
 Blizzard PPC.    
   
 G-REX is an evolution of PCI bridge used previously on CyberVisionPPC and   Three versions of G-REX exist:
 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,   * G-REX 1200 (for Amiga 1200 equipped with BlizzardPPC)
 etc.) before the OS is running. Therefore G-REX does not need any special   * G-REX 4000D (for Amiga 4000 equipped with CyberStormPPC)
 initialization.  * 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  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  space, unlike in Mediator. Firmware allocates memory space as needed, depending
 on what cards are installed.  on what cards are installed.
   
 Blizzard PPC hardware revision 0 is not compatible with G-REX  # 1b. Firmware
 (which revisions are compatible?).   
   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 
   initialization.
   
 # 2. Memory map  # 2. Memory map
   
Line 52  same vendor (8512) and product (101). Line 73  same vendor (8512) and product (101).
   
 0x80000000 - PCI memory space, variable size and number of boards, depending on cards installed.   0x80000000 - PCI memory space, variable size and number of boards, depending on cards installed. 
   
 # 2a. PCI configuration space (0xFFFA0000)  # 2a. PCI configuration space (0xFFFC0000)
   
 Access to configuration space is a bit tricky. Be warned that access to   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   addresses not used by G-REX generates bus error (esp. to configuration 
Line 60  locations which are unused because there Line 81  locations which are unused because there
 how these errors are supported in your OS, it may be important to trap them and  how these errors are supported in your OS, it may be important to trap them and
 handle correctly.   handle correctly. 
   
 Configuration data for first slot seems to be accessible at offset +0x1000 (on   Configuration data for first slot (device 0) is accessible at offset +0x1000, 
 CVPPC/BVPPC there's aslo a mirror on +0x0).  location for the next slots can be obtained by shifting the bit:
   
 [TO BE COMPLETED]  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): 
   
 # 2b. PCI I/O registers space (0xFFFC0000)  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
   common. 
   
   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.  This space offers access to I/O registers of all PCI cards.
   
Line 89  Addresses in this space are treated as a Line 132  Addresses in this space are treated as a
   
 On CVPPC/BVPPC this space is present at different address - 0xE0000000.  On CVPPC/BVPPC this space is present at different address - 0xE0000000.
   
 # 2d. Bridge configuration registers  # 2d. Bridge configuration registers (0xFFFE0000)
   
 Offset - meaning  Offset - meaning
   
 0x0000 - Endianness swapper mode, write 0x02 to switch bridge into big endian mode  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)  0x0010 - Interrupt enable, write 0x01 to enable interrupts (INT2 on Amiga side)
   
Line 102  properly by the firmware. Line 146  properly by the firmware.
   
 # 3. Detecting the G-REX  # 3. Detecting the G-REX
   
 Since AutoConf entries are created by the firmware, G-REX needs a special   Since AutoConf entries are created by the firmware, it is not possible to
 firmware for CyberStorm PPC and Blizzard PPC. Known CSPPC firmware revisions   detect G-REX easily if the correct firmware is not installed.
 supporting G-REX include 44.69 and 44.71.  
   
 Detecting the G-REX is done by looking for Phase5 vendor ID (8512) and product  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  ID 101. Keep in mind that there will be more than one such board present, as
Line 118  Differentiating between CVPPC/BVPPC and  Line 161  Differentiating between CVPPC/BVPPC and 
 by looking for Texas Instruments TVP4020 vendor and product ID at the beginning  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  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  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  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.  in the NetBSD driver.
   
 # 4. Reconfiguring the bus  # 4. Reconfiguring the bus
Line 141  reverse engineering. Line 185  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 first two slots. I'm not sure if it is possible  
 to detect revision of the G-REX in software.  
   
 G-REX 4000D probably has busmaster DMA capability in all slots.  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  # 7. Sample PCI bridge driver implementation
   
Line 165  The p5pb does attach on top of p5bus, ho Line 207  The p5pb does attach on top of p5bus, ho
   
 # 8. Thanks  # 8. Thanks
   
 [[AmiBay|http://www.amibay.com]] users d0pefish and ramborolf helped testing   [[AmiBay|http://www.amibay.com]] users d0pefish, ramborolf and hese helped 
 early versions of p5pb driver. Without their help this document would not   testing early versions of p5pb driver. Without their help this document would 
 exist.  not exist.
   
Removed from v.1.7  
changed lines
  Added in v.1.12

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