Das PCI-BIOS Teil 2

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.

Configuration Register				Adress- Offset
Device ID		Vendor ID		00h
Status		Command		04h
Class Code			Revision ID	08h
BIST	Header Type	Latency Timer	Cache Line Size	0Ch
Base Address Registers				10h
				14h
				18h
				1Ch
				20h
				24h
Reserved				28h
Reserved				2Ch
Expansion ROM Base Address				30h
Reserved				34h
Reserved				38h
Max_lat	Min_Gnt	Interrupt Pin	Interrupt Line	3Ch

Tabelle 1 zeigt das Layout des von der PCI-SIG definierten 64Byte-Bereichs, das jede Karte unterstützen muss. Jedem PCI-Gerät ist es natürlich freigestellt, weitere gerätespezifischen Register im nachfolgenden Bereich abzulegen. Alle Felder, bestehend aus mehr als einem Byte, liegen dem Little Endian (Intel)-Format zugrunde, d.h. die niederwertigere Adresse beinhaltet auch das niederwertigere Byte.
Die Treibersoftware muss mit bitcodierten Feldern sorgsam umgehen, da diese zumeist reservierte Bitpositionen für eine etwaige spätere Verwendung beinhalten. Die Software muss daher bei Lesezugriffen Masken verwenden um die verwendeten Bits zu extrahieren, und darf sich keinesfalls auf bestimmte Werte in reservierten Bits verlassen. Bei Schreibzugriffen muss die Software sicherstellen, dass die Werte von reservierten Bits nicht verändert werden, d.h. ihr Wert muss vorher ausgelesen und zum gewünschten Wert der anderen Bits 'gemerged' 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

Basisklasse	Bedeutung
00h	PCI-Gerät wurde bereits vor der Definition der Class Codes gefertigt
01h	Mass Storage controller
02h	Network controller
03h	Display controller
04h	Multimedia device
05h	Memory controller
06h	Bridge device
07h - FEh	Reserviert
FFh	Gerät paßt in keine der obigen Klassen

Die Basisklasse 00 hex

Diese Basisklasse wurde definiert, um Abwärtskompatibilität für diejenigen PCI-Geräte zu gewährleisten, die bereits vor der Definition der Basisklassen gebaut wurden. Neue Geräte dürfen diesen Wert nicht mehr verwenden, und ältere Geräte sollten soweit als möglich auf einen aussagekräftigeren Wert umsteigen. Für diese Basisklasse existieren nur zwei Subklassen, alle anderen Werte sind reserviert.

Basisklasse	Subklasse	Interface	Bedeutung
00h	00h	00h	alle PCI-Geräte außer VGA-kompatibler Geräte
	01h	00h	VGA-kompatible Geräte

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

Basisklasse	Subklasse	Interface	Bedeutung
01h	00h	00h	SCSI bus controller
	01h	00h	IDE controller
	02h	00h	Floppy disk controller
	03h	00h	IPI bus controller
	80h	00h	andere mass storage controller

Die Basisklasse 02 hex (Network controller)

Diese Basisklasse wurde für die verschiedensten Arten an Netzwerkkarten definiert.
Auch hier gibt es bisher noch keine definierten Register Interfaces.

Basisklasse	Subklasse	Interface	Bedeutung
02h	00h	00h	Ethernet controller
	01h	00h	Token Ring controller
	02h	00h	FDDI controller
	80h	00h	andere Netzwerk controller

Die Basisklasse 03 hex (Display controller)

Diese Basisklasse wurde für alle Arten an Grafikkarten definiert.
Dazu gibt es einige Subklassen, zu denen jeweils ein eigenes Register Interface existiert.

Basisklasse	Subklasse	Interface	Bedeutung
03h	00h	00h	VGA - kompatible Grafikkarte
	01h	00h	XGA - kompatible Grafikkarte
	80h	00h	alle andere Grafikkarten

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.

Basisklasse	Subklasse	Interface	Bedeutung
04h	00h	00h	Video
	01h	00h	Audio
	80h	00h	andere Multimedia Geräte

Die Basisklasse 05 hex (Memory controller)

Diese Basisklasse definiert alle möglichen Arten an Memory controllern.
Es sind keine spezifischen Register Interfaces definiert.

Basisklasse	Subklasse	Interface	Bedeutung
05h	00h	00h	RAM
	01h	00h	FLASH
	80h	00h	andere Memory controller

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.

Basisklasse	Subklasse	Interface	Bedeutung
06h	00h	00h	Host bridge
	01h	00h	ISA bridge
	02h	00h	EISA bridge
	03h	00h	MC bridge
	04h	00h	PCI to PCI bridge
	05h	00h	PCMCIA bridge
	80h	00h	alle anderen bridge devices

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

