Funktionierender NVRAM nun mit Clover

  • Hallo zusammen,


    im Anhang sind zwei neue OsxAptioFixDriver und OsxAptioFixDriverv2, mit denen es nun möglich ist, bei Geräten die ein nicht richtigen funktionierenden NVRAM haben, diesen zu aktivieren. Ich habe bei mir den OsxAptioFix2Drv-64.efi und die EmuVariableUefi-64.efi gelöscht im Clover unter drivers64UEFI und dort nur die Datei OsxAptioFix2Drv-WTH.efi aus dem ZIP Archiv nach drivers64UEFI kopiert. Die NVRAM.plist die direkt in der EFI liegt, habe ich auch gelöscht. Ich habe dann zum Test die Bildschirmhelligkeit des Laptop Displays verändert und neu gestartet, und diese war nach dem Neu start immer noch gespeichert. Dies soll aber erst ab Skylake funktionieren.


    Erstellt wurde das ganze von vit9696 und Download-Fritz.


    Ihr könnt das bei euch ja mal testen, ob es dort auch funktioniert.


    Gruß


    hitman20

    Dateien

    System 1: Laptop Modell: Dell XPS 15 9550, Mainboard: Intel HM170, Grafikkarte: Intel HD 530, Soundkarte: Realtek ALC298, OS X Version: Big Sur 11.6.1, OpenCore Version: 0.6.3

  • Funktioniert :thumbsup: eben getestet. Ein großes :danke2: an vit9696 und @Download-Fritz.

    MfG, docplag



  • Der Fix ist übrigens auch in der aktuellen Version Clover_v2.4k_r4369 enthalten. Funktioniert bei mir, besten Dank an @vit9696, @Download-Fritz, @MacGrummel und @hitman20.

  • Ich entwickle nicht, ich teste und schreibe nur..
    Vielen Dank an die Entwickler, wieder ein gutes Stück Arbeit!
    :zustimm:


    :hackintosh:

  • Cool Funktioniert tatsächlich. :D


    Test mit Variable schreiben:

    Code
    1. sudo nvram MyVar=TestValue


    Ist nach Neustart wieder Verfügbarer mit

    Code
    1. nvram -p
  • Ich habe die aktuelle Clover-Version mal auf meinem Lenovo E460 getestet und endlich überlebt die Einstellung für die Bildschirmhelligkeit wieder einen Neustart. Sehr schön!

  • Das heisst der EmuVariableUefi-64 und die RC-Scripte sind damit hinfällig?
    Cool!!!!

    Gruß
    Al6042

    Keine Unterstützung per PN oder Pinnwand... Eure Anfragen gehören ins Forum, nicht in mein Postfach!

  • RC-Scripte, guter Hinweis. Werden die gelöscht, wenn man das im Clover-Installer abwählt?

  • Kann ich nicht sagen, ich habe die Änderungen eben manuell durchgezogen, da ich Clover bereits heute Mittag aktualisiert habe.
    Die Scripte liegen unter /etc/rc.boot.d und /etc/rc.shutdown.d...
    Einfach beide Ordner entfernen und die Datei nvram.plist auf der versteckten EFI-Partition, zusammen mit der /EFI/CLOVER/drivers64UEFI/EmuVariableUefi-64.efi löschen.


    Kann für beide Systeme eine positive Rückmeldung geben... funzt...


    Tolle Arbeit der Entwickler... :thumbsup:

    Gruß
    Al6042

    Keine Unterstützung per PN oder Pinnwand... Eure Anfragen gehören ins Forum, nicht in mein Postfach!

  • Nein, werden nicht gelöscht. Liegen auf der Mac-Platte in /etc/rc.boot.d/ und /etc/rc.shutdown.d/


    EDIT: der @al6042 war schneller. :)

    MfG, docplag



  • Bei mir auch. Funktioniert auch auf beiden Systemen. :danke2:

  • Top! Funktioniert auch auf meine Lenovo E560!

    HP Elite X2 G2, 12'', Intel Core i5-7300U, 16 GB RAM, Intel HD Graphics 620, 4 TB SSD, macOS Ventura

    ---

    HP Compaq 8300 Elite, Intel Core i5-3470, 4 x 3,20 GHz, 8 GB RAM, Ivy Bridge, Nvidia Geforce GT 710 (Intel HD Graphics 2500), macOS Big Sur

  • Der Fix killt bei mir den Zugriff auf die EFI Runtime Services.
    Zugriff erfolgt über AppleEFIRuntime und funktioniert mit den alten OsxAptio einwandfrei.
    Die neuen crashen mit schwarzem Schirm und Neustart.
    Kennt jemand eine Abhilfe, außer die alten zu weiter verwenden :) ?

  • Oh weh...
    habe ich bisher nicht erfahren müssen...
    Läuft bei mir...

    Gruß
    Al6042

    Keine Unterstützung per PN oder Pinnwand... Eure Anfragen gehören ins Forum, nicht in mein Postfach!

  • Der einzige Fix bei mir ist der Holzhammer-OsxAptioFix2Drv-free2000.efi. Und so hab ich dann doch nichts gewonnen..


    :hackintosh:

  • Der Fix killt bei mir den Zugriff auf die EFI Runtime Services.
    Zugriff erfolgt über AppleEFIRuntime und funktioniert mit den alten OsxAptio einwandfrei.
    Die neuen crashen mit schwarzem Schirm und Neustart.
    Kennt jemand eine Abhilfe, außer die alten zu weiter verwenden :) ?


    Woher weißt das, wird doch irgendetwas angezeigt? Wenn ja, Bild/Dump/whatever bitte.

  • Ich habe eine App, die EFI Runtime Service Routinen aufruft.


    Dazu spricht sie mit dem User Client eines Treibers, dessen Provider AppleEFIRuntime ist und über AppleEFIRuntime erfolgt der Aufruf der EFI Runtime Service Routinen.


    Das funktioniert auch wunderbar, solange das System mit einem "alten" OSAptioFixDrv gebootet wird.


    Wird hingegen der neue OSAptioFixDrv verwendet, wird der Bildschirm schwarz und es wird neu gebootet.


    AppleEFIRuntime führt den Aufruf aus der EFI Runtime Service Tabelle nicht selbst aus, sondern verwendet dazu _pal_efi_call_in_64bit_mode. Das stammt steht wohl aus com.apple.kpi.private.


    Ob AppleEFINVRam den Provider für die Zugriffe aufs NVRam benutzt, erschließt sich mir nicht auf den ersten Blick. Ich bin mir nicht sicher ob überhaupt irgendeine Software AppleEFIRuntime zur Laufzeit aufruft.

  • Ja, NVRAM nutzt AppleEFIRuntime. Welche funktion ruft die App auf?


    EDIT: Nach 'nem normalen Boot oder nach S4-Wake?


    EDIT2: Ich gehe einfach mal davon aus, dass es eine Variable-Funktion ist, die wir nicht überschreiben... also, das Problem ist, dass ein Teil des AMI-Flash-Treibers vom NVRAM-SMM-Treiber beschrieben wird. Mit dem alten AptioFix wurde diese Speicheradresse physisch verschoben und natürlich auch woanders gemappt, weswegen der NVRAM-Treiber dann fröhlich ins Nirvana schreibt, was zufälligerweise in einem R/W-Speicherteil erfolgt. Mit dem neuen AptioFix wird das physische Verschieben verhindert und der SMM-Treiber schreibt in einen eigentlich R/O-Bereich, was zu einem GPF-KP führt. Deshalb wurden die drei Variable-Funktionen, GetVariable, SetVariable und GetNextVariableName überschrieben, um beim Aufruf das WP-Bit aus dem CR0 rauszuhauen, was den KP verhindert. Wenn du eine andere, nicht überschriebene Funktion aufrufst, führt das erwartungsgemäß zu einem KP.
    Die Entscheidung, nur diese drei zu überschreiben, war strategisch, da macOS nur diese drei Var-Funktionen nutzt. Das WP-Bit ist leider Core- und nicht Thread-bezogen, deshalb kann ohne einen Spinlock, wie AppleEFIRuntime ihn setzt, der zweite Thread im Kern auf XNU-Ebene in R/O-Speicher schreiben. Wenn eine Kext also einen Bug oder was auch immer hat, dass sie out-of-bound schreibt und zufällig der andere Thread gerade einen RT-Dienst mit dem WP-Code ohne Spinlock (also an AppleEFIRuntime vorbei) aufruft, wird das WP-Bit rausgekickt und die Kext schreibt erfolgreich ins Nirvana.
    Deswegen: Seit wann gibt es dieses User-Client-Interface für AppleEFIRuntime? Mir wurde gesagt, dass es sowas nicht gibt... mit der Nutzung von diesem gibt es keinen Grund, einen RT-Dienst direkt aufzurufen und das obige Problem ist gelöst.

    Einmal editiert, zuletzt von mhaeuser ()

  • Ich hab beim Start an meinem X99er diese beiden Standart-Meldungen, zuerst konnte ich normal starten, dann hab ich zum testen die EFI gewechselt, danach dann das hier:


    Zwischendurch gab's noch andere Meldungen, dafür war die Kamera aber nicht schnell genug zur Hand. Versuch ich gleich noch einmal!


    :hackintosh: