Wie bereits im ersten Teil dieser Serie erwähnt wurde, hat jedes PCI-Gerät einen eigenen Registersatz. Ein Zugriff auf diesen Konfigurationsbereich erfolgt immer durch paralleles Setzen der IDSEL-Leitung des ensprechenden Slots und dem Anlegen der Registeradresse und des Buskommandos Configuration Read oder Configuration Write auf den Leitungen /C/BE[0..3]. Die IDSEL-Leitung ist dabei für jeden Slot separat vorhanden und wird vom Motherboard auskodiert. Nur mit dieser Art der Steuerung ist ein Zugriff auf die einzelnen Karten direkt nach dem Reset möglich, da zu diesem Zeitpunkt noch keine Adressräume zugeteilt wurden. Der Zugriff auf diese Register wird auf dem PC vom PCI-BIOS über die Befehle Configuration Read / Configuration Write bereitgestellt. Und in der nächsten Folge möchte ich dann sämtliche Möglichkeiten eines ATARI PCI-BIOS vorstellen.

Der PCI Configuration Bereich

Jede PCI-Karte enthält einen Satz von definierten Registern, die Informationen über die Karte bereitstellen und die die automatische Vergabe von Ressourcen überhaupt erst ermöglichen. Der Registerbereich ist 256 Bytes lang und teilt sich in einen von der PCI-SIG (PCI - Special Interest Group) vordefinierten und in einen kartenspezifischen Bereich. Dabei müssen in den jeweiligen PCI-Geräten von den beiden Bereichen nur die notwendigen Register implementiert werden Das Speicherlayout des 64 Byte langen, vordefinierten Bereichs selbst muss aber von jeder PCI-Karte eingehalten werden und beinhaltet die Identifikationsdaten der Karte und die Möglichkeiten zur generellen Kontrolle über die Karte. Die folgenden 192 Bytes sind nicht durch die PCI-Spezifikation vorgegeben, sondern können mit herstellerspezifischen Informationen gefüllt und danach vom Softwaretreiber ausgewertet werden.

Die Register werden während der Initialisierung des PCI-Busses ausgewertet und müssen daher schon direkt nach dem Reset gültige Werte enthalten. Auch später müssen die Register im freien Zugriff verbleiben, da zum Beispiel die Systemsoftware (PCI-BIOS) die Informationen über die Adressräume benötigt und eventuelle Statusinformationen abgefragt werden müssen.

Um herauszufinden, welche Karten nun am PCI-Bus angeschlossen sind, kann man die Vendor ID in jedem der im System vorhandenen Slots auslesen. Die Hostsystem muss daher Zugriffe auf die Konfigurationsbereiche nicht vorhandener Karten (ohne Fehlermeldung) unterstützen. Da für eine Vendor ID der Wert FFFFhex nicht erlaubt ist, reicht es daher völlig, wenn die Systemhardware bei Lesezugriffen auf den Konfigurations-Bereich nicht vorhandener Karten eben diesen Wert zurückliefert.

Jedes PCI-Gerät muss Schreibzugriffe auf reservierte oder nicht unterstützte Register ignorieren, d.h. der Schreibzugriff muss am PCI-Bus ohne Fehlermeldung abgeschlossen werden. Die Daten selbst werden allerdings von der Karte verworfen. Lesezugriffe auf reservierte oder nicht implementierte Register müssen ebenfalls ohne Fehlermeldung am Bus abgeschlossen, und ein Wert von 0000hex zurückgegeben werden.

