OpenCore Sammelthread (N-D-K Fork)
- karacho
- Erledigt
-
-
-
Ich habe meine über die Anleitung von CPUFriend.kext, bzw. mit dem dortigen ResourceConverter.sh Script erstellt --> https://github.com/acidanthera…ob/master/Instructions.md
-
-
-
Bei Github oder auf Insanelymac
-
JimSalabim Da geht's lang -> https://github.com/n-d-k/OpenCorePkg/issues
Oder dort -> https://www.insanelymac.com/fo…with-additional-features/
-
-
Jo siehtecht cool aus JimSalabim Was mir jedoch gegen den Strich geht ist, dass wieder jeder sein eigenes Süppchen kocht. Wozu noch einen Fork, wo ich als User jedesmal komplett 3 Dateien tauschen und meine config.plist ändern muß, damit ich überhaupt booten kann. Das ist doch Wahnsinn!
-
Beide Forks von N-D-K habe ihre Berechtigung.
Wer auch Windows auf dem Rechner haben möchte mit viele ACPI Renames kommt um den OpenCore Fork gar nicht drum rum. Jedenfall läuft Windows nur auf meine Desktop mit dem Original. Auf dem Zenbook keine Chance.
Und der NDKBootpicker ist nur ein erster Schritt in die vielen Möglichkeiten welche Opencore für Bootmenüs bittet.
-
anonymous_writer Man sollte möglichst wenige bis gar keine ACPI-Renames in der config haben. Das wichtigste wird von Lilu, WEG und AppleALC erledigt und das ist auch sicherer.
-
Dass man die SSDTs im Fork für alles außer macOS deaktivieren kann (zumindest wenn ich das so richtig verstanden habe), halte ich auch für recht praktisch – aber das war’s bei mir mittlerweile auch schon mit für mich relevanten Vorteilen des Forks. Ich hab bei mir die SSDTs, bei denen die Aktivierung unter Windows von Nachteil für mich sein könnte, entsprechend auf "Darwin" beschränkt. Hier zum Beispiel:
Code- DefinitionBlock ("", "SSDT", 2, "nocnvw", "cnvwoff", 0x00000000)
- {
- Method (_SB.PCI0.CNVW._DSM, 4, NotSerialized) // _DSM: Device-Specific Method
- {
- If (LOr (LNot (Arg2), LEqual (_OSI ("Darwin"), Zero)))
- {
- Return (Buffer (One)
- {
- 0x03
- })
- }
- Return (Package (0x06)
- {
- "class-code",
- Buffer (0x04)
- {
- 0xFF, 0xFF, 0xFF, 0xFF
- },
- "vendor-id",
- Buffer (0x04)
- {
- 0xFF, 0xFF, 0x00, 0x00
- },
- "device-id",
- Buffer (0x04)
- {
- 0xFF, 0xFF, 0x00, 0x00
- }
- })
- }
- }
-
-
die Frage ist, was wird aus N-D-K passieren, wenn er seine Arbeit nicht mehr aktualisiert...!
Jede als PC Nutzer klar wird Windows drauf installieren neben macOS oder eigentlich wir installieren macOS neben Windows
Wenn N-D-K hat geschafft, die Patches für andere Systeme zu deaktivieren dann schafft auch das Team von acidanthera, also warum implementieren das auch nicht in normal OC......!!!???
dann wird keine NDK nutzen !!!!!!!!!!!!!!!!!!!!!
außerdem viele trauen sich nicht zu OC zu wechseln, wegen diesen Patches geschichte
-
Der Quirk, dass ACPI Patches unter Windows nicht angewandt werden stammt von Acidanthera und wurde entfernt. N-D-K hat diesen veralteten Quirk einfach wieder ausgekramt.
Es wurde bereits häufig diskutiert und es gibt eindeutige Gründe, warum es besser ist ACPI Patches konsistent, unabhängig vom OS anzuwenden, dabei werden auch etwaige Randfälle und Formalitäten beachtet, die für den Standardbenutzer nicht direkt ersichtlich oder verständlich sind, jedoch eindeutige Daseinsberechtigungen besitzen. Die Entscheidung bezüglich des Themas ist bedacht gefallen und wird auch derzeit nicht verändert werden. ACPI Patches können so angewandt werden, dass Windows nicht davon betroffen ist, oder keine negativen Folgen davon hat, zudem ist Windows nicht besonders restriktiv was die Erkennung verschiedenster Device Namen (Renames) betrifft. Es ist alles eine Frage der Konfiguration.
-
kuckkuck Danke für diese Erläuterung! Dann werd ich bei mir nun endgültig ausschließlich die Acidanthera-Version weiterhin benutzen, nachdem die ja nun endlich auch auf meinem Board läuft.
Mir wird das sonst auch zu unübersichtlich und umständlich, wie karacho schon sagt
Dass beide ihre Berechtigung haben, leuchtet natürlich dennoch ein.
-
Respekt an die Entwickler von Opencore. So ein Tool zu Entwickeln hängt echt was dahinter und den Entwicklern ist es auch freigestellt die Richtung vorzugeben.
Dennoch ist aus meiner Sicht das Entfernen des Quirks "ACPI Patches unter Windows nicht angewandt" eine falsche Entwicklung. OpenCore wird zu sicher mehr als 90% auf Hackintosh verwendet und nicht auf original Apple Produkten. Weiter hat auch sicher fast jeder dieser Hackintosh Benutzer Windows auf seinem System.
Ein System wie mein MPG Z390 GAMING PLUS kann man ganz einfach Einrichten das auch Windows mit OpenCore läuft. Für diesen Rechner benötige ich keine ACPI Renames da die alle von den Acidanthera Kexten übernommen werden. Auch die SSDT's kann man sich einfach so einrichten das die unter Windows keine Auswirkung haben. Dennoch könnte man sich die Arbeit mit den SSDT's sparen, wenn es den Quirk "ACPI Patches unter Windows nicht angewandt" geben würde.
Bei meinem ASUS Zenbook sieht das Ganze dann doch etwas anders aus. Auch hier werde die ACPI Renames Patches nicht benötigt welche von den Acidanthera Kexten ausgeführt werden.
Das Zenbook benötigt jedoch weitere zusätzliche Kexte und Patches von anderen Kext Entwicklern für eine volle Funktionalität.
Als Beispiel hier der VoodooI2C von alexandred. Alexandred hat nichts mit OpenCore zu tun und wird seine Kext auch nicht so schnell darauf anpassen. Der einzige Kext welcher für mein Trackpad am Zenbook funktioniert ist seiner und der funktioniert auch richtig gut. Damit dieser funktioniert sind ACPI Renames nötig damit die dafür nötige modifizierte SSDT greift.
Und da ist jetzt der Hacken von OpenCore. Der Rename fürs Trackpad ist nötig. Mache ich den nicht in OpenCore läuft das Trackpad nicht unter OSX. Mache ich den funktioniert das Trackpad nicht unter Windows. Habe ich die Möglichkeit per Quirk "ACPI Patches unter Windows nicht angewandt" anzuwenden wie beim N-D-K Fork muss ich mir über so was nicht mal Gedanken machen. Es funktioniert einfach unter beiden Systemen.
Das Trackpad am Zenbook ist nur ein Beispiel. Es gibt da noch weitere unbedingt nötige Renames auf die man nicht so ohne weiteres verzichten kann und welche ebenfalls Auswirkung auf Windows haben.
Hoffe habe es ausreichend erklärt warum ich den Entfall dieses für Hackintosh wichtigen Quirks nicht so gut finde.
Noch etwas zum N-D-K Fork. Aktuell muss man als N-D-K Fork Nutzer auf gar nichts verzichten vom Original. N-D-K gibt sich echt viel Mühe und zieht Änderungen im Original innerhalb von einem Tag nach. Außerdem ist die Konfiguration komplett kompatibel zum Original. Sollte daher irgendwann der N-D-K Fork wegfallen kann man einfach die Dateien vom Original drüber kopieren und schon läuft zumindest OSX wieder mit der neusten OpenCore Version.
-
OC verwende ich nur zum Booten von MacOS. Linux und Windows werden danke Refind bei mir ohne OC gestarted.
-
Kannst du vielleicht kurz genau beschreiben welche ACPI Patches querschlagen und wie diese funktionieren?
Sprich welche Renames werden eingetragen und welche SSDTs sind notwendig? Wenn du dann dazu noch deine DSDT (und weiteren original ACPI Tabellen) anhängst, hoffe ich dass wir möglichst einfach und verständlich eine Lösung finden können, sodass Windows kein Problem mehr damit hat. Lets try
-
Hallo kuckkuck ,
im Moment habe ich dazu wenig Zeit, aber ich werde einen eigen Thread aufmachen und dich mit rein nehmen.
DSDT verwende ich keine. War Projektziel alles über SSDT's zu machen unabhängig von der DSDT. War auch einiges Arbeit was da drin steckt und die Renames nötig machte.
Mit meinem Thread weiter oben wollte ich erst mal nur deutlich machen das die Übernahme der ACPI Patches in Windows das Einrichten eines Hackintosh sehr erschwert und bei einem Laptop nicht ohne sehr gutem Hintergrundwissen möglich ist.
Hallo SabineT ,
so habe ich auch gestartet. Zum Glück gibt es den N-D-K Fork was den Bootloader Refind unnötig macht.