OpenCore Sammelthread (N-D-K Fork)

    anonymous_writer Tut mir Leid, die einfachst mögliche Einrichtung für jedermann ist ziemlich weit unten auf der Prioritätsliste. Eine Erklärung für das Verschwinden des Quirks gibt es hier: https://www.insanelymac.com/fo…ndComment&comment=2675604


    Priorität haben Sicherheit, Stabilität, Verifizierbarkeit und Zukunftssicherheit - OC soll kein Spielzeug sein, um irgendwie mit der Brechstange macOS neben andere OSes zu zwängen. Clover und der Fork sind komfortabler und jeder kann sie gerne nutzen. Schaut man sich aber an, wie viele und zu welchem Grad macOS-Updates ohne Änderungen an Code und Config überlebt werden, kommt nichts an Vanilla-OC heran, wegen der Custom-Entry-Problematik auch nicht der Fork. Meines Wissens haben wir nur drei Optionen, die nicht funktionieren, wenn macOS nicht als solches erkannt wird: CustomSlide, SafeModeSlide und eine dritte, die mir gerade nicht einfällt. Die Kext-Injection und alle Kernel-/Kext-Patches basieren leider aktuell auf dem Kernelnamen. Alles andere funktioniert unabhängig davon, dass das gestartete OS als macOS" erkannt" wird. Apple kann so einiges ändern, ohne, dass OC den Dienst einstellt und das ist auch das Ziel.

    Hallo mhaeuser , das passt schon. OpenCore ist auf dem richtigen Weg und danke für die Arbeit.

    Soll von mir nur ein Hinweis sein das OpenCore und Windows sich nicht wirklich vertragen.

    Hallo mhaeuser , Hallo kuckkuck ,

    wollte euch noch Rückmeldung geben das mein Asus Zenbook jetzt Catalina und Windows 10 kann mit dem original OpenCore Bootloader.

    Habe da gestern Abend etwas Zeit investiert und konnte es so lösen das beide System problemlos von OpenCore aus booten. Beide Systeme sind auf dem Zenbook verschlüsselt mit BitLocker und Filevault. Unter beiden Systemen läuft nach wie vor alles 1A.

    https://bitbucket.org/anonymou…330uak-efi-oc/src/master/


    Einzig den NdkBootPicker habe ich noch aktiv. Aber der greift ja nicht ins System ein und ich habe ihn drauf weil mir die Oberfläche gut gefällt. Auch das mit F10 Bildschirmfoto ist nee feine Sache.


    Danke nochmals an mhaeuser und das ganze OpenCore Team für die überagende Arbeit.

    Das freut mich zu hören! Wo ich dir eindeutig Recht geben muss, ist dass das korrekte anpassen von ACPI Tabellen, sodass sie sowohl unter macOS als auch Windows das richtige tun einiges an Fachwissen voraussetzt, besonders was Laptops angeht. Vielleicht schafft es ja jemand in Zukunft einen guten Guide dazu zu schreiben, auch wenn das kein einfaches Unterfangen ist.


    Was mich jetzt noch interessieren würde, wäre was bisher die Win Probleme verursacht hatte, bzw welche Veränderungen du im Hinblick auf Win Kompatibilität vorgenommen hast. Ich schätze mal bestimmte Renames haben dazu geführt, dass Windows beim Boot ins Leere gegriffen hat, wenn bestimmte SSDTs nicht geladen wurden. Deswegen hast du dafür gesorgt, dass folgende SSDTs jetzt auch unter Windows aktiv sind?

    • SSDT-ALSC
    • SSDT-ATK-KABY
    • SSDT-LPC
    • SSDT-PTSWAK
    • SSDT-RALS

    Und der Patch _DSM zu XDSM hat sich wohl als überflüssig ergeben. Ist das richtig so? :)

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    Hallo kuckkuck ,

    der Hauptblocker warum Windows gar nicht starten wollte war dieser Rename:


    und die dazu gehörende SSDT.

    Code
    1. Method(GPRW, 2, NotSerialized)
    2. {
    3. If (0x6d == Arg0) { Return(Package() { 0x6d, 0, }) }
    4. If (0x0d == Arg0) { Return(Package() { 0x0d, 0, }) }
    5. External(\XPRW, MethodObj)
    6. Return(XPRW(Arg0, Arg1))
    7. }

    Das war wegen Aufwachen aus dem Sleep. Ich habe da anscheinend keine Problem mehr oder das Problem war nur unter Clover. Jedenfalls gibt es aktuell kein Aufwachen aus dem Sleep wenn ich den Patch weglassen.


    Rename _DSM zu XDSM war das zweite Problem wie du bereits erkannt hast. Warum ich denn drin hatte weiß ich gar nicht mehr. Jedenfalls funktionier alles unter Cataline ohne diesen Patch wie gewohnt. Unter Windows hat der Patch bewirkt das der I2C Bus fehlerhaft geladen wurde und dadurch das Trackpad seinen Dienst verweigert hat.

    OpenCore NDK 0.5.9 (Nightly) kann Big Sur starten, aber nur, wenn Der PrelinkedKernel forciert UND AvoidRuntimeDefrag deaktiviert ist. Letzteres ist nicht gut, da es zu Speicherkorumpierung kommen kann, außerdem funktioniert das nicht bei jeder Hardware.

    Deshalb hier eine angepasste version, die den Kernel auch starten kann, wenn AvoidRuntimeDefrag aktiv ist. Der PrelinkedKernel muss trotzdem forciert werden.

    Ist auf basis des letzten Commits auf Github.

    Release Version, DEBUG folgt (debug macht noch Probleme bei mir)

    Getestet mit ASUS Laptop. OpenRuntime aus dem Letzten NDK Release verwenden.


    Edit: Debug vorerst nicht...