Auch dieser von der PCI-SIG vordefinierte Bereich gliedert sich in zwei Bereiche. Der erste 16 Bytes lange Bereich gilt für alle Arten von PCI-Geräten und ist immer gleich. Den verbleibenden 48 Bytes können in Abhängigkeit von der Funktion des PCI-Geräts verschiedene Layouts zugewiesen werden. Das Feld 'Header Type' an Adresse 0Ehex legt fest, um welches Layout es sich in diesem zweiten Bereich handelt.
Alle PCI-Geräte müssen die Register für Vendor ID, Device ID, Command und Status implementieren. Die Implementierung der anderen Register ist optional und hängt wieder einmal mehr von der Funktionalität des PCI-Geräts ab. Nicht implementierte Register können vom PCI-Gerät wie reservierte Register behandelt werden. Wenn allerdings ein PCI-Gerät eine Funktion beinhaltet, deren Verhalten durch eines der definierten Register festgelegt wird, so muss das PCI-Gerät dieses Register an der dafür definierten Stelle mit dem definierten Verhalten zur Verfügung stellen.

Bedeutung der Konfigurations-Register

Der PCI-Bus hat das Potential, die Konfiguration von Zusatzkarten wesentlich zu vereinfachen. Dazu müssen aber diese PCI-Geräte bestimmte Funktionen (über Register) der Konfigurationssoftware (PCI-BIOS) zur Verfügung stellen. Im folgenden werden also die Register dieses vordefinierten Konfigurations-Bereichs vorgestellt. Das exakte Format der Register (d.h. die Anzahl der implementierten Bits usw.) hängt wiederrum vom jeweiligen PCI-Gerät ab. Jedoch müssen einige allgemeine Regeln beachtet werden. So müssen alle Register die Möglichkeit bieten, die eingestellten Werte zurückzulesen, und diese gelesenen Daten müssen einen Wert repräsentieren, den die Karte für die aktuellen Einstellungen gerade verwendet.
Die Konfigurationsregister werden zur Konfiguration, Initialisierung und für die Behandlung schwerer Fehler verwendet, und sollten nur von der Initialisierungssoftware (d.h. PCI-BIOS) und eventuellen Fehlerbehandlungsroutinen verwendet werden. Die Gerätetreiber selbst sollen nur Zugriffe auf I/O und/oder Memory Bereiche verwenden, um gerätespezifische Register und damit die Funktionalität des PCI-Geräts zu manipulieren.

Die Identifikationsregister

Fünf Felder im vordefinierten Bereich sind für die Identifikation des Geräts vorgesehen. Alle PCI-Geräte müssen diese Felder unterstützen. Die Konfigurationssoftware kann somit leicht feststellen, welche Geräte am PCI-Bus des Rechners verfügbar sind. Alle diese Register sind 'read only'.

Vendor ID:
Dieses Feld identifiziert den Hersteller des PCI-Geräts. Gültige Kennungen werden von der PCI-SIG an zahlende (!) Mitglieder vergeben, um eine Eindeutigkeit zu gewährleisten. Diese Herstellerkennung ist 16 Bit breit, wobei der Wert FFFFhex eine ungültige Vendor ID darstellt und vom Motherboard bei einem nicht belegten Slot zurückgeliefert wird. Anhand dieses Wertes kann also das PCI-BIOS unterscheiden, ob in dem betreffenden Slot eine Karte vorhanden ist oder nicht

Device ID:
Dieses Feld identifiziert ein spezielles Gerät. Die Kennung wird vom Hersteller der Karte selbst vergeben, und dient zusammen mit der Vendor ID dem Softwaretreiber zum eindeutigen Erkennen eines PCI-Gerätes. Die Funktion FindPCIDevice eines PCI-BIOS macht von dieser Möglichkeit Gebrauch. Ein spezielles Problem ergibt sich aber bei der Verwendung von Standard Interface Chips wie dem PCI9060. Verwendet man nämlich z.B. auf einer selbst gebauten Karte einen solchen Interface Chip, so meldet sich dieser mit seiner eigenen Vendor und Device ID und zu einer eindeutigen Erkennung und Unterscheidung solcher Karten ist daher noch eine Subsystem Vendor ID sowie eine Subsystem Device ID notwendig. Mit diesem Thema wird sich zu einem späteren Zeitpunkt ein weiterer Artikel beschäftigen.

