Beiträge von apfelnico

    Ich möchte gar nicht trollen. Tut mir leid, Sorry. Du hattest nur einen Teil wiederholt, was ich oben schon geschrieben hatte. Leider war dein Zitat etwas verkürzt und somit aus dem Zusammenhang gebracht, daraus resultieren Missverständnisse.


    Der Parameter „-1“ deaktiviert den Quirk komplett. Beim Eintrag „0“ wird TRIM deaktiviert - aber nur für die initiale Startphase. Nicht für die Laufzeit von macOS. Dieses steuert das selbst und der Quirk von OpenCore hat damit nichts zu tun. Sieht man auch, wenn man sich den Status einer NVMe anschaut.
    Positive Werte sind Angaben in Millisekunden und bieten eine Verzögerung, den time out, auf den manche Geräte angewiesen waren, damit TRIM während des Startens abgeschlossen werden konnte. Diese Steuerung der zusätzlichen Verzögerung ist seit macOS 12 nicht mehr vorhanden, deshalb ein andere Wert ab dieser macOS Version unsinnig. Ist so nachzulesen im PDF. Schade das du es übersehen hast. Denn leider ist es eben nicht richtig, das mit Wert „0“ TRIM deaktiviert für NVNe Laufwerke. Du schienst griven zu bestätigen mit nem kleinen Auszug aus dem PDF obwohl der Rest da auch drin steht, so eben leider falsch.

    Wahrscheinlich krieg ich jetzt mein Fett weg als „Klugscheißer“. :)

    TRIM immer aktiv es sei denn man deaktiviert es mit OpenCore (APFSTrimtimeout = 0)

    Auch damit wird es NICHT deaktiviert, sondern lediglich in der Startphase nicht mehr genutzt. Dieser Quirk bezieht sich nur auf den Start von macOS. Ab macOS 12 wird zudem kein individueller Timeout mehr akzeptiert. Innerhalb der Laufzeit von macOS regelt dieses selbst TRIM, egal was da in OpenCore eingestellt ist.

    KMac

    Wobei natürlich – wenn es um eine Modifikation der DSDT für das jeweilige System geht und diese wieder per Bootloader eingeschleust werden soll – nur jene als Grundlage zu nutzen ist, welche du verlinkt hast. Nur kann diese eben für ein anderes System, trotz gleichen Boards, oft nicht sinnvoll genutzt werden. Deshalb gab es doch damals vielfach Ärger mit Ozmosis und integrierter, gefixter DSDT. Lief beim Ersteller super, bei anderen durchaus schlecht oder überhaupt nicht.


    Würde nun umgekehrt die aus dem BIOS-File extrahierte, und fehlerbereinigte DSDT per Bootloader eingesetzt werden, so würde das System überhaupt nicht hochfahren, weil die Prozies noch nicht deklariert sind. Heißt, der Rechner fährt mit eigenem BIOS hoch, initialisiert und aktualisiert seine ACPI auf seine Gegebenheiten, um dann vom Bootloader eine jungfräuliche, nicht initialisierte DSDT zu bekommen, quasi auf "dumm" zurückgesetzt.


    Wozu also der Zirkus? Man könnte die extrahierte DSDT bereinigen, um grundlegend wichtige Dinge für "Darwin" :) anreichern und wieder zurück ins BIOS einpflanzen, dann den Rechner damit flashen. Aber weiterhin – wozu? Es wäre lediglich eine Machbarkeitsstudie, rein akademisch. :)

    Enormer Aufwand dafür, dass man sagen kann, "guck mal, mein Häcki läuft ohne jegliche SSDT und irgendwelchen Patches. Und schaust du in die DSDT, findest du keine Fehler."


    Heutzutage lässt man die DSDT in Ruhe, schaut da gern rein und in weitere verlinkte interne Tabellen der ACPI, und kann aufgrund dessen wirksame Ergänzungen per SSDT durch den Bootloader einschleusen. Das ist einfacher, übersteht Aktualisierungen des BIOS und ist universell für verschiedene Systeme innerhalb einer Klasse.



    Würde mich trotzdem reizen, jetzt wo ich drüber schreibe. :)

    Wie gesagt, null Vorteile, nur der Machbarkeit wegen. Ach so, einen Vorteil hätte es: man kann dieses BIOS dann natürlich auch anderen mit gleichem Board zukommen lassen. Nachteil, man sitzt dann auf dieser BIOS-Version fest, oder muss den Zirkus bei neuerem BIOS wiederholen.


    Problem sehe ich nun in der Machbarkeit. Zwar kann ich es mittels aktuellem UEFITool extrahieren, aber nicht einsetzen. Das konnte nur eine alte Version (28), welche aber andere Engine und andere Probleme hatte und nicht unbedingt auf neue BIOS losgelassen werden sollte.

    Auch die alten Tools aus Ozmosis-Zeiten versagen da, weil diese aufgrund der damaligen Plattformen die ACPI in ganz anderen Bereichen des BIOS vermuten.


    Also, wie bekomme ich eine DSDT an oben genannter Stelle wieder ins BIOS integriert, sodass sich dieses BIOS auch sauber flashen lässt? Probieren würde ich es schon fast, es kribbelt wieder in den Fingern. Wer kann helfen? Damals gab es auch Probleme, wenn die Section größer war als vorher. Zumindest dieses Problem stellt sich hier nicht. Obwohl einiges zusätzlich eingetragen wird, kann auch jede Menge raus, ohne Probleme zu verursachen. Zum Beispiel innerhalb der DSDT der Bereich ab Device (PC04) bis einschließlich (PC05) inklusive späterer weiter beschreibenden Scopes etc.

    Diese PCI-(Bus)-Bereiche gibt es bei der Plattform X299 nicht. Da ist die DSDT wohl etwas allgemein auch für höhere Systeme schon ausgelegt gewesen. Was man auch an der Zählung der CPU erkennt. Bei X299 gibts maximal 18-Kerner, nicht den 28-Kerner der in der ACPI schon angelegt ist. Jedenfalls kann da einiges an Ballast raus, so dass die DSDT trotz zusätzlicher Beschreibung eher kleiner ist. Und sollte sie exakt genau so groß werden müssen wie das Original, dann muss man eben hinten dran noch etwas Spaghetti-Code anhängen, 'ne Danksagung zum Beispiel. :)

    KMac und wen es noch interessiert :)


    Benötigte freie Software fürs Nachvollziehen:

    UEFITool – https://github.com/LongSoft/UE…_NE_A68_universal_mac.zip

    MaciASL – https://github.com/acidanthera…MaciASL-1.6.5-RELEASE.dmg


    derzeit aktuelles BIOS 4201 für Asus X299 Deluxe (Version 1)

    https://dlcdnets.asus.com/pub/…X299-DELUXE-ASUS-4201.zip


    Einfach UEFITool starten und per drag'n drop das BIOS-File reinwerfen.

    Dann hangelst du dich durch folgenden Wust:



    … bis zu dieser Section:



    … und kannst per Rechtsklick auch schon mal reinschauen mit Body hex view …



    Zum rauspopeln nutzt du dann Rechsklick – Extrakt Body …



    Wenn du nun die DSDT vergleichst, wirst du zum Beispiel bei den Processor Keywords im Original für ALLE (bis CP37 – 0x00-0x37 – also 56, entspricht 28Core HT) die gleiche Formatierung sehen (CPxx, 0x25, etc).



    Erst bei deiner ausgelesenen DSDT werden dort statt beispielsweise 0x25 die jeweils korrekte Zählung deiner virtuellen Kerne aufsteigend vorgenommen, bis eben CP17, danach stumm 0xFF.

    CP17 entspricht 0x17 hex = 23 dezimal, also ab null gezählt 24 (virtuelle Kerne), macht 12 Core CPU.

    Nee, spezifisch. Anhand der DSDT kann man sehen, welche CPU mit wieviel Kernen genutzt wird etc.
    „Jungfräulich“ ist die nur, wenn mit zum Beispiel UEFITool direkt aus dem BIOS-File rausgepopelt.


    Deine DSDT durchlief schon einen Prozess beim starten, wurde dynamisch angepasst durch BIOS-Einstellungen und installierter Basis - auf einen sehr niedrigen Level - und vom Bootloader ausgespuckt. Wir können gern mal ins Detail gehen, aber interessiert‘s heute noch jemanden? 😀

    Kenne deine Plattform nicht weiter, habe aber mal in deine EFI geschaut. Was mir auffällt, sind viele eingebundene SSDTs – werden die alle benötigt?

    "Failed to drop …" bezieht sich auf den Eintrag in der config.plist "Delete in ACPI", die angegebene SSDT die entfernt werden soll, gibt es nicht, jedenfalls nicht wie beschrieben". Und im Bereich UEFI in der config.plist wird offenbar auch etwas im Array Unload erwartet.

    Dann sind jede Menge Patches im Bereich ACPI drin, kann mir nicht vorstellen, dass diese alle benötigt werden. Die vielen Device-Properties sind auch nötig?

    Ein deutlich schlankeres OpenCore würde dir gut tun, vieles erst in der Post nach Installation fixen, wenn nötig. Wenn du die USB-Kext nicht selbst erstellt hast, dann würde ich die erstmal rausnehmen, im Zweifel hast du damit schon deine USB gekillt und somit keinen Zugriff auf ein bootfähiges Medium

    Im Bereich Security setze mal den Parameter von ScanPolicy auf 0. Damit erlaubst du erstmal ALLES an ALLEN Schnittstellen zu booten.

    Bei Serial werfe mal den Eintrag "Customer" komplett raus.

    Bei UEFI in den DRIVERS lösche mal das Argument beim "ResetNvramEntry.efi (-preserve-boot)

    In den Quirks von UEFI setze mal "DisableSecurityPolicy" auf YES, und UnblockFsConnect auf NO


    Gibt es nicht bei Dortania eine allgemeingültige Konfiguration als minimale Basis für dein benutztes System?

    Im EFI-Ordner befindet sich der Bootloader. Entweder Clover oder OpenCore.
    was der bewirken soll ist dir doch klar. Und eine ESP - EFI System Partition - ist der Bereich auf einer Festplatte (wenn GUID-Partitionstabelle, nicht altes Master Boot Record genutzt), der fürs starten verantwortlich ist. Und dieser liegt letztendlich als FAT32 vor.

    Tatsächlich kannst du einen USB-Stick auch kompliziert mit GUID und zum Beispiel MacOS Extended formatieren und dabei wird auch automatisch eine versteckte EFI-Partition erzeugt, worin du in einem EFI-Ordner deinen Bootloader ablegen kannst, jedoch nur für einen Stick mit Bootloader halte ich das persönlich für zu komplex. Da es extra Mühe bereitet, diese Partition zu mounten um sie zu beschreiben. Es reicht tatsächlich ein MBR/FAT32 Stick. Ist einfacher zum beschreiben und ändern.


    Das es grundsätzlich funktioniert, siehst du doch daran, das OpenCore startet. Nur wird dann kein startbares System angezeigt. Und daran lässt sich doch arbeiten, das hat Gründe. OpenCore kann Windows, macOS und Linux etc erkennen und starten. Mitunter fehlen dazu aber weitere eingebundene Dateisysteme als EFI-Treiber, oder es fehlt eine grundsätzliche Berechtigung zum starten diverser Laufwerke.

    Nur einen Stick mit einem EFI-Ordner drauf zum starten des Bootlladers ist oben schon mal geschrieben worden. Da muss keine EFI-Partition dafür angelegt werden. Es reicht den Stick einfach nur FAT32 zu formatieren und den EFI-Ordner darauf zu kopieren. Egal, ob du nun OpenCore oder Clover nutzen möchtest. Denke das die Mehrheit hier zu OC tendiert und dir damit besser helfen kann.

    Möchte auch nix lostreten 😀

    Klar konnte man nach jeder Veröffentlichung von zum Beispiel Open Core den nächsten Bump abwarten und sich eine „Folgeversion“ kompilieren. Hat aber oft wenig mit der jeweils fertigen Version zu tun, weil währenddessen noch Dinge nachgepflegt werden. Das die Abstände der Veröffentlichungen in letzter Zeit immer gestreckter wurden, ist nachvollziehbar.
    Ziehe nach wie vor meinen Hut vor den Machern von acidanthera, von OpenCore, Lilu nebst Plugs und und und …