Wechsel von Clover auf OpenCore

griven ... vielen Dank für deine Erklärungen. Das mit den USB3.0-Ports kenne ich bereits. Deshalb schrieb ich ja auch 4x USB3.0 = 8 Ports. Ich finde es merkwürdig, dass Hackintool beim Einstecken der beiden Sticks (jeweils mit USB3.0 und USB2.0) nur die USB3.0-Ports kennzeichnet. Die Ports sind aber in Ordnung. Der Stick wird auf dem Desktop und im Finder angezeigt. Früher stand da immer HS und SS. Jetzt steht da PR und PRT. Na gut, da wo mein Drucker, mein WLAN-Stick und mein Logiteck Unify drinstecken, die hiessen schon früher PR.

Jetzt passt es wieder ...

mit SSDT oder mit USBMap.kext für USB-Ports

Nachtrag: 15 Ports pro Controller.

Moin bluebyte Hab deine EFI mal kurz überflogen. Da hast du aber ganz schön geackert, und auch alles gut dokumentiert in den Comments in der config.

Du nutzt noch USBInjectAll, dann solltest/könntest du bei Kernel->Quirks das XhciPortLimit auf YES setzen. Bei UEFI->Protocols ConsoleControl auf YES und bei UEFI->Quirks noch RequestBootVarRouting auf YES. RequestBootVarRouting muss man nicht unbedingt haben, wenn du jedoch in den Systemeinstellungen gerne das Startvolume auswählen möchtest, dann brauchst du es. Auch hätte ich an deiner Stelle bei Platforminfo die Schlüssel DataHub, PlatformNVRAM und SMBIOS gelöscht, so dass nur noch Generic übrig bleibt, wenn Automatic auf YES steht. Die Unterordner in ACPI hätte ich mir auch gespart. Ansonsten gute Arbeit wenn es deinen Rechner so bootet

XhXhciPortLimit darf nicht länger als nötig an sein

Ich vergass es zu erwähnen. Ja, nur solange bis er seinen eigenen USBPorts.kext gebastelt hat. Danke für die ergänzung mhaeuser

karacho und mhaeuser ... Vielen Dank, dass ihr euch mal die EFI angeschaut habt und für die Rückmeldungen und Hinweise. Werde sie dankend annehmen. Habe eben ausgemistet. Das mit dem RequestBootVarRouting ist natürlich genial. Die DSDT und SSDT in den ACPI sind wirklich überflüssig. Ich wollte es nur einmal testen. Musste mich mal wieder mit den Tools (USBmap, ssdtPRGen, MaciASL) beschäftigen. Ich möchte mich nicht nur daran erfreuen, dass der Rechner irgendwie läuft, sondern ich will es auch verstehen, warum manches mal so und mal so läuft. Kann es sein, dass mal abgesehen vom Master-Kext LILU, die Reihenfolge der Kexts eine entscheidende Rolle spielt? Die Kommentare in der config.plist stammen größtenteils von khronoskernel. Bei NVRAM sollte man sich jedoch mit Kommentaren mit "Comment" innerhalb von Dictionary zurückhalten, sonst werden die ins NVRAM geschrieben. Bei den Device Properties habe ich jetzt (Forrest Gump würde sagen: "Mal wieder!") die Layout-ID eingetragen. Jetzt klappt das auch mit der Soundkarte. Dachte bisher, dass das der PropertyInjector.kext automatisch erledigt. Falsch gedacht. Den Wert Platform-ID für die IGPU muss ich auch noch setzen damit die richtige IGPU angezeigt wird. Den Schalter "Normalize Headers" habe ich auf enabled, weil ich High Sierra starten möchte. Leider bekomme ich da immer noch Fehler.

Die Reihenfolge der Kexte ist elementar. Diese müssen nach Abhängigkeiten sortiert werden. Eine AppleALC beispielsweise wird nicht geladen, wenn nicht zuvor eine Lilu geladen ist. Insofern ist es gerade bei letztgenannten immens wichtig, diese so früh wie möglich zu laden, dami aufbauende Plugins auch ihre Basis finden.

apfelnico und mhaeuser interessant in dem Zusammenhang wäre vielleicht auch zu wissen wie man herausfindet welche Abhängigkeiten es eigentlich gibt. Bei Extensions mit Plugins isses ja irgendwie logisch das die Plugins Abhängigkeiten haben zum Jeweils übergeordneten Kext (VoodooPS2, FakeSMC usw.) ebenso bei Lilu und dessen Erweiterungen weil auch da ist es entsprechend dokumentiert aber wie finde ich das bei Extensions heraus wo es nicht so eindeutig definiert ist?

Als Beispiel sei mal die BRCMPatchRam3 Geschichte genannt denn hier braucht es ja 3 Extensions neben der BRCMPatchRam3.kext auch den BrcmBluetoothInjector.kext und den BrcmFirmwareData.kext gut die Reihenfolge von BrcmFirmwareData.kext und BRCMPatchRam3.kext kann man sich anhand der Funktion noch logisch herleiten denn der PatchRam3 soll ja eine Firmware in den RAM der BT Karte schreiben daher scheint es logisch zu sein das der BrcmFirmwareData.kext vorher geladen sein sollte weil sonst wird es nichts mit dem Patch aber wie verhält es sich mit dem Injector? Logisch hergeleitet würde ich sagen der kommt ans Ende der Kette weil er als Injector dafür sorgt die Eigenschaften der BT Karte an das OS weiter zu reichen und das sollte er dann vermutlich erst tun wenn die Karte auch dazu bereit oder? Wie gesagt logisch hergeleitet aber gibt es einen Weg das gesichert zu erkennen?

