Beiträge von hitman20

In der Methode

findest Du deine Werte die für die Batterie zuständig sind. In dem Fall musst Du nur BCM1 und BCM2 anpassen dieser hat aber ein Wert von 40. Diese gehen dann aber mit meiner Methode nicht mehr. Dort muss ich mal schauen wie das mit denen geht. Meine DSDT's hatten immer nur bis 32. Bei meinem Dell XPS musste ich z. B. gar nichts anpassen. Die Zeile

die Du Patchen musst, macht eine Verkettung aus den zwei Werten BCM1 und BCM2.

Welche Warning meinst Du oben mit iASL Warning:? In dem Thread habe ich nichts gefunden, das Du was mit iASL Warning geschrieben hast oder habe ich es vielleicht nur übersehen? Man kann noch andere Methoden mit aufnehmen in die refs.txt aber das ist dann wieder DSDT abhängig ob dort vom iASL Compiler etwas nicht korrekt interpretiert werden kann. In der refs sind eigentlich schon die wichtigsten Methoden enthalten, die man benötigt.

Edit: @BlackOSX Ich habe mal die DSDT bearbeitet, bin mir aber nicht sicher ob das wirklich funktioniert. Kannst Du das bitte mal bei Dir testen?

@BlackOSX Habe die DSDT_bat.aml ausgetauscht. Den Tippfehler habe ich behoben. Dieser ist mir wahrscheinlich nicht aufgefallen weil beim Kompilieren kein Error kam. Danke.

Hast Du mal versucht nur nach "EmbeddedControl" zu suchen oder mal einzeln nach den Worten "ByteAcc oder Lock oder Preserve" ob dort was kommt? Vielleicht klappt es auch wenn Du in deiner DSDT mal nach

suchst oder mal nur nach _BIF oder Battery Information ob dort was kommt. In dieser Methode sollten auch die Worte stehen die verändert werden müssen.
Sollte dort nichts kommen kannst Du vielleicht danach noch schauen

oder dann mal nur nach _BST: Battery Status bzw. Battery Status suchen.

Vielleicht findest Du über die Worte dann die Methode die für deine DSDT korrekt ist. Du kannst mir ja sonst deine DSDT auch mal hochladen dann kann ich mal nachschauen.

Danke @BlackOSX das war ein Tippfehler von mir. Ich habe es in meinem Beitrag korrigiert.

Hallo,

da die Frage öfter mal aufkommt, wie man den Batteriestatus korrekt unter OS X anzeigen kann, möchte ich euch hier in dem Tutorial erklären, wie man dafür die DSDT korrekt patched. Ich habe im Forum noch keine Anleitung dafür gefunden.

Ihr braucht dazu auch die ACPIBatteryManager.kext im Ordner /EFI/CLOVER/kexts/Other oder /System/Library/Extensions oder in /Library/Extensions sonst funktioniert es nicht.

Wenn Ihr eure bereits funktionierende DSDT.dsl mit MaciASL öffnet, solltest Ihr zuerst nachdem Wort "EmbeddedControl" suchen. Dort solltest Ihr in der Regel gleich in der "Operation Region" landen.
Wenn unter der "Operation Region" das Feld "Field (ECRM, ByteAcc, Lock, Preserve)" steht seid Ihr auf jedenfall richtig.

Dort sollte nun eine ganze Reihe von Wörtern stehen, die dahinter lauter Zahlen haben wie z. B. 8 ,16, 32 usw. Es kann natürlich sein das nicht alle Zahlen vorkommen.

Dies sollte dann ungefähr so aussehen wie im Spoiler.

Wenn Ihr dort dann seid, müsst Ihr nach den Werten suchen die alle Grösser 8 sind. Also dann 16, 32 usw. Die Wörter mit dem Wert 8 müssen nicht bearbeitet werden. Das Wort "CTL1" hat zwar den Wert 16 aber wenn ich weiter in der DSDT suche, kommt dieses nirgends mehr vor. Diese müssen dann nicht bearbeitet werden. Es müssen nur die Wörter bearbeitet werden, die auch dann in der DSDT noch gefunden werden wenn man diese sucht.

