Annotation of wikisrc/users/rkujawa/g-rex.mdwn, revision 1.13

1.1       rkujawa     1: [[!meta title="G-REX"]]
                      2: 
                      3: Programming the G-REX PCI bridge
1.2       rkujawa     4: 
1.11      rkujawa     5: document version 0.4
1.1       rkujawa     6: 
                      7: # 0. Introduction
                      8: 
1.4       rkujawa     9: This document describes software/hardware interface of the G-REX PCI bridge 
                     10: for Amiga computers. What you're reading is a result of reverse engineering, 
                     11: which was long and difficult process. 
                     12: 
                     13: Next time when you're going to buy a hardware product for your Amiga, don't 
                     14: forget to ask the vendor to make the programming documentation publicly 
                     15: available! Remeber that hardware without software is just a piece of junk...
1.1       rkujawa    16: and you can't write software without hardware documentation.
                     17: 
                     18: In case you've noticed an error in this document please let me know. 
                     19: 
                     20: # 1. Theory of operation
                     21: 
1.8       rkujawa    22: # 1a. Hardware 
                     23: 
                     24: Three versions of G-REX exist:
                     25: 
                     26: * G-REX 1200 (for Amiga 1200 equipped with BlizzardPPC)
                     27: * G-REX 4000D (for Amiga 4000 equipped with CyberStormPPC)
                     28: * G-REX 4000T (for Amiga 4000T equipped with CyberStormPPC)
                     29: 
                     30: There were at least two different revisions of G-REX 1200. Later revision 
                     31: (marked "Neue Version") probably does support DMA in first two slots. I'm not 
                     32: sure if it is possible to detect revision of the G-REX in software.
                     33: 
                     34: Blizzard PPC hardware revision 0 is not compatible with G-REX
                     35: (revision 2 is certainly compatible, not sure about revision 1). 
                     36: 
                     37: There's a rumor that most G-REX 4000T were recalled due to hardware problem.
                     38: 
1.7       rkujawa    39: G-REX is connected to local expansion slot present on CyberStorm PPC and 
1.8       rkujawa    40: Blizzard PPC. These slots have different physical connectors but signals seem 
                     41: to be mostly the same.
1.7       rkujawa    42: 
1.8       rkujawa    43: The bridge itself is an evolution of PCI bridge used previously on 
                     44: CyberVisionPPC and BlizzardVisionPPC cards. These products share a lot of 
                     45: similiarities (at least when it comes to PCI interface). In fact CVPPC/BVPPC 
                     46: can be treated as a special one-slot version of G-REX. Maybe actually it's the 
                     47: other way around ;-). 
1.1       rkujawa    48: 
1.5       rkujawa    49: All memory spaces of G-REX are directly visible and addressable in Amiga memory
                     50: space, unlike in Mediator. Firmware allocates memory space as needed, depending
                     51: on what cards are installed.
                     52: 
1.8       rkujawa    53: # 1b. Firmware
                     54: 
                     55: G-REX firmware is a part of Flash ROM present on Blizzard PPC and CyberStorm
                     56: PPC boards. Known CSPPC firmware revisions supporting G-REX include 44.69 and 
                     57: 44.71.
                     58: 
                     59: It does the dirty job of assigning PCI resources (BARs, interrupt lines, 
                     60: etc.) before the OS is running. Therefore G-REX does not need any special 
                     61: initialization.
1.7       rkujawa    62: 
1.1       rkujawa    63: # 2. Memory map
                     64: 
1.7       rkujawa    65: G-REX is configured as multipie AutoConf boards. Confusingly, they all have the 
                     66: same vendor (8512) and product (101).
1.1       rkujawa    67: 
                     68: 0xFFFA0000 - PCI I/O register space, 64KB.
1.2       rkujawa    69: 
1.1       rkujawa    70: 0xFFFC0000 - PCI configuration space, 128KB.
1.2       rkujawa    71: 
1.1       rkujawa    72: 0xFFFE0000 - Bridge configuration registers, 4kB.
                     73: 
                     74: 0x80000000 - PCI memory space, variable size and number of boards, depending on cards installed. 
                     75: 
1.10      rkujawa    76: # 2a. PCI configuration space (0xFFFC0000)
1.1       rkujawa    77: 
1.3       rkujawa    78: Access to configuration space is a bit tricky. Be warned that access to 
                     79: addresses not used by G-REX generates bus error (esp. to configuration 
                     80: locations which are unused because there is no card in the slot). Depending on 
                     81: how these errors are supported in your OS, it may be important to trap them and
                     82: handle correctly. 
1.1       rkujawa    83: 
1.10      rkujawa    84: Configuration data for first slot (device 0) is accessible at offset +0x1000, 
                     85: location for the next slots can be obtained by shifting the bit:
1.1       rkujawa    86: 
1.10      rkujawa    87: Configuration space address + (offset << device number)
                     88: 
                     89: For example to obtain configuration space for the second slot (device 1): 
                     90: 
                     91: 0xFFFC0000 + (0x1000 << 1) = 0xFFFC2000
                     92: 
                     93: For the third slot (device 2): 
                     94: 
                     95: 0xFFFC0000 + (0x1000 << 2) = 0xFFFC4000
                     96: 
                     97: and so on.
                     98: 
                     99: How to access device functions is not well analyzed, however funtion 0 is
                    100: always available at address computed by the above equation. Function 1 is
                    101: available at offset +0x100. One could assume that accessing the next
                    102: device functions is possible by shifting the bit (as with device access),
                    103: but that was not tested, becasue cards with more than two functions are not
                    104: common. 
                    105: 
                    106: On CVPPC/BVPPC configuration space is accessible at offset +0x0 (but there
                    107: are also mirrors through whole configuration space).
                    108: 
                    109: 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. 
1.1       rkujawa   110: 
1.10      rkujawa   111: # 2b. PCI I/O registers space (0xFFFA0000)
1.1       rkujawa   112: 
                    113: This space offers access to I/O registers of all PCI cards.
                    114: 
1.5       rkujawa   115: On G-REX BAR addresses in this space are treated as absolute.
                    116: 
                    117: On CVPPC/BVPPC BAR addresses in this space are treated as relative to 
                    118: 0xFFFA0000. Card with I/O BAR set to 0x100 will actually be available 
                    119: at 0xFFFA0100. 
1.1       rkujawa   120: 
1.4       rkujawa   121: # 2c. PCI memory space (0x80000000)
1.1       rkujawa   122: 
1.3       rkujawa   123: This space offers access to memory (and memory-mapped registers) of PCI cards. 
                    124: Each PCI memory BAR is assigned a separate AutoConf board during firmware 
1.4       rkujawa   125: initialization.
                    126: 
                    127: For example Voodoo 3, which has two 32MB memory BARs, will be visible as 
                    128: two 8512/101 boards somewhere at 0x80000000 (or later).
1.1       rkujawa   129: 
1.3       rkujawa   130: Addresses in this space are treated as absolute. Memory BAR register set to 
1.5       rkujawa   131: 0x80000000 means it is configured at this address.
                    132: 
                    133: On CVPPC/BVPPC this space is present at different address - 0xE0000000.
1.1       rkujawa   134: 
1.8       rkujawa   135: # 2d. Bridge configuration registers (0xFFFE0000)
1.1       rkujawa   136: 
                    137: Offset - meaning
1.3       rkujawa   138: 
1.10      rkujawa   139: 0x0000 - Endianness swapper mode, write 0x02 to switch bridge into 
                    140: big endian mode
1.3       rkujawa   141: 
1.1       rkujawa   142: 0x0010 - Interrupt enable, write 0x01 to enable interrupts (INT2 on Amiga side)
                    143: 
1.6       rkujawa   144: No need to fiddle with these registers, as they've been already configured 
                    145: properly by the firmware.
1.1       rkujawa   146: 
1.7       rkujawa   147: # 3. Detecting the G-REX
                    148: 
1.8       rkujawa   149: Since AutoConf entries are created by the firmware, it is not possible to
                    150: detect G-REX easily if the correct firmware is not installed.
