| Zeile 2: | Zeile 2: | ||
Eine der größten Hürden zu Beginn beim Schreiben eines ATA-Treibers ist das Erkennen der angeschlossenen Geräte. Hierzu gibt es keinen von der Spezifikation vorgeschriebenen Weg. Viele Methoden funktionieren zwar in einigen Emulatoren aber auf echter Hardware nicht und umgekehrt. | Eine der größten Hürden zu Beginn beim Schreiben eines ATA-Treibers ist das Erkennen der angeschlossenen Geräte. Hierzu gibt es keinen von der Spezifikation vorgeschriebenen Weg. Viele Methoden funktionieren zwar in einigen Emulatoren aber auf echter Hardware nicht und umgekehrt. | ||
| − | Beim Schreiben des ATA-Treibers für | + | Beim Schreiben des ATA-Treibers für týndur habe ich lange nach einer Methode gesucht, die überall funktioniert und lange Wartezeiten beim Erkennen der Geräte vermeidet. Mittlerweile glaube ich, eine passende Methode gefunden zu haben, die in [[Qemu]] und [[VMWare]] und auf sämtlichen meinen bisher getesteten Maschinen funktioniert (4 Rechner von P1 bis zum P4). |
=== HOB-Bit löschen === | === HOB-Bit löschen === | ||
| − | Im | + | Im OSDev-Forum bin ich darauf gestoßen, dass man vor dem Suchen nach Geräten zuerst das HOB-Bit in den Kontrollregistern der beiden Geräte löschen sollte, da noch nicht klar ist, ob sie LBA48 unterstützen oder nicht. Ob es wirklich notwendig ist weiß ich nicht, aber schaden kann es ja nicht. |
=== Floating Bus === | === Floating Bus === | ||
| − | Angefangen wird mit einem kleinen Test auf eine Erscheinung, die als | + | Angefangen wird mit einem kleinen Test auf eine Erscheinung, die als ''floating bus'' bezeichnet wird. Damit kann festgestellt werden, ob der Bus sicher leer ist. Das Ganze hängt damit zusammen, dass der ATA-Bus mit sogenannten Pullup-Widerständen auf einem hohen Pegel gehalten wird, wenn die einzelnen Leitungen nicht von den Geräten gegen Masse gezogen werden. Beim Auslesen der Register äußert sich das dann durch lauter gesetzte Bits. Am einfachsten lässt sich das durch das Auslesen des Statusregisters erledigen. Zuerst wählt man den Master aus, liest danach den Wert des Statusregisters ein und vergleicht ihn danach mit 0xFF (ist ein ungültiger Status-Wert). |
=== Responsive Device === | === Responsive Device === | ||
| − | Der nächste Schritt dient dazu, herauszufinden ob auf dem Bus ein Gerät vorhanden ist, | + | Der nächste Schritt dient dazu, herauszufinden, ob auf dem Bus ein Gerät vorhanden ist, das auf Anfragen reagiert. Der Test kann einfach durchgeführt werden, indem man ein Gerät auswählt, danach beliebige Werte in die LBA-Register schreibt, und diese wieder ausliest. Wenn ein antwortendes Gerät vorhanden ist, kann man die gleichen Werte wieder einlesen, wenn das nicht der Fall ist, müssen auf dem Bus keine weiteren Prüfungen vorgenommen werden. Sicherheitshalber sollte hier zweimal geprüft werden, einmal mit Master und einmal mit Slave. Dies macht zwar eigentlich keinen Sinn, aber in VMWare reagiert der Master nicht (wie es in der Spezifikation vorgeschrieben ist), falls nur der Slave angesprochen wird, und soviel Zeit braucht das ganze ja nicht. |
=== IDENTIFY DEVICE - Kommando === | === IDENTIFY DEVICE - Kommando === | ||
| Zeile 18: | Zeile 18: | ||
== Fehlerquellen == | == Fehlerquellen == | ||
| − | Hier ein paar Hinweise auf Fehler die nicht sofort offensichtlich sind. | + | Hier ein paar Hinweise auf Fehler, die nicht sofort offensichtlich sind. |
=== Gerätesignaturen === | === Gerätesignaturen === | ||
| Zeile 28: | Zeile 28: | ||
== Weblinks == | == Weblinks == | ||
* [http://t13.org/Documents/UploadedDocuments/project/d1321r3-ATA-ATAPI-5.pdf Working-Drafts der aktuellen Spezifikationen zu ATA(PI)] | * [http://t13.org/Documents/UploadedDocuments/project/d1321r3-ATA-ATAPI-5.pdf Working-Drafts der aktuellen Spezifikationen zu ATA(PI)] | ||
| + | |||
[[Kategorie:Hardware]] | [[Kategorie:Hardware]] | ||