Wieso bekomme ich noch diesen Hinweis, wenn ich OC schon einige Zeit nicht mehr nutze, sondern Clover 5128?
OC-anwendungsabhängig oder von einem Tool stammend?
OpenCore Sammelthread (Hilfe und Diskussion)
- derHackfan
- Unerledigt
-
-
Von welchem Programm bekommst du denn die Meldung?
Könnte was damit zu tun haben, das OC im neuen Clover mit unter der Haube steckt.
-
Könnte was damit zu tun haben,
Daran habe ich auch gedacht. Ich habe nach der letzten Nutzung von OC Selbiges für einen OC-NVRAM genutzt - OC-Reste sollten es m. E. nicht mehr sein.
Langsam habe ich aber ein anderes Tool im Verdacht: OC Configurator. Ich meine mich nämlich zu erinnern, dass das auch kam, wenn ich mit dem OCC die EFI-Partition gemountet hatte, OC aber noch nicht auf die aktuelle Version umgestellt war.
Nur nutze ich das Tool jetzt nicht (mehr), sondern den CC zum Mounten & Bearbeiten.
Wenn das zutrifft, könnte ich per OC-/CLover-NVRAM durchwischen, bis der Arzt kommt - es würde nichts bringen, da es vom Programm initiiert wird.
-
Das ist eine Meldung vom OC Configurator, wenn man eine Opencore-Config damit öffnet, obwohl man nicht mit Opencore gebootet hat.
-
eine Meldung vom OC Configurator, wenn man eine Opencore-Config damit öffnet,
Das vermutete ich inzwischen ja auch, nur benötige/benutze ich den OCC ja nicht, wenn ich nicht damit gebootet habe. Die letzten Tage habe ich das bestimmt nicht gemacht und der Hinweis kommt ja auch direkt nach dem Login - also noch bevor ich irgendwas veranstalten konnte.
-
Wird eine Opencore-Config durch den Autostart mit OCC (oder Überresten) geöffnet?
-
Autostart mit OCC
Was genau meinst Du damit? Wo/wie findet ein Autostart statt?
Bislang habe ich den OCC ohne Bezug zu einer config.plist normal (leer) aufgerufen, um ihn zum Mounten zu nutzen oder ich habe gezielt eine config.plist damit aufgerufen (Öffnen mit ..).
-
Diese kleine Häkchen bei Neustart/Herunterfahren "Fenster wieder öffnen" oder so (bin grad nur auf Windows unterwegs)).
-
"Fenster wieder öffnen"
Ach - das meinst Du.
Das war noch bei Nutzung von OC selten der Fall, dass der OCC noch geöffnet war. Soweit ich es mitbekommen habe, mault macOS diesbezüglich auch.
Aber das bezieht sich ja immer auf die letztgeöffneten Fenster und wenn beim nächsten Mal OCC nicht geöffnet war, dürfte es auch beim erneuten Login nicht geöffnet werden. Richtig?
-
Auch hier nochmal allgemein gefragt; gibt es für OpenCore einen patch oder ein Tool, was die GPU vor dem Abschalten des Betriebssystems deaktiviert?
zB. GPU wird ausgeworfen wenn man MacOS herunterfährt, damit Sie in Windows nicht aufpoppt?!
-
Was hat das mit OC zu tun?
-
Das versuche ich herauszufinden, schließlich erkennt Windows Sie erst als Neue nachdem ich wieder in MacOS war.
Da ich es unter Win nicht hinbekomme Sie zu deaktiveren nach macOS boot, kann man vll. direkt unter MacOS schon angreifen!?
-
Das geht mit einer SSDT und per "_OSI"-Abfrage. Windows sollte dann ebenfalls über OpenCore gestartet werden, damit auch hier die SSDT greift.
-
Danke - hast du noch eine Info welche SSDT ich da genau brauche, ggfs einen Dortania Link?
In Dortania sehe ich nur die üblichen GPU Links, aber nichts mit dem besagten Problem.
Osi Abfrage kenn ich mich gar nicht mit aus.Windows wird sowieso immer über den Picker gestartet und dennoch besteht das Problem.
-
-
-
Nein, keine fertige SSDT. Sondern eine dazu schreiben. Ist doch ganz einfach. Die „Device Properties“ kennst du. Nur packst du die nicht in die Sektion in der config.plist des Bootloaders, sondern eben in eine SSDT. Vorteil davon ist, du definierst es für beide Grafikkarten und packst jeweils drum rum eine if/else-Schleife mit _OSI. Also Abfrage zum System und bedingte Ausführung.
Also quasi: wenn „Darwin“ (macOS), dann diesen Slot deaktivieren und jenen aktivieren, ansonsten genau andersherum. Diese SSDT wird in die ACPI vom Bootloader eingefügt und steht somit frühzeitig zur Verfügung und wird auch so das System beeinflussen je nach Betriebssystem. Das kann der Eintrag von „Device Properties“, so wie du es bisher gemacht hast, nicht leisten. -
Danke
nein, wollte auch keine fertige SSDT.
Nur wie ich die ausetze kompiliere.
Was genau und wie da rein muss, dachte dazu gibt es sowas wie eine dortania anleitung. Hab für den Hack auch alles selbst gemacht. Werde morgen mal schauen, wie ich das umsetze was du schriebst. Danke dafür.
-
kexterhack dünnes Eis in dem Sinne, dass alle Einträge und ACPI Patches auch unter Windows aktiv sind. Es sei denn, man umgeht das mit solchen OSI-Schleifen. Kritisch wird es so richtig mit einer gepachten DSDT. apfelnico ist da wirklich fit 💪 Deshalb sollte man nach Möglichkeit DSDT vermeiden.
-
Sorry wenn ich dazwischen grätsche, aber:
in welcher Form gebe ich unter XCODE 12 Werte in einem DATA-Feld ein?
Wenn ich es mit "0x77080000" versuche erhalte ich eine Fehlermeldung. Wenn ich in dem im Screenshot zu sehenden Feld nur das "0x67f00000" versuche auszutauschen, erhalte ich eine Fehlermeldung.
Ich habe es auch bereits mit "{0x77080000}", "[0x77080000]" versucht - alles bislang ohne erfolg.
Früher reichte es, wenn ich dort einfach nur "0x00000000" eingegeben habe und der Wert wurde korrekt übernommen.
EDIT: hat sich erledigt. muss mit <> eingegeben werden
