Alternative für EMUVariableUefi-64.efi ?

locojens So --- ich hab es jetzt so gemacht wie du es in Post #10 beschrieben hast und es funktioniert! NVRAM gelöscht, und anschließend im Clover Boot noch einmal mit F11.

locojens Kannst du deinen Clover Ordner einmal hochladen? Bei mir klappt es leider nicht. Habe aber in der letzten Zeit viel an der Konfiguration bei mir geändert.

Aus Neugierde habe ich das eben auch mal probiert und ich verwende die AptioMemoryFix-64.efi mit einem Gigabyte Aorus Master / Bios F8

1. EmuVariableUefi64.efi gelöscht (natürlich mit Backup)

2. Reboot

3. Clover F11

4. Boot OS X

5. Herunterfahren: funktioniert, PC schaltet sich aus

6. Clover merkt sich zuletzt gewähltes OS

locojens

Aptio. Nicht Apito.

Aptio ist eine, auf den UEFI-Spezifikationen basierte, BIOS Firmware von American Megatrends Inc. (AMI).

Was hier wieder kreuz- und quergeworfen wird...

1) Kein UEFI-Board hat einen "nicht funktionierenden NVRAM" und, wenn man das andauernd verallgemeindernd so beschreibt, "damit man es versteht", kommen genau solche Missverständnisse zu stande.

2) Das "NVRAM-Problem" tritt erst mit dem Boot von macOS auf. Damals, weil ein Buffer, dessen physische Adresse zwischengespeichert wurde, physisch verschoben wurde und zwei Teile des NVRAM-Modules (ein mal virtueller, ein Mal physischer Zugriff) auf unterschiedliche statt gleiche Speicherregionen zugegriffen haben, das zweite war circa analog. Somit ist "Clover merkt sich irgendwas" irrelevant für die eigentliche Problematik

3) Die Probleme mit dem Herunterfahren und dem Neustarten sind nur Symptome eines tieferliegenden Problems mit dem NVRAM-Zugriffs und deren Behebung impliziert nichts über den Status des Problems

Und damit kommen wir mal wieder zum Ursprung des Threads...

Hier werden Herangehensweisen vorgeschlagen und keine Doktor-Arbeiten ausgeliefert.

Wenn es im Forum Leute geben sollte, die diverse Situationen genauer kennen und dabei ggf. auf irreführende Infos stoßen, sind diese Mitglieder gerne dazu eingeladen Ihr Wissen in entsprechenden, verständlichen Texten hier zu lassen.

locojens

Nicht gleich so heftig reagieren.

Leider ist so etwas überhaupt nicht jedem klar. Wozu NVRAM überhaupt emuliert werden muss, wenn es doch vorhanden ist, warum gibt es schreibgeschützte Bereiche, warum gibt es manche BIOS-Versionen (direkt vom Hersteller), die zumindest einen entscheidenden (De)Lock erlauben (MSR 0xE2), wie kann man das eigene BIOS patchen, wenn der Hersteller diese nicht zulässt, warum gibt es überhaupt eine "Aptio"-Problematik, warum müssen Speicherbereiche verschoben werden, welche verschiedenste Ansätze dazu gibt es, und welche Konsequenzen haben diese dann wiederum auf andere Funktionen.

Spannend ist auf jeden Fall die Entwicklung von "OsxAptioFixDrv.efi", die "abgemilderte" Variante "OsxLowMemFixDrv.efi". Die weitere Variante dann "OsxAptioFix2Drv.efi" und im Gespann mit "EmuVariableUefi", nebst weiteren Skripten. Dann Neuentwicklung von "AptioMemoryFix" und "Gegenentwicklung" von OsxAptioFix3Drv.efi". Dann auch "aufbohren" eines vorhandenen Treibers in Form von "OsxAptioFix2Drv-free2000.efi". X99-User erinnern sich über Probleme der fragmentierten Speicherzuweisung von PCIe-Geräten.

Ich schätze mhaeuser Beiträge sehr, er hat ein unglaubliches Fachwissen. Würde gern viel öfter und mehr von ihm lesen.

apfelnico Danke! Bekomme relativ häufig Nachrichten auf verschiedenen Plattformen, die mir zeigen, dass sowas eben nicht klar ist und ich muss es dann immer auf's Neue erklären. "So, dass man es versteht" schön und gut, aber früher oder später reicht das eben nicht mehr.

Vor ein paar Jahren wurde mir relativ oft versucht zu erklären, dass auf diversen Boards der NVRAM wortwörtlich garnicht funktioniert oder gar was Apple-eigenes ist... bis AptioFix2 kam

Also nach 4h Versuchen kann ich berichten, dass es mit meiner Konfiguration nicht geklappt hat. Bin wieder bei emusowieso gelandet. Kann es sein, dass es mit den Einstellungen der config.plist zusammenhängt?