Damit die Methode zum Patchen funktioniert, müsst Ihr noch Methoden in die DSDT hinzufügen, damit diese die Aufteilung dann versteht.
Wenn Ihr nur Werte mit 16 habt reicht eine Methode schon aus. Bitte diese im MaciASL über die Patch Methode importieren und einfach in das Textfeld ein kopieren und mit "Patch" bestätigen.
Die Methoden zum Einfügen sind in den Spoiler zu finden.
Methode B1B2:

Wenn Ihr Werte mit 32 habt braucht Ihr diese Methode noch zusätzlich:
Methode B1B4:

Wenn Ihr die Methode(n) importiert habt und sich die DSDT noch ohne Fehler kompilieren lässt, kann man mit dem Patchen beginnen.

In meinem Beispiel wird dann dann das Wort "CAP0" nochmal gefunden wenn ich weiter danach in der DSDT suche. Dort taucht dann die Zeile auf.

Danach geht man nochmal in die "OperationRegion (ECRM, EmbeddedControl, Zero, 0x0100)"
und fügt jetzt zwei neue Zeile hinzu und erstellt z.B. einen Wert "CAPX, 8," und "CAPY, 8," und kann dann den Wert "CAP0, 16," löschen, da diese jetzt in die zwei Werte "CAPX" und "CAPY" aufgeteilt wurden. Die aufgeteilten Wörter müssen immer den Werten der originalen Wörter entsprechen also CAP0 hatte 16 und deshalb muss dieser nur zweimal aufgeteilt werden. Bei einem Wert mit 32 müsste dieser in vier Teile aufgeteilt werden. Nach der Änderung der Wörter kompiliere ich die DSDT nochmal und dann sollte so ein Fehler auftreten "Object not found or not accessible from scope (^^PCI0.LPCB.EC0.CAP0)" Wenn Ihr diesen Fehler anklickt kommt Ihr gleich in die betroffene Zeile und müsst nicht nochmal neu suchen.

Für Werte die nur 16 haben kommt die Methode B1B2 zum Einsatz und für Werte die 32 haben kommt B1B4 zum EInsatz die wir vorher importiert haben.

Da für das Wort "CAP0" diese Zeile noch gefunden wurde

müssen wir diese jetzt auf unsere geänderten Werte CAPX und CAPY abändern. Die neue Zeile würde jetzt so aussehen

Wenn Ihr das richtig angepasst habt, sollte sich die DSDT ohne Fehler kompilieren lassen, am besten die DSDT nach jeder Änderung einmal kompilieren falls Ihr euch vielleicht irgendwo vertan habt. Dieses vorgehen macht Ihr nun für alle Werte die grösser 8 sind und auch in der DSDT noch gefunden werden. Wenn Ihr alles richtig gemacht habt, solltet Ihr dann einen korrekten Batterie Status haben.

Hätte das Feld CAP0 den Wert 32 gehabt, hätte ich dieses so aufgeteilt

Die Store Methode in der der Wert "CAP0" vorgekommen ist, müsste dann so aussehen:

Es kann auch sein das bei euch Felder noch vorkommen die den Wert 64 oder grösser haben. Mit diesen hatte ich noch nichts zu tun und kann diese leider dort hier nicht beschreiben, wie mit diesen vorgegangen wird.

Ich habe meine unbearbeitete DSDT Datei mit Namen DSDT.dsl hochgeladen und die bearbeitete mit dem Namen DSDT_bat.dsl, so das man die Änderungen nachschauen und auch nachvollziehen kann, wenn man dies an seiner eigenen DSDT probiert.

Ich hoffe das war soweit verständlich erklärt.

Gruss

Ich habe diesmal die DSDT aus meinem ersten Post genommen wenn die DSDT von @derHackfan auch schon eine Kernel Panik ausgelöst hat. In meiner ist momentan nur der hoffentlich funktionierende Battery Patch enthalten ohne weitere Patches. Sollte diese funktionieren, kann diese dann um weitere Patche erweitert werden.

Solltest Du dort auch wieder ein Verbotszeichen bekommen bitte in den Clover Bootflags noch den Wer "-v" anhängen dann sollte man sehen wo es hängt. Bitte die Datei dann wieder entsprechend umbenennen.

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.

@razer5786 Versuch mal bitte folgende DSDT ob diese Dir den Batterie Status gibt. Ich habe DSDT.aml aus dem Post von @derHackfan genommen weil diese schon die Grundpatches enthält. Bitte die DSDT_bat.aml dann in DSDT.aml umbenennen.

