Return to g-rex.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc / users / rkujawa

Further extend G-REX doc.

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

Programming the G-REX PCI bridge

document version 0.2 - 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 (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.

# 2. Memory map

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.

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 (0xFFFA0000)

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 offset +0x1000 (on 
CVPPC/BVPPC there's aslo a mirror on +0x0).

[TO BE COMPLETED]

# 2b. PCI I/O registers space (0xFFFC0000)

This space offers access to I/O registers of all PCI cards.

On G-REX BAR addresses in this space are treated as absolute.

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)

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.

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

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. However, there seems to be an interrupt 
enable register (see "Bridge configuration registers" above).

# 5. DMA

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

# 6. Sample PCI bridge driver implementation

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

# 7. Thanks

[[AmiBay|http://www.amibay.com]] users d0pefish and ramborolf helped testing 
early versions of p5pb driver. Without their help this document would not 
exist.