--- wikisrc/users/rkujawa/g-rex.mdwn 2012/07/04 18:24:04 1.2 +++ wikisrc/users/rkujawa/g-rex.mdwn 2020/09/09 16:20:21 1.13 @@ -2,30 +2,68 @@ Programming the G-REX PCI bridge -document version 0 - THIS IS A WORK IN PROGRESS! +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... +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 -G-REX is an evolution of PCI bridge used previously on CyberVisionPPC and BlizzardVisionPPC cards. These -products share a lot of similiarities. +# 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 ;-). -Firmware 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. +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 +initialization. # 2. Memory map -G-REX is configured as multipie AutoConf boards. Confusingly, they all have the same vendor and product ID. +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. @@ -35,61 +73,141 @@ G-REX is configured as multipie AutoConf 0x80000000 - PCI memory space, variable size and number of boards, depending on cards installed. -# 2a. PCI configuration space +# 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 handle correctly. +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 +handle correctly. -Configuration data for first slot seems to be accessible at +0x1000. +Configuration data for first slot (device 0) is accessible at offset +0x1000, +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): + +0xFFFC0000 + (0x1000 << 2) = 0xFFFC4000 -# 2b. PCI I/O registers space +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. -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. +On G-REX BAR addresses in this space are treated as absolute. -# 2c. PCI memory space +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. -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 initialization. +# 2c. PCI memory space (0x80000000) -Addresses in this space are treated as absolute. Memory BAR register set to 0x80000000 means it is configured at this -address. +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 +initialization. -# 2d. Bridge configuration registers +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 + +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. +No need to fiddle with these registers, as they've been already configured +properly by the firmware. + +# 3. Detecting the G-REX -# 3. Reconfiguring the bus. +Since AutoConf entries are created by the firmware, it is not possible to +detect G-REX easily if the correct firmware is not installed. -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 +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. +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 DMA, but it needs further reverse engineering. +The bridge is certainly capable of real busmaster DMA, but it needs further +reverse engineering. [TO BE COMPLETED] -There were at least two different revisions of G-REX 1200. Later revision probably does support DMA in all slots. -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 + +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). -# 6. Sample PCI bridge driver implementation +# 8. Thanks -The NetBSD p5pb driver serves as example driver implementation. It was written using the same knowledge that went -into this document. +[[AmiBay|http://www.amibay.com]] users d0pefish, ramborolf and hese helped +testing early versions of p5pb driver. Without their help this document would +not exist.