Bit	Bedeutung
0	IO Space 0: Gerät reagiert nicht auf I/O Zugriffe 1: Gerät reagiert auf I/O Zugriffe
1	Memory Space 0: Gerät reagiert nicht auf Memory Zugriffe 1: Gerät reagiert auf Memory Zugriffe
2	Bus Master 0: Gerät generiert keinerlei Zugriffe am PCI-Bus 1: Gerät darf als Busmaster auftreten
3	Special Cycles 0: Gerät ignoriert Special Cycle Operationen 1: Gerät reagiert auf Special Cycle Operationen
4	Memory Write and Invalidate Enable (als Busmaster) 0: Gerät benutzt als Busmaster nur Memory Write Befehle 1: Gerät darf Memory Write and Invalidate verwenden.
5	VGA Palette Snooping (Bit muss von allen VGA kompatiblen Geräten zur Verfügung gestellt weden) 0: Gerät behandelt Paletten-Befehle wie alle anderen 1: Gerät antwortet nicht auf Paletten-Befehle
6	Parity Error Response (Geräte, die auf Parity prüfen, müssen dieses Bit unterstützen; Geräte müssen das Parity Bit immer generieren, auch wenn die Funktion über dieses Bit deaktiviert ist) 0: Gerät ignoriert Parity - Fehler 1: Gerät signalisiert und reagiert auf Parity - Fehler
7	Wait Cycle Control 0: Gerät arbeitet ohne Adress Data stepping 1: Gerät arbeitet mit Adress Data stepping
8	SERR# enable (Parity wird nur dann gemeldet, wenn auch dieses Bit gesetzt wurde) 0: Gerät darf an Pin /SERR keinen System Error signalisieren 1: Gerät darf an Pin /SERR System Error signalisieren
9	Fast Back-to-Back Enable (legt fest, ob das PCI-Gerät als Busmaster Transaktionen zu verschiedenen Targets durchführen darf; die Initialisierungssoftware setzt dieses Bit, wenn alle Targets Fast Back-to-Back capable signalisieren) 0: Gerät darf Fast Back-to-Back nicht verwenden 1: Gerät darf als Busmaster Fast Back-to-Back verwenden
10-15	reserviert

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

Bit	Bedeutung
0 - 6	reserviert
7	Fast Back-to-Back Capable (zeigt an, ob das PCI-Gerät als Target Fast Back-to-Back Transaktionen zu mehreren Targets verabeitet kann) 0: keine Fast Back-to-Back Transaktionen als Target möglich 1: Gerät versteht als Target auch Fast Back-to-Back Transaktionen
8	Data Parity Detected (wird nur signalisiert, wenn ein Paritätsfehler während eines Busmaster-Zugriffs auftritt, und durch das Command Register auch freigeschalten wurde) 0: kein Parity Error bei Master Zugriff oder durch Command Register gesperrt 1: Parity Error bei Master Zugriff aufgetreten
9 - 10	DEVSEL timing (ein PCI-Target zeigt an Pin /DEVSEL an, dass es einen Zugriff auf eine Adresse registriert hat, die sich in einem durch das Basisadreßregister zugewiesenem Adressbereich befindet; der Wert legt fest, zu welchem Zeitpunkt nach der Adressphase der Pin /DEVSEL von High nach Low wechselt.) 00: schnell (nach einem PCI-Taktzyklus) 01: mittel (nach zwei PCI-Taktzyklen) 10: langsam (nach drei PCI-Taktzyklen) 11: reserviert
11	Signaled Target Abort (zeigt an, wenn das PCI-Gerät selbst die laufende Transaktion am PCI-Bus abbricht) 0: keine abgebrochene Transaktion 1: Gerät hat Transaktion mit 'Target Abort' abgebrochen
12	Received Target Abort (zeigt an, wenn das PCI-Gerät als Busmaster agiert und die laufende Transaktion am PCI-Bus durch das Target abgebrochen wird) 0: keine abgebrochene Transaktion 1: Target hat Transaktion mit 'Target Abort' abgebrochen
13	Received Master Abort (zeigt an, wenn das PCI-Gerät als Busmaster agiert und die laufende Transaktion mit Ausnahme von Special Cycle am PCI-Bus durch 'Master Abort' abgebrochen wird - alle Busmaster-fähigen Geräte müssen dieses Bit implementieren) 0: keine abgebrochene Transaktion 1: Busmaster - Transaktion wurde durch 'Master Abort' abgebrochen
14	Signaled System Error (zeigt an, ob das Gerät an Pin /SERR einen System Error signalisiert hat) 0: kein System Error 1: System Error signalisiert
15	Detected Parity Error (zeigt an, ob das Gerät einen Parity Error erkannt hat - auch wenn das Parity Handling durch das Command Register abgeschalten wurde) 0: kein Parity Error erkannt 1: Parity Error erkannt

Verschiedene Funktionen
Die nachfolgenden Register sind gerätespezifisch und müssen nur von denjenigen Karten zur Verfügung gestellt werden, die die beschriebene Funktionalität beinhalten. Für den Standardbetrieb sind diese Register nicht nötig.

Cache Line Size
Dieses Register legt die Größe der Cache Line in Langworten (32 Bit) fest. Dieses Register muss von allen busmasterfähigen Geräten zur Verfügung gestellt werden, die das Kommando Write and Invalidate generieren können. Geräte die am caching protocol beteiligt sind, verwenden dieses Register um herauszufinden, wann Burst-Zugriffe an den Cache Grenzen zu wiederholen sind. Wenn das Register auf 0 gesetzt ist, können die jeweiligen Geräte die PCI Cache Leitungen /SDONE und /SBO ignorieren. Geräte, die dieses Register zur Verfügung stellen, müssen dessen Wert bei Reset auf 0 setzen.