Ein anderes Beispiel ist der VoodooInput.kext der für den VoodooPS2 Branch von Acidanthera benötigt wird auch hier stellt sich die Frage wie finde ich heraus in welcher Reihenfolge die Extensions geladen werden sollten? Voodooinput quasi als foundation vor allem was zu VoodooPS2 gehört oder erst VoodooPS2 dann VoodooInput und dann die Plugins? Wie gesagt wäre cool wenn es da eine Möglichkeit gibt die Abhängigkeiten gesichert zu ermitteln (gibt sicher eine nur kenne ich die noch nicht und damit stehe ich vermutlich nicht alleine da weil bisher musste man sich darum ja nicht wirklich kümmern) wenn Ihr da eine Idee habt oder gar eine Möglichkeit kennt wäre es prima das kurz zu erläutern. Danke schon mal

griven ... bei meiner Soundkarte war es relativ einfach. Erst den RealtekALC.kext weil sich darin die info.plist befindet die vermutlich für den AppleALC.kext die Informationen liefert. AppleALC ohne RealtekALC läuft nicht. Falschmeldung. Es läuft doch ohne RealtekALC.kext.

Meine Kernel-Erweiterungen werden in dieser Reihenfolge geladen.

Item 0 Lilu.kext

Item 1 VirtualSMC.kext

Item 2 WhateverGreen.kext

Item 3 PropertyInjector.kext

Item 4 USBInjectAll.kext

Item 5 realtekALC.kext

Item 6 AppleALC.kext

Item 7 AtherosE2200Ethernet.kext

Item 8 SMCProcessor.kext

Item 9 SMCSuperIO.kext

Was mich immer noch wurmt, ist das das Umschalten der Auflösung kurz vor dem Login. Das war schon bei Clover so. Gibt es da eine elegante Lösung?

Ich denke, den PropertyInjector.kext kannst du dir sparen bluebyte . AppleALC.kext mit den korrekten DeviceProperties in deiner config (mit layout-id 1, 5 oder 7) sollte für Onboard Audio reichen. Oder brauchst du den PropertyInjector noch für was anderes?

Mit Hackintool->PCI findest du den Device Path deines Audio Devices. Rechte Maustaste darauf und dann Copy Device Path und in deiner config mit Paste über einen bestehenden Eintrag den du nicht nutzt, einfügen und die layout-id eintragen. (siehe Beispiel anhand meiner config). PropertyInjector.kext noch auf NO und dann mal neu booten.

karacho könntest du mir mal bitte behilflich sein? entweder bin ich zu blind oder..

Wie muss ich für Sound layout-id 1 das eintragen? Ich habe nur dieses Bild im Xcode.

StevePeter ... genau so wie auf dem Screenshot. Der Wert muss im Format Little Endian eingegeben werden. Oh mein Gott, wenn ich noch an die 90er denke. Atari ST, Motorola, 68000er, Big Endian. Eigentlich kein Hexenwerk.

X 00 10 20 30

= 30 20 10 00

X 00 00 00 02

= 02 00 00 00

Läuft dein Audio jetzt mit Layout-id 2 bluebyte ?

StevePeter trage es so ein wie bluebyte oben schrieb.

karacho ... ja läuft mit Layout-ID 2

Einwandfrei. Und ohne propertyinjector?

karacho ... ohne PropertyInjector.kext

bluebyte habs drin, aber in den Systemeinstellungen/Sound werden nur die DisplayPorts angezeigt.?? Unter Clover habe ich aber mit Audio Inject 1 auch die Onboards.

Kexte alle vorhanden und in der richtigen Reihenfolge geladen?

Audio-ID geht auch einfach per Bootargument.

StevePeter ... gehst Du über Monitorausgang? Was sagt Hackintool? Hast Du ioregexplorer?

Bin jetzt selbst am Grübeln. Jetzt tauchen im ioregexplorer Begriffe auf wie layout-id und alc-layout-id.

Habe mich um die Onboard nie so richtig gekümmert. Gehe meistens über mein Focusrite Scarlett, wenn ich meine Gitarren anschließe und in die Saiten haue. Hatte die sogar eine Zeit lang im BIOS ausgeschaltet.

StevePeter dann probiere mal den Vorschlag von apfelnico. Lösche den Key unter DeviceProperties und trage dafür bei Nvram bei den boot-args alcid=1 mit ein. Und achte darauf, dass Lilu in deiner config an erster Stelle steht.

apfelnico  karacho Ihr seid echt super. So funktioniert es mit den int. Sound. Vielen Dank

PS: eine Kleinigkeit hätte ich noch: Wie kann ich die Boot-Reihenfolge ändern? Bei mir steht auf 1 Windows und auf 2 macOS.

Gestartet wird aber immer Windows, ich möchte aber macOS gestartet haben. Das finde ich einfach nicht.