Clover, DSDT, SSDT...... ich bin überfordert :S

Hast du schon mal in unserem Wiki gestöbert?
Grundlegende Schritte zum Erstellen einer gepatchten DSDT - Desktops

Btw: Thread passend verschoben da es sich ja nicht um eine Anleitung von dir handelt.

Für allgemeine Erklärungen und evtl. nötige Optimierungen solltest du auch mal hier vorbeischauen: https://www.hackintosh-forum.d…=40-Nach-der-Installation

Übrigens ist beides nicht Pflicht, du siehst ja wie dein hacky auch ohne funktioniert, aber definitiv nice 2 haves!

meinem skylake haben dsdt und die ssdt's schon ganz gut getan, es war aber im vergleich zu dsdt's von thinkpads ziemlich harter tobak, mich darin zurechtzufinden.
warnungen kann man eigentlich ignorieren, remarks und optimierungen lasse ich mir gar nicht erst anzeigen (man muss sich ja nicht völlig irre machen)
gibts denn errors?

im clover gibts einen timeout haken, mit dem du einstellst, wie lang das menü angezeigt wird. könntest du auf 0 setzen. dann haste aber keine chance mehr, was auszuwählen, wenn es denn mal sein müsste.

die warnungen beziehen sich auf unsauberen code, der aber nicht so fehlerhaft ist, dass er nicht ausgeführt werden kann, ist aber manchmal auch total spitzfindig
beispiel:
"not all controlpaths return a value" (oder so ähnlich) - kriegste weg, in dem du in der entsprechenden methode an die schliessende geschweifte klammer navigierst, und genau vor diese klammer ein "Return (Zero)" (ohne "") setzt.
die warnung kommt aber auch, wenn alle in der methode vorkommenden "untermethoden" einen rückgabewert haben, und keinerlei "if" bewirkt, dass das fehlende Return Zero überhaupt erreicht wird.
dann gibts noch so eine seltsame warnung, dass irgendwas gesetzt wär, aber nicht benutzt wird (Method Local is set but never used (Local3)). da kann man dann eine zeile einfügen:
"And (Local3, Ones, Local3)" (LocalX natürlich entsprechend der warnung)
oder die size mismatch-dinger -> tag is smaller than... da macht man z.b. aus
"CreateByteField (CRS3, \_SB.PCI0.LPCB.SIO1._Y1C._HE, IRQS)" ein "CreateBitField (CRS3, \_SB.PCI0.LPCB.SIO1._Y1C._HE, IRQS)"
muss man halt gucken, welche grösse angegeben ist - bit, byte, word oder qword - recherchiert, was die einzelnen bezeichnungen in bit bedeuten (oder try and error...) und passt entsprechend der warnung an.
eigentlich könnte man das alles ignorieren, aber schon der übersichtlichkeit halber und natürlich dem bastelehrgeiz geschuldet, versuch ich, möglichst wenige warnungen übrigzubehalten.
meistens findet sich eine lösung, wenn man den text der compilerwarnung googelt.

Zitat von grt

bit, byte, word oder qword

Fehlt noch DWORD

hast recht -

da warst du ja noch recht fleissig gestern @seefew

Zitat von seefew

Missing dependency (Device object requires a _HID or _ADR in same scope)

die hab ich auch, und hab auch nix dazu gefunden. mit-der-stange-im-nebel-stochernde tryanderror versuche haben nur zu neuen fehlern geführt, ergo hab ich sie fürs erste da gelassen, wo sie sind.
und wie gesagt, die remarks ignoriere ich von vorne herein, lass ich mir überhaupt nicht anzeigen. sind ja nur "anmerkungen"

Die Remarks sind von iASL eingefügte Kommentare, wie "// Device Address". Optimizations sind Änderungen wie 0x0 => Zero oder andere Optimierungen, die die Lesbarkeit und Verständlichkeit der C-ähnlichen Interpretation des Assemblercodes verbessern sollen. Beides geht beim Kompilieren in Assembler, also "speichern als ASL File" verloren und wird beim erneuten Öffnen mit MaciASL wieder erzeugt, also gibts da nichts auszubessern.

Bezüglich der dependency issues: Die Adresse ist meist eh vorhanden, nur in einen Scope ausgelagert. Darum ist das auch kein Fehler, sondern wird sozusagen als "bad practice" von iASL bemängelt. Auch daran lässt sich natürlich etwas machen, auch wenn es in der Regel echt nur kosmetisch für alle ACPI Fetischisten (wie mich ) ist, nämlich die Adresse vom Scope direkt ins Device geben. Kleine Bilderstrecke:

Durch Anklicken der Warnung ein betroffenes Device ausfindig machen. Normal sollte darin als erstes die Adresse deklariert werden, was hier offensichtlich nicht der Fall ist. Nun könnte man den Scope mit der Adresse suchen, was aber für viele nicht intuitiv sein dürfte...

Wenn man einen "Dummy" Adresseintrag macht, wirft der Compiler einen Fehler, da zwei Adressen beim gleichen Device unweigerlich zu Problemen führen würden. Dadurch wird man aber leicht zum gesuchten Scope geführt.

Hier ist die Adresse, welche man gleich ausschneiden und später im Device einfügen kann.

Durch das Ausschneiden ist im Scope nichts mehr enthalten, man kann ihn also komplett entfernen.

Zurück im Device ersetzt man die Adresse 0x0 durch die korrekte Adresse. Kompilieren et voilá - das Mimimi des Compilers hat ein Ende

Zitat von grt

im clover gibts einen timeout haken, mit dem du einstellst, wie lang das menü angezeigt wird. könntest du auf 0 setzen. dann haste aber keine chance mehr, was auszuwählen, wenn es denn mal sein müsste.

Ist nicht ganz richtig. Ich habe meinen Timeout auch auf Null gestellt, damit der Häcki gleich durchbootet. Wenn du zwischen Bios Post und erscheinen des Apfels wiederholt eine beliebige Taste drückst, erscheint Clover für den Fall das was sein sollte.

@seefew bei mir wurden sogar noch 5 Warnungen angezeigt. Anbei deine Datei zurück. Schau am besten mit diff, was sich gegenüber deiner Datei geändert hat. Dann kannst du es sicher schneller nachvollziehen, als wenn ich das mit 10 Screenshots dokumentiere

Danke @Thogg Niatiz Ich habe soeben bei meiner DSDT auch allen Warnungen beseitigt. Bringt wahrscheinlich nichts als ein gutes Gefühl, aber das ist ja auch immerhin was.

Jupp...habe bei mir auch noch etwas bereinigt...
Da waren es aber andere Warn-Meldungen, nämlich

Das konnte einfach gelöst werden, in dem in das Return (Zero) Statement am Ende der jeweils betroffenen Methode eingefügt wurde...

Jetzt ist das "Compiler Summary"-Fenster nackich...

ich muss noch ran.. missing dependency gibts noch 11 stück, dann ist hier auch alles sauber geputzt (zumindest die dsdt )

Dank @Thogg Niatiz nur 'ne kleine Fleissarbeit.