OpenCore Sammelthread (Hilfe und Diskussion)

bei meinem T430 kann ich auf die DSDT.aml nicht verzichten, die blockiert aber die SSDT-XOSI.aml.

Beim Notebook ist das eine ziemlich große Frickelei.

Habe letztes Jahr mehrere Tage an meinem T520 gesessen, um es von der DSDT zu befreien.

Mac OS und Windows konnte ich über den Picker starten.

Bis auf ein paar Kleinigkeiten lief das ganz gut mit Big Sur und Windows 10.

Hatte nur Probleme mit dem Lichtschalter am Panel. Ich glaube das nennt sich irgendwas mit PNLF.

Ansonsten ist das machbar ohne DSDT. Dauert natürlich. Außerdem bin ich da auch nicht der große Experte.

also für mich ist ACPI in Bezug auf die Syntax der DSDT.aml bzw. der SSDT-*.aml absolutes Neuland. Da brauch ich ml Denkanstöße.

Also um Windows aus OC zu starten, habe ich mit SSDTTime und der Original DSDT.aml (Clover F4) eine SDDT-XOSI.aml generiert. Die funktioniert nur, wenn ich die gepatchte DSDT.aml (Quelle Hardware/Nootebooks/Lenovo/T430 by Sascha_77) deaktiviere. Leider fehlt mir dann aber Audio. Der Versuch aus der DSDT.aml eine SSDT-HDEF.aml zu generieren, ist mit misslungen. Den per c&p in eine leere SSDT mittels Maciasl zu schieben klappt nicht, dass die Syntax zwischen SDDT und DSDT scheinbar vollkommen unterschiedlich ist. Aus dem Export von HackinTool kann ich eine SDDT-HDEF.aml genieren, die auch fehlerfrei kompiliert wird. Nur funktioniert diese nicht. Deren Inhalt kann mit dem Abschnitt der DSDT auch nicht verglichen werden.

Als Alternative blieb noch _OSI in der DSDT.aml anzupassen. Aber da sind die Werte welche für Windows 11 benötigt werden auch schlecht unter zu bringen.

Ich habe alles zusammengepackt und vielleicht schaut da mal jemand drüber. Vielleicht liegt die Lösung ja näher als gedacht.

Arkturus von griven muss hier im Forum auch noch was rumgeistern. Habe mich damals an den EFI von griven und Sascha_77 orientiert. Ich glaube, dass ich die sogar noch auf meinen Datengräbern habe. Ich schau mal. Eventuell hat griven die noch.

Die haben auch eine DSDT

Bin ja auch nicht ganz der ASL Fritz und kenne mich nicht mit deinem Laptop aus aber ich würd jetzt behaupten das das nicht ganz gut klappen kann...

In deinem ORIGINAL DSDT hast du schon einen Device HDEF...

Du kannst jetzt nicht noch einmal mit einem SSDT-HDEF.aml kommen und den gleichen Device verändern wollen.

Das endet mit einem Fehler, ganz klar.

Meiner meinung nach müsstest du um sowas zu erreichen eben den vorhandenen Hdef deaktivieren und einen anderen Device anstelle der original mit veränderten Daten kommen, dafür sind ja die SSDT`s da, SSDT = Secondary System Description Table.

Während du sollche änderungen vornimmst musst du eben auch darauf achten und wissen was du da machst, denn sollche änderungen gelten eben für alle Betriebsysteme, das heisst deine HDEF Device ist dann auch für den Windows genau so, wenn die Treiber die Windows dafür lädt nicht mitspielt crasht es, ganz einfach.

Hier kommt dann eben diese _OSI weiche die du ins SSDT einbaust ins spiel, der guckt dann was sache ist, wenn "Darwin" gestartet wird heisst das für ihn das diese table gilt und die Device HDEF so wie es da steht geladen wird, ansonsten wenn Windows kommt schaltet es aus und es gilt die HDEF Device im originalen DSDT, ergo ist das dann so wie der Hersteller vorgesehen hat für Windows.

Ausserdem bin ich der meinung das das alles mit DSDT veränderungen zu lösen veraltet und unnötig ist.
Das ist dann stures System der immer das gleich gute oder fehlerhafte ladet, daher weg mit DSDT und arbeite nur mit SSDT`s.
Am besten jedes modifizierte Ding ein eigenes SSDT, weil da weisst du dann auch was funktioniert/geladen wurde und wo es fehler gab und nicht geladen wurde. Klar, man kann alles in einem DSDT packen, oder gar auch alles in einem einzigen SSDT usw. nur bringt das gar nix ausser eben unerfahrenene oder besser gesagt die leute die das nicht beherschen ins grübeln zu bringen und das Handtuch werfen.
Alles in einem wird dann eben auch entweder geladen oder auch nicht, auch wenn darin 99% korrekt war, bei einem Fehler wird die Table nicht geladen.

