File:  [NetBSD Developer Wiki] / wikisrc / users / rkujawa / g-rex.mdwn
Revision 1.2: download - view: text, annotated - select for diffs
Wed Jul 4 18:24:04 2012 UTC (10 years, 7 months ago) by rkujawa
Branches: MAIN
CVS tags: HEAD
Fix layout a bit.

[[!meta title="G-REX"]]

Programming the G-REX PCI bridge

document version 0 - THIS IS A WORK IN PROGRESS!

# 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...
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.

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.

# 2. Memory map

G-REX is configured as multipie AutoConf boards. Confusingly, they all have the same vendor and product ID.

0xFFFA0000 - PCI I/O register space, 64KB.

0xFFFC0000 - PCI configuration space, 128KB.

0xFFFE0000 - Bridge configuration registers, 4kB.

0x80000000 - PCI memory space, variable size and number of boards, depending on cards installed. 

# 2a. PCI configuration space

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.


# 2b. PCI I/O registers space

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. 

# 2c. PCI memory space 

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. 

Addresses in this space are treated as absolute. Memory BAR register set to 0x80000000 means it is configured at this

# 2d. Bridge configuration registers

Offset - meaning
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.

# 3. 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

All interrupts are converted into Amiga INT2 interrupt. There's no such thing as interrupt acknowledge register.

# 5. DMA

The bridge is certainly capable of DMA, but it needs further reverse engineering.


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.

# 6. Sample PCI bridge driver implementation

The NetBSD p5pb driver serves as example driver implementation. It was written using the same knowledge that went
into this document.

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb