DSDT Sammelthread (Hilfe und Diskussion)

Spannendes Thema! Die Zeilen, die einen Syntaxerror verursacht haben, hast du entfernt, oder?

@Harper Lewis nicht immer komplett. Bin da auch erstmal Bild vor zurück und wieder vor

Über die anfängliche Fehler in der rohen DSDT kann ich keine neuen Erkenntnisse beibringen, da bei meinen DSDTs (Desktop und Hackbook) nur die üblichen Fehler auftraten, die schnell zu beseitigen waren (siehe WiKi “ACPI -> Grundlegende Schritte zum Erstellen einer gepatchten DSDT - Desktops).

Bei meinem Hackbook hatte ich aber ganz andere Probleme. Für ein Notebook fand ich den Patch “Rename GFX0 to IGPU” ganz wichtig. Immer wenn ich diese DSDT dann benutzte, wurde der SATA-Controller und damit die SSD nicht mehr erkannt. Klinkt total zusammenhanglos, aber es war nun mal so. Wenn man keine Ahnung hat versteht man auch manche Zusammenhänge nicht. Logisch oder?

Durch mehrere Vergleiche unterschiedlicher DSDTs änderte ich dann nochmal das Device MCHC, welches vorher so aussah.

Nachher:

Seit dem klappt es auch mit dem SATA-Controller, was vielleicht daran liegt, dass wieder ein Device (GFX0) vorhanden ist.
Falls jetzt ein DSDT-Versteher hier fragt, ob ich was falsches geraucht habe. Nein, ich bin Nichtraucher und verstehe weder warum es vorher nicht, noch warum es danach funktioniert. Aber es freut mich schon, dass es funktioniert.

Zitat von derHackfan

dass das Patchen einer rohen DSDT gar nicht so schwer ist

Insofern gebe ich dir recht, solange man weiß welche Patches denn überhaupt angewendet werden müssen. Was auch voraussetzt, dass man weiß für welches Wehwehchen der jeweilige Patch Linderung verspricht. Ich glaube, dass das die am höchsten liegende Latte beim DSDT-Patching ist, die übersprungen werden muss.
Und wenn, wie du erwähnt hast, gar kein fertiger Patch vorhanden ist, guck ich ich ganz doof in die Röhre oder was auch immer.

PS. Meine eigene DSDTs kriege ich schon ganz gut hin (so zum lernen, denn ich habe ja eine fertige), aber mit einer fremden, die vielleicht noch viel anders aufgebaut ist, würde ich wahrscheinlich kläglich versagen. Vor allem scheitere ich immer noch am Auslesen eines IOReg-Dumps um das Ergebnis in die DSDT zu übertragen.

Beispiel um eine bereinigte DSDT zu bekommen, welche oft vorkommt

Lösung

"Arg"-Einträge entfernen bzw. Auskommentieren

Das ist, glaube ich, der Erstfehler bei fast allen DSDTs. Du hast sie auskomentiert ich lösch sie immer. Ergebnis ist in jedem Fall dasselbe.

Vielleicht ist es hilfreich immer mal dazu zu schreiben, warum die jeweilige Änderung notwendig ist.
Zu den ArgN Variablen nach dem Return:

Die _DSM Methode (im Prinzip eine Funktion) nimmt 4 Parameter entgegen ("Method( _DSM, 4, Serialized)"). Die Werte dieser Parameter lassen sich innerhalb der Methode der Reihenfolge nach als Arg0, Arg1, ... ansprechen und etwa an andere Methoden wie in Zeile 12273 PCID(Arg0, Arg1, Arg2, Arg3) ebenfalls als Parameter übergeben. Die Methode PCID wird in dieser Zeile aufgerufen, macht etwas mit diesen 4 Werten und liefert dann einen Wert zurück, welcher dann dank Return([Rückgabewert von PCID]) jenen Wert als Ergebnis der _DSM Methode liefert. Somit kommt dann irgendwo dort, wo ursprünglich die _DSM Methode aufgerufen wurde, ein [Rückgabewert von _DSM] an. Zurück zum eigentlichen Problem mit den ArgN nach der Return() Funktion: Sobald die Return() Funktion aufgerufen wurde, wird in dieser Methode kein nachfolgender Code mehr verarbeitet, das heißt, dass die 4 herrenlosen ArgN Variablen nach dem Return vollkommen unnütz sind.

Wie kommen die 4 ArgN überhaupt dort hin? Wahrscheinlich wurde die original DSDT mit einer anderen ACPI Version erstellt und wird daher von MaciASL etwas missverstanden.
Ich vermute, dass die Zeile 12278 eigentlich so aussehen müsste: Return(SDSM(Arg0, Arg1, Arg2, Arg3)), statt einfach die ArgN zu löschen. Euch fällt sicher die Ähnlichkeit zur Zeile 12273 auf. Wenn ich mit meiner Vermutung richtig liege, gibt es irgendwo in der Nähe eine Zeile Method(SDSM, 4, ... - die 4 ist ein Indikator dafür, dass Arg0, Arg1, Arg2, Arg3 nicht einfach auskommentiert gehören, sondern eine mehr oder weniger wichtige Funktion haben, weil die Methode bis zu 4 Parameter erwartet.

Vielen Dank @Thogg Niatiz für die ausführliche Eklärung. Ich als DSDT-Nichtversteher bin immer auf so etwas angewiesen. Ich übernehme etwas in die DSDT, was ein anderer an anderer Stelle erklärt hat und hoffe dass es funktioniert, was es meistens auch macht. Um das richtig zu vestehen, benötigt man wahrscheinlich Programmierkenntnisse, die ich leider nicht habe.

@Thogg Niatiz Danke für deine Erklärung.
In dem Fall von oben, erledigt sich das ganze ehe von allein Device (SAT0) und dem Patch SATA

Das wusste ich auch noch nicht. Eben ausprobiert und es funzt. Da haben wir also noch eine weitere Erkenntnis, man muss wissen in welcher Reihenfolge die Patches angewendet werden müssen, dann verschwinden manche Fehler von alleine.

Error: Name already exists in scope

Methode existiert doppelt, innerhalb des Scope

Ich schreibe euch hier mal die Scritte wie eine DSDT richtig decompiliert wird, nachdem diese mit Clover extrahiert worden ist. Die extrahierten *.aml Dateien findet Ihr auf der EFI Partition unter EFI/CLOVER/ACPI/origin. Aus diesem Ordner werden eigentlich nur die DSDT Datei und die SSDT Daten benötigt. Diese nehme ich sicherheitshalber auch noch mit falls in einer Datei mal auf eine Externe Referenz verwiesen wird. Die SSDT Daten die ein "x" im Dateinamen haben z. B. "SSDT-4x.aml" werden nicht benötigt. Bitte die DSDT und die SSDT Dateien in einen eigenen Ordner kopieren.

Damit mein vorgehen funktioniert, benötigt Ihr das Programm MaciASL, das es hier im Forum auch zum Download gibt. Bitte dies herunterladen und am besten nach Programme kopieren. Aus diesem Programm benötigt ihr noch die Datei "iasl61". Diese könnt Ihr euch heraus kopieren, in dem Ihr einen Rechtsklick auf MaciASL macht und dort auf "Paketinhalt anzeigen" geht und dann in den Ordner Contents -> MacOS und dort dann die Datei "iasl61" nach /usr/bin kopiert. Wenn die Datei in dem Pfad /usr/bin ist bitte diese nach "iasl" umbenennen.

Wenn Ihr alles richtig gemacht habt, und Ihr ein Terminal öffnet und den Befehl "iasl" eingebt, sollte folgender Auszug kommen mit noch ein paar Optionen mehr, die ich aber jetzt nicht in den Spoiler gepackt habe.

Wenn der Befehl funktioniert hat, könnt Ihr dann im Terminal in euren Ordner wechseln in dem die DSDT und SSDT Dateien liegen.
Wenn Ihr dann in eurem Ordner seid, bitte den folgenden Text aus dem Spoiler kopieren:

Wenn Ihr diesen Text kopiert habt, dann bitte folgenden Befehl im Terminal ausführen:
pbpaste>refs.txt . Dieser erstellt euch dann die Datei refs.txt mit dem kopierten Inhalt aus der Zwischenablage.

Wenn Ihr das gemacht habt, dann kann man jetzt mit folgendem Befehl die *.aml Dateien korrekt decompilieren. Der Befehl lautet "iasl -da -dl -fe refs.txt DSDT.aml SSDT*.aml". Wenn alles ohne Fehler funktioniert hat, solltet Ihr dann Dateien mit der Endung .dsl erhalten. Danach kann mit maciASL die DSDT.dsl geöffnet werden und Ihr könnt probieren ob sich die Datei bereits ohne Fehler kompilieren lässt. Sollte dies der Fall sein, könnt Ihr euch mit den weiteren Patchen beschäftigen die eure DSDT benötigt, damit alles korrekt läuft auf eurem Hackintosh.

Es kann natürlich auch zu Fehlern kommen wenn Ihr den Befehl "iasl -da -dl -fe refs.txt DSDT.aml SSDT*.aml" ausgeführt habt. wie z.B der im folgenden Spoiler. Dann werden noch keine .dsl Dateien erstellt.

Dort kann natürlich auch ein anderer Wert als "MSID" stehen aber das vorgehen ist dann das selbe. Das liegt dann daran das eine oder mehrere SSDT Dateien doppelt sind, falls dieser Fehler mehrfach vorkommt. Die doppelten SSDT Dateien könnt Ihr mit dem Befehl "grep -l MSID *.aml." herausfinden. Ihr bekommt dann die SSDT Dateien angezeigt die diesen Namen alle enthalten. Eine Datei davon könnt Ihr dann löschen und den Befehl "iasl -da -dl -fe refs.txt DSDT.aml SSDT*.aml" nochmal ausführen und dieser sollte dann erfolgreich sein und dann die .dsl Dateien erzeugen. Es kann natürlich sein das Ihr vielleicht mehrere Dateien habt bei denen ein ACPI doppelt vorkommt. Dann müsst Ihr den "grep" Befehl natürlich öfter ausführen und nach den ACPI Namen suchen die der Compiler anmeckert.

Der Output aus dem grep Befehl sieht dann z. B. so aus

Meine DSDT konnte ich nach diesem vorgehen ohne Probleme kompilieren. Wenn ich meine DSDT ohne diese Schritte kompiliere bekomme ich folgende Fehler:

Ich habe die Fehler auch mal als Screenshot angehangen und auch das Ergebnis nachdem die Aktionen ausgeführt wurden. Manuell musste ich dann nichts mehr bereinigen.

Ich hoffe das war so weit verständlich und hilft euch weiter.