Checken kannst du immer mit diesem Command was der zustand deiner ACPI Table`s auswirft.

sudo dmesg | grep "ACPI" > $HOME/Desktop/acpi.txt

Ergo, weg mit DSDT, benutze das Original DSDT vom Bios selber, patche einfach nur das was für MacOS nicht passt per SSDT einzeln, löse ein problem nach dem anderen, baue immer ein SSDT mit OSI weiche die dann auch NUR für Darwin gilt und das rest IMMER das original benutzt.
Nur so wirst du auch pö a pö zum ziel kommen, ansonsten sieht man ja das manche leute an einem Gerät jahrelang basteln aber nie zum ziel kommen

Hier ist auch ein SEHR guter anlaufpunkt für SSDT`s und einzelne probleme, die euch erlauben zu verstehen wie es zu lösen gilt.

Gruss Coban

Das mit dem HDEF in der DSDT.aml hatte ich ja entdeckt cobanramo, ebenso die Einträge zu _OSI. Es war ja auch nicht mein Ziel, zusätzlich zu der DSDT das AudioDevice mit SSDT zu füttern, sonder vielmehr dies anstelle derer, damit die SSDT-XOSI werkeln kann. Ob noch andere Dinge aus der DSDT gespeist werden muss ich noch rausfinden. Werde mal den Terminalbefehl nutzen, und die Differenzen zu sehen. Das ist echt cool. Danke!

Erstmal Danke für die Hinweise und den weiterführenden Link zu @5T33Z0. Das hatte ich früher schon mal gesehen und leider wieder aus den Augen verloren. Aber genau was ich suchte!

Zitat von nobby

cobanramo

Vielen Dank !

damit hat es geklappt

Habe die SSDT´s aus dem Oc-Paket genommen , da ich zu blöde bin bei githup mir das SSDTTime zu holen , habe dort keine release gefunden .

LG nobby

Alles anzeigen

gibt auch kein Release davon, Du musst den MasterCode als ZIP downloaden. Dort sind dann die .bat's oder .command's für Windows oder macOS. Es sind reine Terminal Anwendungen in Verbindung mit der ungepatchten original DSDT.

Dieses zeigt Dir die nötigen Patches für macOS.

Gepatchte DSDT ist auch nicht mehr der beste Weg unter OC, ferner dann doch besser mit einzelnen SSDT's.

Ohne Deine gepatchte DSDT jetzt zu sehen, behaupte ich mal, dass darin auch die IRQ-Patches gesetzt sind, welche für Audio auf Laptop unabdingbar sind. Wenn Du jetzt auf reine SSDT's umstellst und die gepatchte DSDT deaktivierst, dann fehlen Dir die IRQ-Patches für's Audio.

Du hast aber selbst gesehen, dass der Umstieg auf SSDT's, ohne DSDT, für Windows ein Vorteil ist, somit brauchst Du nur noch die IRQ-Patches wieder einbinden und Du hast vermutlich wieder Audio. Hierfür wichtig sind die Devices RTC und TIMR.

SSDTTime in Verbindung mit der real ungepatchten DSDT zeigt Dir die nötigen Patches an, welche man unter OC/DSDT/Patches einbinden kann.

Die Patches kann man auch in einer SSDT einbinden, wenn man etwas Ahnung davon hat, wie hier im Beispiel von meinem T450s, alles sauber mit OSI-Methode:

SSDT-HPET_RTC_TIMR-Fix.aml

Vielleicht nutzt Du aber auch einfach mal die Internetsuche "Lenovo X230 EFI GitHub", evtl. gibt's dort schon fertige EFI's zum Vergleich, wo evtl. die eine oder andere Sache bereits eingebunden ist.

Diese fertigen EFI's mit komplett gepatchter DSDT kommen häufig vom Tomaten-Forum oder vergleichbar, aber hier ist ist die OSI-Methode oft raus und es macht oft mehr Probleme, als es wirklich Nutzen bringt.

Was soll ich sagen, die Lösung war am Ende leichter als gedacht. Erstmal mit SSDTTime ein FixupHPET gemacht und die SSDT und die Patches eingebaut. Das allein und/oder die Änderung der Layout-ID von 1 auf 29 hat es dann gebracht. Diese Layaout-ID hatte ich noch hauskommentiert im DP liegen und sie passt.Die DSDT.aml wird nicht mehr benötigt, Audio funktioniert ohne diese.

Außerdem klappt es mit der der SSDTTime generierten SSDT-XOSI.aml und Windows 11 2H22 im Dualboot.

Leider funktioniert die Abfrage der ACPI im Terminal nicht, die ACPI.txt bleibt leer, ohne Fehlerausgabe.

Vielen Dank an alle die geholfen haben.

MacPeet Ich hatte 2020 für mein T520 auch eine Konfiguration mit DSDT besorgt.

Diese stammte nicht aus dem Tomaten-Forum, sondern von einem sehr engagierten Nutzer von insanelymac.

Dieser Nutzer hat auch Repositories auf GitHub. Sein Name lautet "tluck".

Ich habe letztes Jahr auch wie verrückt gebastelt. Bin aber am PNLF gescheitert.

Habe das mit den blauen Funktionstasten nicht geschafft.

"kommen häufig" hatte ich geschrieben, war keine strickte Behauptung, noch ein Angriff.

Arkturus

Deine ACPI-Abfrage hat aber nix mit SSDTTime zu tun oder?

Naja, die nötigen Patches hast Du ja jetzt in Deiner Tabelle, welche SSDTTime ja sicher auch angezeigt hatte.

Schön, wenn's nun klappt.

Die Frage zu SSDTTime kann ich nicht beantworten, ob damit die Abfrage mittels dmesg unterdrückt wird.

Vielleicht stimmt die Syntax nicht, denn am KBL-Desktop ist die acpi.txt auch leer.

MacPeet Um Himmelswillen, ich hatte das gar nicht als Angriff gewertet. Alles gut!!!

Zitat von Arkturus

Vielleicht stimmt die Syntax nicht, denn am KBL-Desktop ist die acpi.txt auch leer.

Das Command funktioniert schon, hast vermutlich nur nichts zu anzeigen da dein Rechner schon ne weile läuft und die dmesg keine "ACPI" einträge mehr im Log buffer findet. Du solltest den Command unmittelbar nach einem Boot ausführen oder noch viel besser den "DebugEnhancer.kext" einbinden.

Da hast du dann auch genügend informationen in deinem Log.

Wenn du erweiterte informationen zu einer bstimmten Thema im log suchst solltest du auch den Debug version von diesem Kext drin haben.

Bspl.

Whatevergreen --> Debug Version

bootarg = -wegdbg

sudo dmesg | grep "whatever" > $HOME/Desktop/whatevergreen.txt

Da siehst du mal was alles so Weg macht...

sudo dmesg | grep "ACPI" > $HOME/Desktop/acpi.txt

So kannst du dann auch geziehl nach informationen herausfiltern und auf den Desktop legen, Alles ">" muss natürlich nicht sein wenn du die info nur im Terminal sehen willst.

Gruss Coban


PS: Hackintool macht ja auch nichts anderes, dort kannst du auch dein Log checken...

Da ist man mal ein paar Tage beschäftigt und nicht hier und schon wird man gerufen

bluebyte EFI für welches Gerät und welches OS ist gefragt? (Mein T430 werkelt aktuell relativ passabel mit Sonoma)...

Da wurdest du von bluebyte angepingt, aber es ging darum mein T430 von der DSDT.aml zu befreien, was hier auch gemeinsam gelungen ist griven

_OSI und HPET sind in SSDT umgezogen, wegen Dualboot mit W11 und Patches zur ALC269. Alles gut.

Ah okay dann lass ich das T430 in der Schublade

griven dein T430 kannst du in der Schublade lassen. Ich habe deine EFI schon an Arkturus geschickt.

Die lag noch ruhig und friedlich auf meinem NAS.

Immer gut wenn man sowas archiviert hat

Wie gesagt inzwischen ist sie Sonoma tauglich geworden wenngleich das T430, im speziellen meines wegen dem Display, mit Sonoma eine kleine Update Zicke ist (braucht eine eigene EFI für Updates in der das -igfxvesa Arg gesetzt ist und der restrictevents.kext deaktiviert ist). Ansonsten auch mit Sonoma rennt das Teil noch immer recht gut.

Gut zu wissen, aber restrictevent muss ich fürs Update nicht deaktivieren. Lediglich -igfxvesa für Grafik Patch.

Werde nächste Woche die EFI einstellen. Vorher wird’s nichts mehr.

EDIT: erledigt, steht online

Migrationsassistent und OCLP: ständiger Abbruch

Für alle die ein ähnliches Problem haben: Habe sehr viel probiert, da ich meine Daten mit dem macOS Migrationsassistenten einfach nicht übertragen bekam. Lösung nach langer Zeit war dann letztendlich sehr einfach: die Systeme (Quelle und Ziel) dürfen nicht gepatched sein (siehe auch Clonen unter CCC). Root Patches mit OCLP wieder rückgängig gemacht und schon geht es. Hoffe das hilft.
Gruß