Latency Timer
Der Standardzugriff auf dem PCI-Bus ist der Burst. Ein Einzelzugriff ist somit nichts anderes als ein nach dem ersten Datenwort beendeter Burst. Sowohl der Master als auch der Slave (Target) können einen Bursttransfer abbrechen. Der Busmaster bricht dann einen Transfer ab, wenn ihm der Bus über /GNT entzogen wird, und seine interne Verzögerung (latency timer) abgelaufen ist.
Dieses Register legt den Wert des Latency Timers für Busmaster fest, und muss daher auch von allen busmasterfähigen Geräten zur Verfügung gestellt werden, die mehr als zwei Datenphasen im Burst-Betrieb verarbeiten. Bei zwei oder weniger Datenphasen im Burst-Betrieb kann dieses Register auch als 'read-only' ausgeführt sein, der somit fixierte Wert sollte allerdings kleiner gleich 16 (bus clocks) sein. Eine durchaus verbreitete Implementierung sieht z.B. die untersten 3 Bits als 'read-only' vor, während die oberen 5 Bits beliebig verändert werden können. Dadurch ergibt sich eine Auflösung des Latency Timers von 8 bus clocks. Ist dieses Register allerdings nicht als reines 'read only'-Register ausgeführt, muss das PCI-Gerät dessen Wert bei Reset auf 0 setzen.

Built-in Self Test (BIST)
Dieses optionale Register dient zur Steuerung eines auf der PCI-Karte implementierten Eigentests, sofern dieser überhaupt vorhanden ist. PCI-Geräte die keinen Selbsttest zur Verfügung stellen, liefern in diesem Register den Wert 0 zurück. Ein Gerät, dessen Selbsttest gestartet wurde, darf den Normalbetrieb des PCI-Busses in keinster Weise beeinträchtigen.

Tabelle 5: Bits im BIST Register

Bit	Bedeutung
7	BIST capable 0: Gerät unterstützt keinen Selbsttest 1: Gerät stellt einen eingebauten Selbsttest zur Verfügung
6	Start BIST 1: Selbsttest starten. Nach Beendigung des Tests wird dieses Bit vom PCI-Gerät wieder auf 0 gesetzt. Trifft dies auch nach dem Ablauf von 2 Sekunden nicht zu, so ist diese Karte als defekt einzustufen.
5 - 4	reserviert
3 - 0	Completion code 0000: PCI-Gerät hat den Selbsttest bestanden. Alle von 0000 verschiedenen Werte stellen gerätespezifische Fehlercodes dar.

Interrupt Line:
Dieses 8-bit breite Register wird vom Hostsystem dazu verwendet, die Information über den dem Gerät zugeteilten Hardware-Interrupt allgemein zur Verfügung zu stellen. Der Wert in diesem Register zeigt an, welcher Eingang des Interruptcontrollers mit dem Interrupt-Pin des PCI-Gerätes verbunden ist. Sowohl Gerätetreiber als auch das Betriebssystem selbst können diese Information dazu benutzen, um Interruptprioritäten und Vektorinformationen zu ermitteln. Die Werte in diesem Register hängen von der jeweilig verwendeten Systemarchitektur ab. Der Wert FFhex wird dann verwendet, wenn keine Zuordnung zum Interrupt Controller ermittelt werden konnte, oder wenn keine Verbindung zu diesem besteht. Vom PCI-Gerät selbst wird dieses Register.nicht weiter beachtet.

Interrupt Pin:
Das Interrupt Pin Register kann nur gelesen werden. Über dieses Register teilt das PCI-Gerät dem Hostsystem mit, welche Interruptleitung des PCI-Busses es benutzt. PCI-Geräte, die keine Interrupts generieren, müssen dieses Register auf 0 setzen.

Tabelle 6: Interrupt Pin Register

Wert	Bedeutung
0	PCI-Gerät generiert keine Interrupts
1	PCI-Gerät verwendet Interrupt Pin /INTA
2	PCI-Gerät verwendet Interrupt Pin /INTB
3	PCI-Gerät verwendet Interrupt Pin /INTC
4	PCI-Gerät verwendet Interrupt Pin /INTD
5-255	reserviert

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

Bit	Bedeutung
31(63)..4	Memory-Basisadresse (32 oder 64 bit breit)
3	Prefetchable
2 - 1	Type (Größe des Registers 32/64 bit, sowie gewünschter Adressraum) 00: 32 bit breit, beliebig im 32 bit Adressraum 01: 32 bit breit, Adressraum unterhalb 1 MB 10: 64 bit breit, beliebig im 64 bit Adressraum 11: reserviert
0	Memory Space Indicator = 0

I/O-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

Bit	Bedeutung
31..2	I/O-Basisadresse
1	reserviert (immer 0)
0	IO Space Indicator = 1

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.

Markus Fichtenbauer

---

---