Thema: Juhuuuuuuuuu

[bluecode]

Ich nehme an es bezieht sich auf das hier:

The method suggested in the ATA specs for sending ATA commands tells you to check the BSY and DRQ bits before trying to send a command. This means that you need to read a Status Register (Alternate Status is a good choice) for the proper drive before sending the next command.

[bitmaster]

Hmm... Jetzt habe ich alles so gemacht und es funktioniert auch. Sobald ich aber jetzt ein Befehl senden will und vorher auf BSY und DRQ testen will ist das ERR bzw. CHK Bit gesetzt. Was hat das zu bedeuten? Laut der Spezifikation: "For the PACKET and
SERVICE commands, this bit is defined as CHK and indicates that an exception condition exists". Soll ich das einfach ignorieren?

danke!!!

[bluecode]

6.17.5.2 Outputs for PACKET Command feature set devices
In response to this command, devices that implement the PACKET Command feature set shall post
command aborted and place the PACKET Command feature set signature in the Command Block registers
(See 5.15).

6.17.6 Error outputs
Devices not implementing the PACKET Command feature set shall not report an error.

Ein "Commnd aborted" wird afaik angezeigt über ein ERR im Statusregister und ein ABT im Fehlerregister, musst du halt dann da auch nachschauen was der Grund für den Fehler ist. Da nur ein Fehler bei Packet Devices möglich ist, hast du halt ein Packet Device vor dir und solltest dann auch Identify Packet Device ausführen.
btw. du solltest den Fehlercode nach dem Ausführen eines Commands überprüfen, nicht vor dem nächsten. Du willst ja schließlich wissen ob das Command fehlgeschlagen ist oder nicht.

Lern bitte lesen. Ich werde nicht weiter "spoon feeding" betreiben.

[bitmaster]

Nein nein, du hast mich falsch verstanden. Dass der Befehl bei einem ATAPI Laufwerk abgebrochen wird ist mir klar. Also ich mache das so:

1. sende den Befehl "IDENTIFY DEVICE" an das master device
2. schaue im Statusregister nach, wenn Null dann

- sende den Befehl "IDENTIFY DEVICE" an das slave device (da das master device dann ja nicht vorhanden ist, muss ich dazwischen noch was machen? also muss ich z.B. trotzdem die 256 WORDs auslesen (soweit ich das englisch verstanden habe nicht))

- wenn nicht Null, dann prüfe ob ERR gesetzt ist wenn nicht dann

- teste BSY und DRQ und lese die 256 WORDs aus

- ansonsten wenn ERR gesetzt ist, dann prüfe die Signatur auf ATAPI



Und wenn ich das jetzt bei IDE0,0 bis IDE1,1 gemacht habe, habe ich in einem Array die ATAPI Laufwerke stehen (Null für IDE0,0, EINS für IDE0,1, ZWEI für IDE1,0 und DREI für IDE1,1). Dann möchte ich einen Befehl an die ATAPI-Laufwerke senden. Dazu prüfe ich nach dem setzen des DEV-Bit das Statusregister. In dem ist das ERR/CHK Bit dann aber gesetzt. Was soll ich jetzt machen?

sry, hatte mich vorher vielleicht falsch ausgedrückt

[bluecode]

5.14.5.7 ERR / CHK (Error / Check)
[...]
The ERR bit shall be cleared to zero by the device:
      1) when a new command is written to the Command register;
      2) when the SRST bit is set to one;
      3) when the RESET- signal is asserted.

Insofern ja, das kannst du beim Senden des neuen/nächsten Commands getrost ignorieren.

[bitmaster]

Jou es funktioniert. Dann bedanke ich mich recht herzlich für deine Hilfe, auch wenn ich dir wahrscheinlich ein wenig auf den Keks gegangen bin. Aber im Hinblick (ja wo wollen wir denn hinblicken ala C. Daum ^^) auf meinem Treiber war das gut.

vielen dank!!!

[bluecode]

Aber im Hinblick [...] auf meinem Treiber war das gut.

Blöderweise verhilft das meinem ATA/ATAPI Treiber nicht zur Existenz.
Aber du könntest ja etwas an die Community zurückgeben und unseren Wikiartikel ausbauen.

[bitmaster]

@bluecode: Wieso? Wo hakts denn bei deinem ATAPI-Treiber noch? Jo, vielleicht schreibe ich bald ins Wiki.

Ich bin jetzt nur am überlegen wie ich die ATAPI-Laufwerke registrieren soll. Denn ich muss dem OS ja irgendwie sagen, dass jetzt ATAPI-Laufwerke vorhanden sind. Und dann muss ich die noch mit dem Dateisystemtreiber in Verbindung bringen. Dann muss der ISO9660-Treiber ja schauen ob die beiden ATAPI-Laufwerke das ISO9660-Dateisystem benutzen. Hmm... mal schauen wie ich das machen werde.

[bluecode]

@bluecode: Wieso? Wo hakts denn bei deinem ATAPI-Treiber noch?

Ich habe ja ein neues OS begonnen und da bin ich logischerweise noch nicht bis zum ATA/ATAPI Treiber vorgedrungen.

Jo, vielleicht schreibe ich bald ins Wiki.

Das wäre natürlich eine tolle Sache.

Ich bin jetzt nur am überlegen wie ich die ATAPI-Laufwerke registrieren soll. Denn ich muss dem OS ja irgendwie sagen, dass jetzt ATAPI-Laufwerke vorhanden sind. Und dann muss ich die noch mit dem Dateisystemtreiber in Verbindung bringen.

Kannst dir ja das Linux Model mit dem /dev Verzeichnis und dem "mounten" von Geräten mal anschauen, dann kriegst du bestimmt eine Idee.

[bitmaster]

Also ich komme irgendwie nicht dahinter wie das Zusammenarbeiten mit einem OS, einem Laufwerkstreiber und einem Dateisystemtreiber funktionieren soll.

Sagen wir mal mein ATAPI-Treiber hat jetzt ein ATAPI-Laufwerk an IDE0,0 gefunden. Jetzt muss es meinem OS ja irgendwie über die Betriebssystemfunktionen sagen, dass ein "neues" Laufwerk vorhanden ist. Also ich habe mir gedacht, dass ich vielleicht eine Funktion zur Verfügung stelle, die ein Laufwerk registriert unter Angabe von Laufwerksbezeichnung (also z.B. "cd0" oder egal was (auch "hans37")), Laufwerksgröße (Anzahl der Sektoren), Sektorgröße usw. Dann müsste ich aber auch noch eine genaue Laufwerkstreiberzuweisung angeben lassen (z.B. "ATAPI" als string), damit die VFS-Funktionen meines OS dann auch den richtigen Treiber ansprechen (z.B. beim Lesen oder Schreiben von Sektoren).

Aber wie mache ich das eigentlich, dass eine normale Anwendung nicht mit dem ATAPI-Treiber kommunizieren kann (oder ist das egal, wenn man das erlaubt) aber das VFS mit dem Treiber kommunizieren kann. Außerdem muss man dem ATAPI-Treiber ja über IPC/RPC z.B. beim lesen eines Sektors den ide-channel und das master/slave device angeben. Aber das ganze ist dann ja nicht mehr wirklich Laufwerksunabhängig und somit nicht wirklich für ein Ansprechen des ATAPI-Treiber seitens des VFS geeignet.

Hmm... ich glaube ich habe in dem Bereich große Wissenslücken. Aber vielleicht könnt ihr mir ja helfen. Denn mir schwirren da unendlich viele Sachen durch den Kopf, aber nichts was wirklich Hand und Fuß hat.

danke!!!

[Korona]

In meinem OS läuft die Kommunikation der Treiber mit den Anwendungen und die der Treiber untereinander über ein ähnliches Interface ab, wie TCP/IP Sockets unter Windows/Linux/BSD etc.
Es gibt Server (identifiziert durch einen Namen) zu denen sich Clients verbinden können und dann Bytes schicken können.
Um das ganze übersichtlicher zu gestalten plane ich einen Device Manager einzubauen, einfach ein Programm, bei dem alle Treiber registriert werden und in Klassen (Blockdevice, Netzwerkkarte, Tastatur, Grafikkarte, Terminal etc.) eingeteilt werden. Zusätzlich wird dann noch für jede Klasse ein default Treiber zugewiesen. Eine Anwendung kann dann einfach den Device Manager nach dem benötigten Gerät fragen oder das default Gerät benutzen. Manche Geräte, wie das Terminal auf dem die Anwendung läuft oder (bei Fs Treiber) auf welche Festplatte der Fs-Treiber zugreifen soll, wird man durch das Setzen von Environment Variablen zuweisen könnten (bzw. die Vorgabe vom Device Manager überschreiben können).

[bitmaster]

So, ich habe mir gedacht, dass ich in meinem OS ja eine Art Tabelle benötige, in der alle Geräte eingetragen werden. Über eine Bibliotheksdatei (in der vielleicht sogar die Tabelle stecken könnte  ) wie z.B. Dev.lib könnte man dann Geräe hinzufügen oder entfernen und informationen über ein spezielles Gerät auslesen etc. Dann würde genau ein Datensatz informationen über ein Gerät beinhalten. Ich grüble die ganze Zeit welche Informationen denn ein Datensatz beinhalten könnte. Bis jetzt sind mir folgende durch den Kopf gegangen:

-Geräteklasse (Zeichenkette) z.B. mouse, keyboard, cdrom etc.
-Anzeigename (Zeichenkette) z.B. SONY DVD RW DRU-800A ATA Device
-PID des zugehörigen Treibers  damit das OS auch den zugehörigen Treiber anspricht 
-Laufwerksbit z.B. 0 = kein Laufwerk, 1 = Laufwerk
-wenn Laufwerksbit = 1, dann Laufwerksbezeichnung z.B. cd0, fd0 etc.
-wenn Laufwerksbit = 1, dann PID des zugehörigen Dateisystemtreibers  damit das VFS auch den richtigen Dateisystemtreiber anspricht 

Oder sollte man den Anzeigenamen vom Treiber laden und nicht in die Tabelle schreiben? Bzw. was habe ich eurer Meinung nach vergessen bzw. was gehört nicht in die Tabelle. Wäre es nicht noch vernünftig jedem Gerät eine ID zuzuweisen (Größe? Byte, Word oder noch größer?, weil mehr als 255 Geräte wird man wohl nicht an einem PC anschließen (können) oder?)?

Ach ja, und dann muss ja noch eine Art Device-Byte in die Tabelle? Denn wenn das VFS ein Laufwerk anspricht und dann den Treiber, dann muss ja z.B. der ATAPI-Treiber wissen ob das Gerät an IDE0,0 oder bis IDE1,1 angeschlossen ist.

Da einige von euch ja bereits funktionierende Geräte- Dateisystem- und Laufwerkstreiber für ihr OS geschrieben haben hoffe ich doch mal, dass ihr mir helfen könnt. Ich wäre euch sehr dankbar.

bitmaster