Wer verwendet eine SSDT-EC.aml?

Hab mal gelesen, dass die bei Fehlern in Verbindung mit NVMe-Platten (u. U. Samsung) hilfreich sein soll.

Bei mir war sie das aber nicht. Mehr weiß ich dazu leider nicht.

"EC" steht wohl für Embedded Controller

Macht schon Sinn, das Ganze. Ich verwende diese auch, wenn man es mal verstanden hat.

Windows 10 - Mac OS im Dualbetrieb / CLOVER vs. OC Configs

warum diese gebraucht wird.

https://dortania.github.io/Get…CPI/Universal/ec-fix.html

text text text

Da steht doch alles was man wissen muss... Bis auf diesen Teil:

Zitat

Skylake and newer devices will want USBX as well

, der da heißen müsste:

Zitat von Wiki

Für SMBios größer gleich ≥ iMac17,1 und ≥ MacBookPro14,3 (also einschließlich iMac17,1 und MacBookPro14,3) ist dies: SSDT_EC-USBX.aml

Welche Unklarheiten gibt es denn noch? Mit NVMe-Platten, Speedstep oder Timer hat SSDT-EC nichts zu tun.

Da du laut deinem Profil einen Kabylake nutzt, kommt für dich die SSDT-EC-USBX.aml in frage.

https://dortania.github.io/Ope…plist/kaby-lake.html#acpi

HAI Jein. Die meisten Embedded Controller in Hackintoshs sind inkompatibel zu Apples EC-Implementation, man versucht garnicht erst echte Kompatibilität herzustellen und Apples Embedded Controller Treiber werden auf Hackys auch nicht benötigt. Unter Desktops ignoriert man den Embedded Controller einfach und injected per SSDT-EC ein Fake-Gerät, dass einfach nur sagt "Ich bin ein Apple kompatibler Embedded Controller", aber nichts tut wenn man es anspricht. Warum das Ganze? Weil bestimmte Gerätetreiber-Funktionalitäten außerhalb des EC von Apple nur aktiviert werden, wenn ein kompatibler Embedded Controller existiert. Das war früher vorallem der USB Strombedarf. Doch wenn man SMBios ≥ iMac17,1, ≥ MacBookPro14,3, ≥ iMacPro oder ≥ MacPro7,1 verwendet, hat selbst bei vorhandenem Fake-Apple-EC der gewollte Treiber nicht geladen, da diese Apple Geräte zusätzlich noch ein USBX Gerät besitzen. Deswegen injectet man hier zusätzlich noch ein Fake-USBX-Gerät (Non Apple Geräte besitzen diese Hardware nicht). Wie sich die Treibersituation in letzter Zeit entwickelt hat, konnte ich leider nicht wirklich mitverfolgen. Ich hab irgendwo mal gelesen, dass irgendwann angeblich macOS Boot nur möglich war, wenn ein EC vorhanden war, aber auch gelesen, dass die entsprechenden USB-Power Treiber inzwischen garnicht mehr von EC abhängen... Was da dran ist weiß ich nicht, in jedem Fall tut man nicht schlecht daran entsprechende Apple-kompatible Fake-Devices per ACPI zu injecten.

Richtig gut erklärt!