OpenCore Sammelthread (Hilfe und Diskussion)
- derHackfan
- Unerledigt
-
-
Hallo,
ich bekomme den Ruhezustand bei mir einfach nicht ans Laufen. Angefangen hab ich mit einem vorkonfigurierten Skylake Clover Image, was hier freundlicherweise im Forum angeboten wurde (damit lief alles auf Anhieb, außer dem Ruhezustand). Dann bin ich auf OpenCore umgestiegen, hab die neuesten Releases von https://github.com/acidanthera/ verwendet und anhand des Guides https://dortania.github.io/OpenCore-Install-Guide/ konfiguriert (selbes Ergebnis: es lief alles, außer dem Ruhezustand). Dann hab ich die Lösungsvorschläge https://dortania.github.io/Ope…tall/universal/sleep.html komplett abgearbeitet, dabei insbesondere UsbInjectAll.kext durch ein eigenes angepasstes USB mapping ersetzt (https://dortania.github.io/OpenCore-Post-Install/usb/), für die iGPU den Parameter igfxonln=1 hinzugefügt, das CPU Power Mapping angepasst (https://dortania.github.io/Ope…Install/universal/pm.html), eine SSDT-HPET.aml gegen mögliche IRQ Konflikte erstellt, eine eigene SSDT-SBUS-MCHC.aml erstellt (https://dortania.github.io/Get…ACPI/Universal/smbus.html), sowie sichergestellt, dass die Voraussetzungen für die beschriebenen möglichen Probleme mit Thunderbolt, NIC, NVMe, Display, NVRAM, RTC, Audio oder TSC nicht vorliegen. Jetzt hab ich zwar eine perfekt angepasste Config und vieles gelernt, aber das Problem mit dem Ruhezustand besteht weiterhin.
Das einzige, was ich während des Anpassungsprozesses auffällig fand, war, dass der Guide https://dortania.github.io/Ope…/pm.html#using-cpu-friend nicht wie erwartet funktionierte: Obwohl ich eine Skylake CPU habe, wurde der zweite der drei Schritte (EPP) im CPUFriendFFriend übersprungen; und wenn ich mit dem generierten CPUFriendDataProvider.kext gebootet und CPUFriendFriend nochmal aufgerufen habe, wurden mir als aktuelle Werte immer noch die alten angezeigt. Ich hab mir den Python Source von CPUFriendFriend daraufhin angeschaut und festgestellt, dass das Tool im ioreg output von IOPlatformPowerProfile -> FrequencyVectors (hex-codierte Binärdaten) nach Teilstrings sucht und teilweise nicht fündig wird. Da ich keine Doku über das Binärformat finden konnte, war mir der Ansatz zu unseriös, und ich bin zu Plan B, das ssdtPRGen Tool zu verwenden (https://dortania.github.io/Ope…y-bridge-power-management) übergegangen, da das Tool (entgegen der Überschrift in der Anleitung) mittlerweile offenbar erweitert wurde und auch Skylake unterstützt; diese Anleitung ließ sich dann auch problemlos anwenden.
Im Laufe der vielen Versuche wachte macOS einmal plötzlich aus dem Ruhezustand wieder auf. Doch zu früh gefreut: mehrfaches wiederholen zeigte, dass es nur ca. jedes 15. Mal klappt. Immerhin eine neue Erkenntnis: es spielt eine race condition / timing / Zufall mit rein.
Schließlich hab ich aus dem Gedanken heraus "vllt geht ja wenigstens suspend-to-disk, wenn suspend-to-ram nicht geht" eine möglicherweise hilfreiche Entdeckung gemacht: wenn ich mittels sudo pmset -a hibernatemode 25 die Art des Ruhezustands umstelle, scheitert das Aufwachen aus suspend-to-ram und suspend-to-disk nacheinander mit exakt derselben kernel panic, wohingegen die kernel panics sich sonst unterscheiden. Ich würde daraus schlussfolgern, dass die zufällige Komponente des Scheiterns / Gelingens vom Zustand vor dem Ruhezustand und nicht vom Aufwachprozess abhängt. Nur bin ich mit meinem Latein leider nun am Ende. Weiß jemand hier Rat?
Ich hänge einige kernel panics an. Man sieht, dass es immer auf eine ähnliche Weise knallt, aber sehr unterschiedliche stack traces dahin führen können.
-
Es ist OCv061, reproduzierbar bootet diese Version das T430 nicht. Wenn ich downgrade auf OCv060 mache, kann ich mit der EFI wieder booten. Das Recovery bootet auch die OCv061, Mojave leider nicht. Hat also nichts mit FileVault zu tun.
EDIT: Ich habe jetzt mal die EFI auf OCv0.6.2 gehoben, einschl. verfügbare nigthly Kexte. Hier der Sanity-Check.
Leider ohne Erfolg. Ohne Meldung zurück zum Picker.
Problem ist hardwareunabhängig auf allen Systemen.
hier mal die aktuelle EFI OCv0.6.2
-
jgehw Man kann es auch übertreiben mit den SSDT's. Den ganzen Kram brauchst du sehr wahrscheinich garnicht. Ich würde zuerst einmal nur mit einer SSDT-EC.aml (oder SSDT-EC-USBX.aml) booten und dann weiter schauen.
-
jgehw
Hast du deine BigSur Installation eventuell auf einer externen Platte welche über USB angebunden ist?
-
jgehw
Hast du deine BigSur Installation eventuell auf einer externen Platte welche über USB angebunden ist?
Nein, ich hab macOS (Catalina übrigens) auf einer internen SSD installiert.
jgehw Man kann es auch übertreiben mit den SSDT's. Den ganzen Kram brauchst du sehr wahrscheinich garnicht. Ich würde zuerst einmal nur mit einer SSDT-EC.aml (oder SSDT-EC-USBX.aml) booten und dann weiter schauen.
Der Kram scheint in der Tat überflüssig zu sein. Hab die SSDTs bis auf EC/USBX rausgenommen und es läuft weiter wie bisher. Leider klappt aber auch der Ruhezustand weiterhin nicht.
-
Schorse Wie bereits von karacho erwähnt, brauchst du für die Vega 64 keinerlei SSDT und auch keinen Eintrag in den DeviceProperties – übrigens weder im iMacPro1,1-SMBIOS noch im iMac19,1-SMBIOS. Wenn du sie aus rein kosmetischen Gründen dennoch eintragen willst, genügt ein Eintrag wie dieser:
Aktuelle Lilu.kext und WhateverGreen.kext und gut ist.
-
Guten Morgen liebe Leute, ich hätte da auch mal eine Frage, die mich seit ein paar Wochen beschäftigt.
Wenn ich mit meinem BigMac einen sogenannten "Kaltstart" mache, dann werden im "Picker" keine Auswahlmöglichkeiten angezeigt.
Wenn ich nach dem "Kaltstart" mit Strg-Alt-Entf einen "Warmstart" mache, dann werden die Einträge angezeigt.
Da ich aus dem Stehgreif weiß, welche Einträge dort stehen müssten, kann ich auch nach dem "Kaltstart" die Systeme im Blindflug starten. Aber das ist nicht Sinn der Sache.
Mac OS -> Neustart -> Einträge im Picker und Meldungen im verbose werden angezeigtMac OS -> Runterfahren -> Rechner starten -> Einträge im Picker und Meldungen im verbose werden nicht angezeigt -> Start im Blindflug möglich
Windows -> Neustart -> Einträge im Picker und Meldungen im verbose werden angezeigt
Windows -> Runterfahren -> Rechner starten -> Einträge im Picker und Meldungen im verbose werden nicht angezeigt -> Start im Blindflug möglich
Es muss etwas mit den Grafikeinstellungen im Picker zu tun haben, oder nicht?
Lade hier mal die config.plist hoch. Vielleicht erkennt jemand von Euch den/die Fehler?
Allen einen schönen Mittwoch und viele liebe Grüße von bluebyte -
Nein. Das wird bei DeviceProperties->Add eingetragen, so wie du es schon drin hast. Die layout-id 21000000 sieht auch gut aus. Lösche mal alcid=33 und -lilubetaall. Mit einer aktuellen Lilu.kext brauchst du -lilubetaall nicht, und die layout-id hast du schon in den DeviceProperties. Wenn mit layout-id 21000000 kein Audio, dann mal mit der 7F000000 (127) oder der 1C000000 (28) probieren.
ich habe jetzt mit viel Geduld alle Varianten durchgespielt. Mit oder ohne alcid =33(28;127) und den dem entsprechenden Layout-id in Deviceproperties. Ich kriege Audio auf dem T430 nicht zum laufen.
Was mir noch aufgefallen ist, im Bootpicker ist funktioniert NVRAM reset scheinbar nicht. Im Clover Menü funktioniert das mit F11. Erkennbar weil danach der Defaultstartpunkt Im OC Bootpicker zurückgesetzt wird. Wenn ich Im Bootpicker die Option NVRAM reset ausführe bleibt der Startpunkt bestehen.
-
Arkturus Gib mal im Terminal ein:
sudo nvram TestVar=Test123
Dann die Eingabe bestätigen und Computerpasswort eintippen. Anschließend Neustart und im Bootpicker den NVRAM-Reset ausführen.
Wenn danach (nach einem weiteren Neustart) bei Eingabe von
nvram -p | grep 'TestVar'
im Terminal als Ausgabe erscheint
TestVar Test123
dann funktioniert der NVRAM-Reset wirklich nicht. Ansonsten, wenn nicht diese Ausgabe kommt und die NVRAM-Variable durch den Reset also korrekt gelöscht wurde, kannst du davon ausgehen, dass der NVRAM-Reset funktioniert.
Ich bilde mir ein, mal was gelesen zu haben, dass es ggf. einen Unterschied macht, ob man den NVRAM-Reset schon vor dem Picker mit Cmd-Opt-P-R ausführt oder direkt im Picker über den Menüpunkt, aber kann mich daran nicht mehr erinnern, ob da was dran ist und, falls ja, was dabei der Unterschied ist.
-
@JimSalabim das ist egal was ich in die DeviceProperties eintrage, es bleibt bei mir ohne Berücksichtigung und genau darum geht es.
Benötige ich weiterhin diese Boot-Args in BS11 Beta 6, OC 0.6.1?
keepsyms=1npci=0x2000
-
-
@JimSalabim Danke für die klare Antwort, sind raus..
Genau das wundert mich auch das sie unter Catalina funktionieren. Brauchen tue ich es nicht, da nur kosmetisch, interessant finde ich es dennoch gerade weil ich mich gerne mit OC beschäftige. Mal sehen wo es mit der Beta noch hingeht..
-
Wenn ich mit Opencore 0.6.1 auf dem Usbstick Big Sur starte, wird der VoodooPs2Controller nicht geladen. Tastatur und Trackpad funktionieren nicht. Mit der genau gleichen EFI auf der eingebauten SSD funktioniert alles wunderbar. Die Suche nach einer Lösung beschäftigt mich ich seit dem Frühstückskaffee, Tante Google findet leider nichts passendes. Hat jemand eine Idee, woran das liegen könnte?
-
Bei meinem X230er läuft es auch mit 0.6.2 alles, ich lasse aber alle "Voodoozauber-Treiber" einzeln laden, also auch die in der Kext unter 'Plugins' versteckten.
Natürlich sind die alle einzeln in der config unter Kext -> Add eingetragen.
-
Eingetragen ist imho alles nötige, sonst würde es, mit der SSD-EFI gestartet, auch nicht funktionieren.Warum die gleiche EFI, je nachdem von der Platte oder vom Stick gestartet, den VoodooPS2Controller (und die Plugins natürlich ) lädt oder eben nicht, übersteigt meinen Horizont.
-
Alles anzeigenArkturus Gib mal im Terminal ein:
sudo nvram TestVar=Test123
Dann die Eingabe bestätigen und Computerpasswort eintippen. Anschließend Neustart und im Bootpicker den NVRAM-Reset ausführen.
Wenn danach (nach einem weiteren Neustart) bei Eingabe von
nvram -p | grep 'TestVar'
im Terminal als Ausgabe erscheint
TestVar Test123
dann funktioniert der NVRAM-Reset wirklich nicht. Ansonsten, wenn nicht diese Ausgabe kommt und die NVRAM-Variable durch den Reset also korrekt gelöscht wurde, kannst du davon ausgehen, dass der NVRAM-Reset funktioniert.
Ich bilde mir ein, mal was gelesen zu haben, dass es ggf. einen Unterschied macht, ob man den NVRAM-Reset schon vor dem Picker mit Cmd-Opt-P-R ausführt oder direkt im Picker über den Menüpunkt, aber kann mich daran nicht mehr erinnern, ob da was dran ist und, falls ja, was dabei der Unterschied ist.
NVRAM funktioniert. testvar wird gespeichert. Aber OC Tool NVRAM reset kann nicht löschen. Clover F11 löscht den NVRAM. JimSalabim
-
Was mir in dieser Beziehung aufgefallen ist, manchmal zerschießt man sich die die config.plist einfach nur dadurch, das man unterschiedliche Programme zum editieren benutzt, hatte mal auf dem Großen eine plist vom Lenovo mit XCode bearbeitet um mir ein neues OC zu bauen (war glaub ich 0.5.9) auf dem Lenovo nutzte ich aber den PListeditor. und beim überprüfen war soweit alles OK und auch alles vorhanden. Aber beim Versuch zu booten meckerte OC mich an das der Abschnitt ACPI fehlen würde, welcher aber ganz normal in der plist drin war...
ich habe dann händisch aus der defaults.plist nochmal genau die selbe gebastelt und die lief ohne Probleme.
Ergo: es gibt viele Wege welche nach Rom führen mögen, aber auch einige um eine eigentlich funktionierende config.plist in Datenmüll zu verwandeln.
-
-
Arkturus Hast du in deiner config.plist AllowNvramReset auch aktiviert?
ja, war aktiviert.
Siehst in dem Security evtl. andere Fehler?JimSalabimEDIT: Ich ziehe an dieser Stelle meine Fragen zum T430 in Bezug auf OC zurück. Diese Pferd ist jetzt töter als tot.
Es bleibt bei Clover und dafüt werde ich zu ein nespäteren Zeitpunkt die Übungen wieder aufnehmen.
Aber vielen Dank an alle die Geholfen haben!