1.7       rkujawa   151: 
                    152: Detecting the G-REX is done by looking for Phase5 vendor ID (8512) and product
                    153: ID 101. Keep in mind that there will be more than one such board present, as
                    154: expained above.
                    155: 
                    156: It is possible to misdetect CVPPC/BVPPC as G-REX, since it uses the same vendor 
                    157: and product ID if G-REX firmware is installed. With older firmware versions 
                    158: these cards have no associated AutoConf entries.
                    159: 
                    160: Differentiating between CVPPC/BVPPC and G-REX in this situation is possible
                    161: by looking for Texas Instruments TVP4020 vendor and product ID at the beginning
                    162: of PCI configuration space. Configuration data for Permedia 2 chip will be
                    163: available at offset 0x0 on CVPPC/BVPPC, but on G-REX first slot is located
1.10      rkujawa   164: at offset 0x1000. See [[p5pb_identify_bridge()|http://nxr.netbsd.org/xref/src/sys/arch/amiga/pci/p5pb.c#p5pb_identify_bridge]] 
                    165: and [[p5pb_cvppc_probe()|http://nxr.netbsd.org/xref/src/sys/arch/amiga/pci/p5pb.c#p5pb_cvppc_probe]] functions
1.7       rkujawa   166: in the NetBSD driver.
                    167: 
                    168: # 4. Reconfiguring the bus
1.1       rkujawa   169: 
1.3       rkujawa   170: If needed, it's possible to reconfigure bus just by writing new values into 
                    171: configuration space. Keep in mind that any previously initialized chips will 
                    172: need to be reset and initialized again (for example 3Dfx Voodoo 3, which is
1.1       rkujawa   173: initialized by the firmware so it can display early startup menu). 
                    174: 
1.7       rkujawa   175: # 5. Interrupts
1.1       rkujawa   176: 
1.3       rkujawa   177: All interrupts are converted into Amiga INT2 interrupt. There's no such thing 
1.5       rkujawa   178: as interrupt acknowledge register. However, there seems to be an interrupt 
                    179: enable register (see "Bridge configuration registers" above).
1.1       rkujawa   180: 
1.7       rkujawa   181: # 6. DMA
1.1       rkujawa   182: 
1.5       rkujawa   183: The bridge is certainly capable of real busmaster DMA, but it needs further 
                    184: reverse engineering.
1.1       rkujawa   185: 
                    186: [TO BE COMPLETED]
                    187: 
                    188: 
1.10      rkujawa   189: G-REX 4000D probably has busmaster DMA capability in all slots. G-REX 1200 has
                    190: busmaster DMA in first or two first slots depending on hardware revision.
1.1       rkujawa   191: 
1.7       rkujawa   192: # 7. Sample PCI bridge driver implementation
1.1       rkujawa   193: 
1.13    ! kim       194: The NetBSD [[!template id=man name="p5pb" section="4" arch="amiga"]] 
1.3       rkujawa   195: driver serves as an example driver implementation. It was written using the 
                    196: same knowledge that went into this document.
                    197: 
                    198: The driver consists of several files in [[src/sys/arch/amiga/pci|http://nxr.netbsd.org/xref/src/sys/arch/amiga/pci/]] directory.
                    199: 
1.6       rkujawa   200: * p5membar.c - Dummy driver handling AutoConf resources.
                    201: * p5membarvar.h - Structures used by the p5membar.
                    202: * p5pb.c - Main driver code.
                    203: * p5pbreg.h - Inlcude file containing register locations.
                    204: * p5pbvar.h - Structures used by the p5pb.
1.3       rkujawa   205: 
                    206: 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).
1.1       rkujawa   207: 
1.7       rkujawa   208: # 8. Thanks
1.4       rkujawa   209: 
1.12      rkujawa   210: [[AmiBay|http://www.amibay.com]] users d0pefish, ramborolf and hese helped 
                    211: testing early versions of p5pb driver. Without their help this document would 
                    212: not exist.
1.4       rkujawa   213: 

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