Revision ID:
Dieses Register beinhaltet eine gerätespezifische Revisionsnummer. Der Wert selbst wird wieder vom Hersteller der Karte vergeben, wobei auch die Revisionsnummer 00hex erlaubt ist. Dieses Feld sollte daher als herstellerspezifische Erweiterung zur Device ID angesehen werden.

Header Type:
Dieses Byte legt sowohl das Layout der Bytes 10hex bis 3Fhex des Konfigurationsbereiches fest, als auch die Information, ob das Gerät weitere Funktionen beinhaltet. Bit 7 dieses Registers wird dazu verwendet, um sogenannte multi function devices zu kennzeichnen. Ist das Bit 0, so handelt es sich bei diesem Gerät um ein single function device, ist es hingegen gesetzt, so hat dieses Gerät mehrere Funktionseinheiten. Bits 6..0 legen schließlich das Format des zweiten Teils des Konfigurationsbereiches fest. Das in Tabelle 1 gezeigt Layout gilt für Standard-Geräte und ist mit Header Type 00hex gekennzeichnet. Zur Zeit ist noch Header Type 01hex für PCI to PCI-Bridges definiert.

Class Code:
Das Class Code Register ist ebenfalls nur 'read only' und wird dazu verwendet, um die 'Gattung' (die generelle Funktion) eines PCI-Gerätes festzulegen, sowie in einigen wenigen Fällen ein Register Interface.
Das Register ist dazu in 3 Bytes unterteilt. Das oberste Byte (an Adresse 0Bhex) stellt die Basisklasse dar, welche die Funktion dieser Karte ganz allgemein beschreibt. Das mittlere Byte (an Adresse 0Ahex) ist eine Subklasse, welches die in der Basisklasse definierte Funktion genauer beschreibt. Im Falle von Basisklasse 02hex für Network Controller wird hier z.B. weiter zwischen Ethernet, Token Ring, FDDI und anderen Arten unterschieden. Das niedrigste Byte (an Adresse 09hex) ist schließlich das gerätespezifische Register Interface, über das geräteunabhängige Software mit dem Gerät kommunizieren kann. Tabelle 2 zeigt die definierten Werte für die Basisklasse. Der Class Code selbst ermöglicht überhaupt erst die Zusammenarbeit von geräteunabhängiger Software mit Standardkomponenten wie etwa einer Grafikkarte, da es eben eine Fülle an verschiedenen Herstellern (Vendor ID) und verschiedenen kompatiblen Grafikkarten (Device ID) gibt, die ein Treiber sonst alle implementieren müßte.

Tabelle 2: Die Definition der Basisklassen

Die Basisklasse 01 hex (Mass Storage controller)
Diese Basisklasse wurde für alle möglichen Massenspeicher-Anwendungen definiert.
Bisher sind für diese Geräte keinerlei Register Interfaces definiert

Die Basisklasse 04 hex (Multimedia device)
Diese Basisklasse definiert die möglichen Typen von Multimedia Geräten, für die aber keinerlei spezifische Register Interfaces definiert sind.

Die Basisklasse 06 hex (Bridge device)
Diese Basisklasse ist für alle möglichen Typen von 'bridge devices' reserviert.
Eine solche PCI-bridge ist ein PCI-Gerät, das PCI Ressourcen (Memory oder I/O) von der einen Seite dieses Geräts auf die andere Seite des Geräts mappt. Es gibt mehrere Subklassen, und es sind keine spezifischen Register Interfaces definiert.