Hatte mich am Befehl vertan deiner ist natürlich richtig @BlackOSX. Ich habe meinen Beitrag noch korrigiert. Die Datei muss dann im Befehl enthalten sein damit es funktioniert.

@derHackfan Die Schritte füge ich morgen dem Thread hinzu die ich in meinem vorherigen Beitrag geschrieben habe und gemacht habe.

@derHackfan Ich habe mir die DSDT und die SSDT Dateien von @razer5786 genommen und in einen Ordner kopiert und dort eine Datei namens refs.txt erstellt mit folgendem Inhalt

Danach habe ich versucht diese mit dem Befehl "iasl -da -dl -fe refs.txt DSDT.aml SSDT*.aml" decompiliert in .dsl Dateien. Dort kam dann der Fehler

Ich habe dann mit dem Befehl "grep -l MSID*.aml" den doppelten ACPI Eintrag MSID gesucht wo dieser noch vorkommt.
Dieser kann in der SSDT-1 und SSDT-12 vor. Die SSDT-1 habe ich gelöscht, weil diese gleich mit der SSDT-12 war. Danach habe ich wieder den Befehl iasl -da -dl -fe refs.txt DSDT.aml SSDT*.aml angewendet und dann war die Decompilierung erfolgriech und dann ahbe ich nur die "Zero" Einträge bereinigt und dann kamen keine Fehler mehr. Hoffe das war soweit verständlich und Du kannst es bei Dir nachvollziehen. Die SSDT Dateien mit x habe ich weg gelassen.

@derHackfan In der DSDT waren Einträge mit dem Namen "Zero" mehrfach vorhanden und diese Einträge habe ich gelöscht in den entsprechenden Zeilen und dann konnte die DSDT ohne Fehler kompiliert werden. Dies war der einzige Fehler. Hatte ich auch in meinem Beitrag geschrieben. Die Fehler waren 5501, 6126, syntax error, unexpected PARSEOP_ZERO, 5530, 6126, syntax error, unexpected PARSEOP_ZERO und 9013, 6126, syntax error, unexpected PARSEOP_SCOPE, expecting $end and premature End-Of-File. Der letzte Fehler hat sich dann mit den Bereinigungen von selbst gelöst.

Hallo @razer5786,

ich habe deine DSDT mal von den Fehlern bereinigt und die Einträge "Zero" gelöscht. Allerdings ist diese noch ungepatcht. Eventuell kann Dir dort @al6042 weiterhelfen oder Du versuchst es selber mit MacIASL zu patchen.

Mit DSDT habe ich immer nur ein Gerät angezeigt bekommen unter High Sierra. Ich habe mir die Geräte in den Systeminformationen alle über eine SSDT gepatcht anstatt über die DSDT. Unter Sierra geht auch alles. High Sierra ist ja auch noch Beta. Wenn ich mit -lulubeta und -alcbeta komme ich gar nicht mehr ins System. Einmal hat es funktioniert. Ich installiere das glaub nochmal neu.

Ist euch unter High Sierra schon aufgefallen das in den Systeminformationen unter PCI nicht alle Geräte auflistet werden? Unter Sierra hatte ich noch kein Problem damit.

Die config und DSDT habe ich komplett neu gemacht. Das komische ist nur das das Verhalten sonst nie aufgetreten war egal wie die DSDT gepatcht war. Ich habe auf die selbe Festplatte mal den Clover Ordner von der funktionieren Festplatte kopiert und dort tritt das Verhalten nicht auf allerdings wurde dort nichts mit DSDT gepatcht sondern nur mit SSDT's. In den Dateien pmset.txt und kextstat.txt konnte ich jetzt keine unterschiede Feststellen. Ich denke das mit vielleicht irgendein DSDT Patch fehlt damit der Rechner aus dem Sleep wieder korrekt erwacht.

Hallo zusammen,

ich habe auf meinem Dell XPS nochmal Sierra neu aufgesetzt auf einer anderen Festplatte weil ich mit dieser n bisschen testen wollte, ohne mein funktionierendes Sierra auf der anderen Festplatte kaputt zu machen.

Ich habe meine DSDT und SSDT's soweit gepatcht wie ich es für richtig befunden habe und konnte auch alles soweit starten ohne Probleme. Das komische an diesem Setup ist nur sobald ich den Laptop in den Sleep Mode schicke bleibt er auch normal im Sleep, sobald ich aber über den Power Button drücke geht der Laptop zwar an aber Bildschirm bleibt schwarz und nach ca. 15 Sekunden höre ich die Lüfter aber nichts passiert.
Ich kann den Laptop erst wieder starten wenn ich diesen komplett abwürge. Mit meiner anderen Festplatte auf dem das "richtige" Sierra installiert ist, geht alles ohne Probleme und der Laptop ist in ein paar Sek. nachdem Sleep wieder da. Allerdings habe ich dort die "Hotpatch" Methode angewendet mit den SSDT's von Rehabman aber auch als ich ohne die Hotpatch Methode gearbeitet habe, war dieses verhalten nicht da. Erst seit dieser Neuinstallation unter High Sierra habe ich das verhalten auch allerdings habe ich es dort zuerst auf die Beta geschoben und wollte Sierra nochmal testen ob ich es dort nachstellen kann was aktuell der Fall ist.

Eventuell kann es auch mit dem neuen BIOS Update zusammenhängen aber dies habe ich schon ein paar Monate installiert.

Habt Ihr dafür noch eine Lösung was dieses Verhalten auslösen kann?

Ich habe meinen Clover Ordner und die DSDT und SSDT's mal angehangen im .dsl Format. Dort sind auch die Patche beschrieben die ich angewendet habe.

Danke.

Gruss

hitman20

Mit einer Fritz Box habe ich das nie getestet aber wenn Du einen Root Server hast, könntest Du dort ja vielleicht eine weitere VM aufsetzen mit einem VPN Server und eigener öffentlichen IP und über die Fritz Box wenn es mit dieser geht einen VPN Full Tunnel zu deiner VPN VM aufbauen so dass jeder Traffic über deine VM geroutet wird und Du dann mit der IPv4 von deiner VM surfst. Wegen der Portfreigabe, wirst Du wahrscheinlich eine Layer 2 Verbindung brauchen damit eine Point to Point Verbindung aufgebaut wird und deine Fritz Box und deine VM in einem Netzwerk sind und über die VM wenn Du Linux benutzt mit IPTables dann die Portfreigaben machst für die IP Adressen in deinem LAN. Wenn die IP Adressen in deinem LAN und mit der Point to Pint Verbindung unterschiedlich sind, musst Du routen damit sich die Netze sehen und dann auch die Portfreigaben funktionieren.

Kann natürlich sein das dass von mir auch falsch gedacht ist, aber vielleicht hilft es dir etwas.

Vielleicht ist das bei meinem Laptop auch wieder was anderes warum das nicht korrekt läuft. Wären die beiden Mainboards aus deiner Sicht in Ordnung die ich nehmen könnte? USB-C Geräte habe ich sonst keine ausser meinen Dell DA 200 Adapter. Als CPU würde ich dann den i3 7100 nehmen und wahrscheinlich 8GB RAM oder evtl einen 16GB RAM Riegel was es bei DDR4 ja gibt.

@Dr.Stein Mit USB 3.1 bin ich mir halt nich so sicher ob das OOB läuft weil bei meinem Dell XPS der auch einen USB 3.1 Anschluss mit Thunderboilt hat ist es so das die Gerät beim Booten eingesteckt sein müssen damit diese erkannt werden und der Hotplug dort nicht funktioniert.
Das Mainboard Gigabyte GA-B250N-Phoenix WIFI und Asus ROG Strix B250I Gaming würden für mich infrage kommen. Nur beim Asus kann ich nicht erkennen, ob die WLAN karte fest auf dem Mainboard integriert ist. Laut Mindfactory hat es auch einen PCIe 3.0 x16 Anschluss.

Danke. Ich habe mir das MSI Board mal angesehen aber dies hat leider keine USB 3.0 Ports und nur 2.0. Die anderen 1151 Mainboards muss ich mal noch durchshauen ob ich dort was finde was für mich passt. Ersetzen soll das System mein Hystou Barebone. Dieser hat auch Mini ITX aber 4 USB 3.0 und 4 USB 2.0 ob es das bei Skylake bzw. Kaby Lake gibt weiß ich nicht weil ich mich damit noch zu wenig auseinandergesetzt habe.