OpenCore Sammelthread (Hilfe und Diskussion)

Die wenigsten benutzen _OSI Patches, bzw korrekter gesagt, die wenigsten brauchen es. Was Dual Boot mit Windows angeht sollte die SSDT nicht weiter stören, die setzt _OSI ja auf Windows. Hast du mal nach Alternativen Lösungen für ein Touchpad gesucht?

Moin,

ja, so gibt _OSI immer eine nestimmte Windows-Version zurück. In den ACPI-Samples von OC sehe ich da einige Abfragen, die z.B. ein EC-Device nur aktivieren, wenn _OSI = Darwin ist. Das kommt sich dann doch so in die Quere, oder nicht?

Was meinst du mit „Alternative“?

Hallo Harper Lewis ,

ich mach es genauso wie es im Manual von OpenCore abgeraten wird. Funktioniert super.

Moin,

das hatte ich tatsächlich in deinem Repository für dein ASUS-Laptop gesehen. Daher auch meine Frage

Wenn ich keinen Knoten im Kopf habe, gibt _OSI dann aber immer Windows zurück und um beim Beispiel SSDT-EC zu bleiben: Das dürfte dann ja nicht mehr wie gewollt funktionieren:

Was meinst du mit "nicht mehr wie gewollt funktionieren"?

Wenn _OSI immer Windows zurückgibt, gibt _STA für das Gerät EC in obigem Beispiel immer Zero zurück. Der „fake“ EC wird so unter macOS niemals auftauchen, oder sehe ich das falsch? Das wäre ja genau nicht gewollt.

Ich muss das mal auf dem Laptop prüfen. Ist mir noch nicht aufgefallen das dem so sein könnte.

Ich habe mal nachgesehen, du fragst das OS nicht ab:

Somit dürfte EC unter OpenCore sowohl unter macOS, also auch unter Windows auftauchen

Zitat von anonymous writer

ich mach es genauso wie es im Manual von OpenCore abgeraten wird. Funktioniert super.

Ich hab auch den ACPI Patch EC0->EC drin, weil die SSDT-EC nix brachte. Nur mit der SSDT-EC hatte ich in ioreg kein EC Device. Mit dem Patch ist es da.

karacho : Dann benutzt du auch einen _OSI-Hotpatch? EC0 (oder Embedded Controller mit anderem Gerätenamen) sollte man nicht mehr umbenennen, insbesondere nicht bei Desktops. Davon wird an mehreren Stellen abgeraten (u.a. in den ACPI-Samples). Nimm doch mal die _OSI-Abfrage raus, dann sollte es in jedem Fall mit der SSDT-EC klappen.

karacho Genau das ist doch der Punkt, der macOS-EC-Treiber ist mit fremden ECs nicht kompatibel und soll deswegen nicht geladen werden. Musst nur überprüfen, ob der AppleBusPowerController geladen wird, der geht nach ACPI, nicht IOReg

Richtig sieht es dann so aus, wenn unter IOService ein EC-Device + ApplePowerBusController zu sehen ist, AppleACPIEC darf dort nicht ebenfalls geladen werden. Korrrekt? Also kein ACPI-Rename, sondern immer die SSDT-EC benutzen. Gibt es auch Rechner, bei denen der Embedded Controller tatsächlich den Gerätenamen EC hat? Bisher sind mir nur EC0, ECDV, H_EC usw. untergekommen.

Nachtrag: Unter Mojave matcht AppleACPIEC (IONameMatch) PNP0C09 und boot-ec (echter Mac). Catalina habe ich gerade nicht am Start, da dürfte das ja anders sein.

Harper Lewis Du hast keinen Dreher drinn, _OSI Darwin bedingtes Laden von ACPI Tabellen in macOS würde nicht mehr funktionieren, es wird ja Windows zurückgegeben. Im Optimalfall sind ACPI Tables so designed, dass sie sowohl unter Win als auch unter macOS funktionieren. Wenn das nicht so ist, könntest du einfach per SSDT-XOSI eine andere Windows Version zurückgeben, als das dein installiertes Windows tun würde. Dementsprechend laden deine macOS ACPI Tables bei XOSI gleich Windows 10 o.ä und eben nicht, wenn du Windows 7 bootest. Andere Herangehensweise besteht darin nicht auf den _OSI Hack angewiesen zu sein, ich weiß aber nicht wie crucial der für dein Trackpad ist.

Was SSDT-EC angeht, beachtet die unterschiedlichen HIDs bei der SSDT-EC vom acidanthera Package und älteren bekannten SSDT-ECs mit _HID EC000000. Auch ist die SSDT-EC bei neueren OSs für die Strom-Problematik iirc nicht mehr nötig, ändert natürlich nichts an der ansonstigen Signifikanz von deaktivieren inkompatiblen H_EC und ggf. Ersatz durch SSDT-EC.

Danke. Ich muss mir das nochmal genauer anschauen.

Das Laptop hat in den ACPI-Tables zwei EC-Devices:

H_EC mit _HID PNP0C09, _STA gibt Zero zurück (inaktiv)

ECDV mit _HID PNP0C09, _STA gibt 0x0F zurück (aktiv)

Momentan habe ich, weil ich es „damals" nicht besser wusste, ECDV in EC__ umbenannt. Das werde ich ändern…

Leider taucht das Touchpad-Device (EPD0) ohne den Windows-Patch gar nicht erst auf.

Ab Catalina braucht ihr das EC Device sowieso nicht mehr. Der AppleBusPowerController lädt auch ohne.

Wo findet man den denn unter Catalina im IOReg?

In den IOResources. Matcht auf IORTC.

Ah, danke. Es gibt ja unter Catalina in AppleBusPowerController.kext keinen entsprechenden IONameMatch auf EC mehr wie bisher, sehe ich gerade.

Und um mal wieder zu OpenCore zurückzukommen…

Wenn ich wie in diesem Beispiel (Uncomment replacing…) den EC / ECDV meines Laptops deaktivieren möchte, müsste ich doch ebenfalls die bereits in den ACPI-Tables vorhandene Methode _STA des Gerätes per Patch umbenennen, oder verhält sich OpenCore hier anders als Clover?

Sodele, habe den Patch jetzt mal rausgenommen und die SSDT-EC genommen. Jetzt sieht das ganze so aus.

Ohne SSDT-EC bootet die Kiste jedoch nicht mehr. Bleibt hängen bei + Previous shutdown cause 5 + und die Tastaturbeleuchtung geht aus. Nix mehr, nada...hilf nur noch Reset.

Update: Ich habe gelesen, dass AppleACPIEC nicht geladen werden soll. Hab mir dann mal die AcpiSamples im Ordner Docs angesehen. Dann die SSDT-EC-USBX.dsl meinen Bedürfnissen angepasst (/** und **/ nach dem DefinitionBlock gelöscht, kompiliert und als aml gespeichert. Die SSDT-EC.aml die Hackintool erstellt hat, gelöscht und die neue SSDT-EC-USBX.aml in den ACPI Ordner. config.plist angepasst und neu gestartet. Passt. Kein EC0->AppleACPIEC mehr da.

Bei Laptops muss man mit dem Deaktivieren von vorhandenen ECs aufpassen, der Embedded Controller macht hier mitunter wichtige Aufgaben!

Harper Lewis was meinst du mit umbenennen? Wenn du _STA umbenennst wirst du damit nicht mehr den Status verändern können... _STA wird hier einfach auf 0 gesetzt.