Die Kontrollregister
Command:
Über das Command Register können die verschiedenen Möglichkeiten des PCI-Gerätes über einzelne Bits freigeschalten werden, sofern das Gerät dies auch unterstützt. Das Command Register stellt auch eine einfache Kontrolle über das PCI-Gerät dar, ob es PCI-Cycles generieren beziehungsweise darauf antworten darf. Schreibt man eine 0 in das Command Register, so ist dieses Gerät mit Ausnahme von Zugriffen auf den Konfigurationsbereich logisch vom PCI-Bus getrennt. Alle PCI-Geräte müssen diese Funktionalität dem System zur Verfügung stellen. Die anderen Bits im Command Register können in Abhängigkeit der weiteren Funktionen und Möglichkeiten der betreffenden Karte wahlweise implementiert werden. Eine Karte, die z.B. keine I/O- Zugriffe erlaubt, wird auch das Setzen des entsprechenden Bits im Register nicht zulassen. Die PCI-Geräte beinhalten typisch den Wert 00hex nach dem Power up, d.h. die Funktionen werden erst vom PCI-BIOS freigegeben (oder auch nicht).

Tabelle 3: Bits im Command Register

Status:
Das Status-Register wird dazu verwendet, um Informationen bezüglich PCI Bus - relevanter Vorgänge zur Verfügung zu stellen. Die PCI-Geräte müssen wiederrum nicht alle Bits implementieren, das hängt wieder von der Funktionalität der Karte selbst ab. Wenn eine Karte z.B. als Target agiert, aber niemals einen target abort signalisiert, wird auch dieses Bit von der Karte nicht verwendet werden. Lesezugriffe auf diese Register verlaufen normal, Schreibzugriffe auf dieses Register können Bits nur löschen, aber nicht setzen. Ein Bit in diesem Register wird gelöscht, wenn man an der jeweiligen Position eine 1 schreibt. Wenn man z.B. Bit 14 löschen möchte, ohne andere Register zu beeinträchtigen, so schreibt man in dieses Register den Wert 4000hex. Im Gegensatz dazu kann das PCI-Gerät selbst diese Bits nur setzen, aber nicht löschen.

Tabelle 4: Bits im Status Register

Tabelle 5: Bits im BIST Register

Tabelle 6: Interrupt Pin Register

MIN_GNT und MAX_LAT
Diese beiden 'read only' Register legen die Grenzwerte für das Setzen des Latency Timers (nur für den Busmaster-Betrieb nötig) fest. Beide Register haben hierbei eine Auflösung von 0,25 Mikrosekunden. Ein Wert von 0 zeigt an, dass dieses PCI-Gerät keine speziellen Anforderungen an die Konfiguration des Latency Timers stellt.
MIN_GNT zeigt an, wie lange das PCI-Gerät für eine einzige Burst-Periode (nur eine Datenphase) in Bezug auf eine PCI-Taktrate von 33 MHz mindestens benötigt. Dem PCI-Gerät (als Busmaster) sollte also für mindestens diese Zeit der Bus durch den Bus Arbiter zugeteilt werden. MAX_LAT definiert, für wie lange das PCI-Gerät als Busmaster Zugriff auf den PCI-Bus erwirken möchte. Aus beiden Werten kann man dann einen geeigneten Wert für das Latency Timer Register wählen. Der Busmaster gibt den Bus ja erst dann zurück, wenn ihm der Bus Arbiter den PCI-Bus über /GNT entzieht, und der eigene latency timer abgelaufen ist. Ein Master darf sich aber nicht durch ständiges Aktivieren der /REQ-Leitung den Bus auf Dauer sichern, sondern nur für den aktuellen Zugriff benutzen. Der Algorithmus zur Arbitrierung ist in der PCI-Spezifikation allerdings nicht festgelegt. Die PCI-Geräte sollten daher auch solche Werte angeben, die eine effektive Verwendung sowohl des PCI-Busses als auch ihrer eigenen internen Ressourcen ermöglichen.

