Lowlevel
OffZone => Offtopic => Thema gestartet von: bitmaster am 06. May 2008, 22:37
-
So, einbisschen verspätet:
Deutscher Meister 2008!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Pokalsieger 2008!!!!!!!!!!!!!!!!!!!!!!!!!
Ligapokalsieger 2007!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Jaaaaaaaaaaaaaaaaaaaaaaaaa!!!!!!!!!!!!!!!!! ^^
feiern feiern feiern
Und mit einbisschen mehr Härte und Verstärkung wirds auch international wieder was.
geile Saison
Nur der FC Bayern München!!!!!!!!!!!! rot regiert!!!
EDIT: Uups jetzt habe ich meine Frage vergessen. Woran kann es liegen, dass ein ATA Treiber unter Emus funst aber unter einem RealPC net (ATAPI geht)?
thx
-
http://www.orf.at/?href=http%3A%2F%2Fwww.orf.at%2Fticker%2F288093.html
Muss man der vollständigkeit halber auch erwähnen...
Gruss
-
http://www.orf.at/?href=http%3A%2F%2Fwww.orf.at%2Fticker%2F288093.html
Muss man der vollständigkeit halber auch erwähnen...
Gruss
Das 1:3 gegen Stuttgart und das 0:2 gegen Cottbus etc. hast du vergessen. Aber im goßen und ganzen war es eine richtig gute Saison.
Also ich komme nicht dahinter, warum mein ATA Treiber nicht funzt. Beim ausführen des PACKET Befehl funst alles (sonst würde der ATAPI ja net gehen). Aber die anderen ATA Befehle wie z.B. READ etc. funktionieren auf einem RealPC net. kA wieso
-
Also ich komme nicht dahinter, warum mein ATA Treiber nicht funzt. Beim ausführen des PACKET Befehl funst alles (sonst würde der ATAPI ja net gehen). Aber die anderen ATA Befehle wie z.B. READ etc. funktionieren auf einem RealPC net. kA wieso
Hällst du den die von den Specs vorgeschriebenen Timings bei den I/O Operationen ein? :wink:
-
Also ich komme nicht dahinter, warum mein ATA Treiber nicht funzt. Beim ausführen des PACKET Befehl funst alles (sonst würde der ATAPI ja net gehen). Aber die anderen ATA Befehle wie z.B. READ etc. funktionieren auf einem RealPC net. kA wieso
Hällst du den die von den Specs vorgeschriebenen Timings bei den I/O Operationen ein? :wink:
Nö ^^
-
Könnte vllt daran liegen. :wink:
-
@Homix: Bei euch geht es ja wieder richtig zur Sache. ^^
Noch nie so einen dummen Verein gesehen.
Der Ziffzer hat es ja mal ausgesprochen.
Na ja, das blaue Pack halt. Die Fans, die Spieler, die Verantwortlichen, alles Vollpfosten.
Wie süß die versuchen an Geld zu kommen. Vielleicht sollten sie ja wieder betteln gehen.
Da haben die "Fans" sich gefreut, dass Hoeneß den "Verein" gerettet hat. Dabei haben sie nicht mitbekommen, dass es die echten 59er gar nicht mehr gibt. Ich meine, ich hätte den Verein ja erbärmlich betteln lassen und zugrunde gehen lassen. Aber so wie es jetzt ist, ist es ja noch "schlimmer". Vielleicht hatte Hoeneß eine Kristallkugel.
Na ja, die Löwen zerfleischen sich, die Löwen zerfleischen sich, die Löwen zerfleischen sich oleeee oleeee oleeeeeeee
@bluecode: Es klappt, thx!
-
@bluecode: Es klappt, thx!
Woran lags denn genau?
-
@bluecode: Es klappt, thx!
Woran lags denn genau?
Ich habe im Doku nachgeschaut an welcher Stelle ich wie lange warten muss und habe dann ein Kommentar hinzugefügt und eine kleine Schleife. Also z.B. so:
;warte 2ms
mov ecx,0FFFFFh
loop $ ;später ändern
Und wenn ich dann mal einen funktionierenden Timer habe, dann kann ich exakt warten lassen. Aber bis dahin reicht das. Aber kann ein Timer eigentlich in Millionstelsekunden warten? Ich dachte immer das ginge nur in Tausendstelsekunden.
-
Der APIC Timer und die HPET haben Auflösungen im Nanosekundenbereich.
-
Der APIC Timer und die HPET haben Auflösungen im Nanosekundenbereich.
Ach so, ja dann. thx
-
Könnte mir jemand von euch den Befehl "EXECUTE DEVICE DIAGNOSTIC" erklären? Also ich verstehe nicht warum das DEV-Bit im Device-Register keine Rolle spielt. Da steht ja "DEV shall be ignored". Man soll also nur das Command-Register auf 90h setzen. Dann steht unten aber für die Ausgabe "When this code is in the Device 0 Error register" und "When this code is in the Device 1 Error register". Das verstehe ich nicht. Und woher soll dann der Befehl "EXECUTE DEVICE DIAGNOSTIC" wissen welches Device gemeint ist? Und was ist ein "Device 0 Error register" und ein ""Device 1 Error register"?
Den Befehl brauche ich, um zu testen wie viele Laufwerke überhaupt vorhanden sind.
Vielleicht kann mir ja einer von euch helfen.
danke!!!
-
6.13.8 Description
This command shall cause the devices to perform the internal diagnostic tests. Both devices, if present, shall
execute this command regardless of which device is selected.
Ich würde aber eher so (http://www.osdev.org/wiki/ATA_PIO_Mode#Detection_and_Initialization) vogehen.
-
@bluecode: Was genau meinst du?
Da steht ja "This method does not work for detecting ATAPI devices -- their RDY bit is always clear (until they get their first PACKET command)."
-
All current BIOSes have standardized the use of the IDENTIFY command to detect the existence of all types of ATA bus devices ... PATA, PATAPI, SATAPI, SATA.
Das meine ich.
There are two other nonstandard techniques that are not recommended:
1. The first is to select a device (then do a 400ns delay) then read the device's Status Register. For ATA devices that are not "sleeping", the RDY bit will always be set. This should be detectable, just so long as you have already tested for float (where all the bits are always set). If there is no device, then the Status value will be 0. This method does not work for detecting ATAPI devices -- their RDY bit is always clear (until they get their first PACKET command).
2. The other method is to use the Execute Device Diagnostics command (0x90). It supposedly sets bits in the Error Register (0x1F1 on the Primary bus) to show the existence of master and slave devices on the bus
Das "not revommended" bezieht sich auf die zwei Methoden die danach folgen. :wink:
-
Dann bleibt also nur noch das über: "The other method is to use the Execute Device Diagnostics command (0x90). It supposedly sets bits in the Error Register (0x1F1 on the Primary bus) to show the existence of master and slave devices on the bus."
Aber genau so wollte ich es doch machen. Ich verstehe nur nicht wieso das DEV-Bit ignoriert wird und woher das "EXECUTE DEVICE DIAGNOSTIC" dann wissen soll welches Device gemeint ist.
-
Les bitte nochmal was ich zitiert habe. Ich hab doch extra "two other nonstandard techniques" und "not recommended" fett hervorgehoben, danach einen Doppelpunkt gemacht und dann eine Liste mit zwei Punkten... :roll:
Nur um das ganz klar zu sagen: Deine Methode fällt unter "not recommended". :wink:
-
Sag mal, liest du eigentlich was bluecode schreibt? Dort steht doch, dass diese Methode nicht empfohlen wird? Und die Frage wegen EXECUTE DEVICE DIAGNOSTIC hat er ja auch schon beantworten.
Happerts beim Lesen allgemein oder nur beim Englisch? :|
-
Uups, ja das kommt davon wenn man nebenbei am kochen ist. Sry, muss eben nach mein Essen schauen. Bin gleich weider da.
-
So, bin wieder da. Wenn ich jetzt alles richtig verstanden habe meinst du den Befehl "IDENTIFY DEVICE". Wieso steht da "Then read the Status port (0x1F7) again." Muss ich den zuvor bereits ausgelesen haben? Und wenn jetzt also der ausgelesene Wert Null ist, dann existiert das Device nicht? Und wenn es existiert dann halt testen ob BSY, ERR etc. und ggf. die 256 WORDs auslesen. Und wenn das Device nicht existiert? Dann nichts weiter machen? Oder irgendwie noch was reseten? So, scheiße mein Essen. *schnell ab in die Küche*
-
Ich nehme an es bezieht sich auf das hier (http://www.osdev.org/wiki/ATA_PIO_Mode#400ns_delays):
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.
-
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!!!
-
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. :roll:
-
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
-
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.
-
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!!!
-
Aber im Hinblick [...] auf meinem Treiber war das gut.
Blöderweise verhilft das meinem ATA/ATAPI Treiber nicht zur Existenz. :-P
Aber du könntest ja etwas an die Community zurückgeben und unseren Wikiartikel ausbauen. :wink:
-
@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: 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. :wink:
-
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!!!
-
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).
-
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