Basis-Addressen:
Die Basisadressen sind eine der wichtigsten Funktionen, um eine einfache Konfiguration und Einbindung von PCI-Geräten in das Rechnersystem zu gewährleisten. Die sechs Basisadreßregister enthalten die in der Initialisierungsphase (vom PCI-BIOS) vergebenen Adressen zum Zugriff auf die einzelnen Adressräume des PCI-Gerätes. Bit 0 in diesen Adressregistern kann nur gelesen werden und zeigt an, ob der Adressraum im Memory-Bereich oder im I/O-Bereich liegt.

Memory-Bereiche:
Register, die einen Memory-Bereich anfordern, müssen Bit 0 auf den Wert 0 setzen. Die Register selbst sind dabei entweder 32 bit oder aber auch 64 bit breit. Zur Auskodierung der Basisadresse verwendet das PCI-Gerät allerdings nur Bit 4 bis Bit 31 bzw. Bit63, d.h. Memory-Bereiche beginnen stets an 16 Byte - Grenzen.
Die anderen Bits sind 'read only'. In Bit 3 des Registers wird mitgeteilt, ob der Adressbereich 'prefetchable' ist, und in Bit 2 und Bit 1 steht die gewünschte Art des Memory mappings in der Initialisierungsphase

Tabelle 7: Adressregister für Memory-Bereiche

Register, die einen I/O-Bereich anfordern, sind immer 32 Bit breit und müssen in Bit 0 den Wert 1 zurückliefern. Bit 1 ist reserviert (read only) und muss immer gelöscht sein, alle anderen Bits (Bit 2 bis Bit 31) beschreiben schließlich die Adresse im I/O-Bereich, d.h. diese Bereiche beginnen stets an 4 Byte - Grenzen.

Tabelle 8: Adressregister für IO-Bereiche

Insgesamt ist im Konfigurationsbereich Platz für sechs Adressregister. Das erste Adressregister beginnt immer an Offset 10hex. Die Lage des zweiten Adressregisters hängt dann allerdings von der Größe (32/64 Bit) des ersten Registers ab, und beginnt demnach an Offset 14hex bzw. 18hex.
Grafikkarten fordern typischerweise einen I/O-Bereich für die Kontrollregister und einen Memory-Bereich für den Grafikspeicher an. Wenn ein PCI-Gerät seine Kontrollregister in den Memory- und in den I/O-Bereich legen will, muss es dafür auch zwei Adressregister 'spendieren'. Grundsätzlich sollten es alle PCI-Geräte ermöglichen, Kontrollregister in den Memory-Bereich zu mappen. Das ist aus der Unzulänglichkeit der PCs entstanden, die einen viel zu kleinen I/O-Bereich besitzen.

Um nun zu bestimmen, wieviel Speicher das jeweilige Gerät mittels der Adressregister anfordert, beschreibt das Hostsystem jedes Adressregister mit dem Wert FFFF'FFFFhex und liest danach das Register wieder zurück. Das PCI-Gerät liefert an jenen Bitpositionen 0 zurück, die es zur Auskodierung des gewünschten Speicherbereichs verwendet. Fordert das Gerät z.B. einen 1MB großen Memory-Bereich im 32-bit Adressraum und einen 256 Byte großen I/O-Bereich an, so findet man nach dem Beschreiben mit FFFF'FFFFhex in einem Adressregister FFF0'0000hex für den Memory-Bereich und in dem anderen FFFF'FF01hex für den I/O-Bereich vor. Das Hostsystem kann danach die Basisadressen für die jeweiligen PCI-Geräte vergeben. Ab diesem Zeitpunkt dekodieren die PCI-Geräte die Zugriffe dann selbst aus. Die Vergabe der Adressräume beim Booten des Rechnersystems ist Aufgabe eines PCI-BIOS.
Damit wären nun die wichtigsten Register vorgestellt und in der nächsten Folge können wir uns dann endlich mit der Definition und den Aufgaben eines ATARI PCI-BIOS beschäftigen. Die bereits in der ersten Folge bechriebene Möglichkeit von Erweiterungs-ROMs auf den Karten werden zu einem späteren Zeitpunkt behandelt.