Vorwort
Dieser Artikel geht nicht darauf ein, wie man ein BIOS flasht, macOS lädt, oder wie man einen Bootstick erstellt. Auch sind die vorbereitenden Maßnahmen hinsichtlich des Funktionierens der beiden 10G-Ethernetports hier nicht beschrieben. Dafür geht ihr bitte in dieses ältere Tutorial von "DSM2", zum Punkt „Ethernet“:
X299 TUTORIAL - ASUS WS X299 SAGE/10G
Hier geht es um einen Einblick in die ACPI, um bestimmte Konfigurationen nachvollziehen zu können. Es ist keine detaillierte Schritt für Schritt Anleitung, am Ende des Artikels wird ein mit geringer Modifikation lauffähiger OpenCore-EFI-Ordner zu laden sein. Lest bitte dennoch aufmerksam, es hilft ungemein für eigene Anpassungen.
Allgemeines
Das "WS X299 SAGE/10G" von ASUS, weiter im Text einfach nur "SAGE" genannt, ist ein etwas besonderes Board. Mit neuestem BIOS-Update (Stand Februar 2021, Version: "3302") können auch die aktuellsten Prozessoren genutzt werden.
Da das Board selbst schon etwas älter ist, können hier allerdings nicht alle 48Lanes der CPU genutzt werden, es wurde ursprünglich für maximal 44Lanes entwickelt. Trotzdem ist es in der Lage, vier PCIe 3.0 x16, oder gar sechs PCIe x8 plus einen x16 simultan bereitzustellen. Mischformen sind auch möglich, ein Blick auf das Blockdiagramm enthüllt den Zauber:
Das Interessante am SAGE sind die besonderen Chips, die PLX und QSW. Diese MultiPLeX- und Quick-SWitches fungieren vereinfacht ausgedrückt als "Verdoppler" und "Verteiler". Sehr gut zu erkennen ist im Diagramm, wie aus lediglich zwei x16 vom Prozessor die sieben PCIe-Slots bestückt werden.
Wie funktioniert das Ganze? – Ziemlich gut! – um es mit den Worten von Montgomery "Scotty" Scott zu sagen (auf die Frage, wie denn der "Heisenbergkonverter" funktioniere, der das Heisenbergsche Unschärfen-Theorem geschickt umgeht).
Dabei hat der Prozessor durch nur zwei x16 noch deutliche Reserven. So sind zusätzlich direkt am Prozessor 2x 10Gbit Ethernet (Intel X550), je eine M2 und U2 angebunden. Am PCH finden wir die üblichen Verdächtigen wie Audio, USB, eine weiterer M2, SATA sowie per PCIe Root Port (RPxx) zweimal USB3.1 Gen2 (ASMedia) sowie bei Bedarf PCIe x4 für Thunderbolt3.
Ziel diese Tutorials ist es, einen lauffähigen EFI-Ordner zu erhalten, in dem sämtliche auf dem Board vorhandenen Geräte optimal eingebunden werden. Wir entscheiden uns für eine Mischung aus SSDT und OpenCore Properties Injection, so ist es einfacher für eigene spezifische Anpassungen einen geeigneten Weg zu finden.
ACPI
Schauen wir uns aus der ACPI zunächst die DSDT an. Ein Problem beim aktuellen BIOS (neben den Vorzügen der Aktualität) ist, dass hier ein neues Device eingeführt wurde: AWAC. Dieses neue "Time and Alarm Device" ersetzt in der Standardkonfiguration das altbekannte RTC. Letzteres ist aber für macOS wichtig. Ohne "Real Time Clock" geht's nun mal nicht. Ein bekanntes Verfahren ist, den Wert von "STAS" von "0" auf "1" zu setzen, um das ebenfalls vorhandene, aber deaktivierte RTC mit dem neuen AWAC auszutauschen.
Wie man sehen kann, ist nur eines der beiden jeweils aktiv. Interessant aber ist zum Einen, dass AWAC selbst keinen Einfluss auf macOS hat, zum Anderen, dass das RTC ohnehin eine fehlerhafte Konfiguration besitzt, es werden nicht alle vorhandene Ports im Device zugeordnet. Machen wir somit aus der Not eine Tugend und lassen zunächst alles beim alten. AWAC ist aktiv, RTC nicht.
Das bietet uns die Chance, per SSDT ein fehlerbereinigtes "RTC0" einzubinden, denn "RTC" als Namen des Devices geht nicht mehr, es ist nunmal – ob aktiv oder nicht – im Code der DSDT enthalten. Und an ein und der selben Stelle kann eben kein zweites sein, wussten schon die alten Griechen.
Ein nächstes Problem ist das Device "EC0". Auch dieses versteckt sich unter "LPC0", dem "Low Pin Count Bus", an dem weitere Geräte wie das schon bekannte RTC, PS2-Maus/Tastatur, DMA-Controller, Speaker sein könnten. "EC0", der sogenannte "Embedded Controller", ist nicht auf jedem Board vorhanden, vornehmlich übernimmt dieser in Laptops seine Aufgabe unter anderem für Tasten-, Akku- und Lüftersteuerung. Auch für Sleep/Wake kann er mit zuständig sein.
macOS möchte diesen Controller gern "EC" genannt haben, damit dieser genutzt wird. In früheren macOS-Versionen wurde an "EC" gern auch die USB-Stromversorgung/Steuerung delegiert. Fehlte das Device, gab es nicht genügend Stromstärke an den USB-Ports; Geräte die mehr Leistung benötigten, funktionierten dann bestenfalls nur eingeschränkt.
Es gibt dafür heute eine andere Möglichkeit, aber das Thema "EC" möchte ich noch beenden, schliesslich soll alles mit den verschiedensten macOS laufen. Machen wir es kurz – auch die embedded Controller auf Desktops sind meistens für macOS nicht sinnvoll nutzbar, oftmals wird ein unpassender Treiber geladen, der dann mehr schaden als nützen kann. Wir benennen also "EC0" nicht in "EC" um, sondern deaktivieren ihn mittels der Methode "_STA" (Status).
Den Status eines Devices kann man abfragen und auch setzen. Dabei gibt es viele feine Abstufungen, ob etwa ein Gerät vorhanden ist, oder aktiviert, oder in der UI angezeigt wird, ob es ordnungsgemäß funktioniert. Wir nutzen nur die beiden "extremen" Werte 0x00 oder 0x0F, garniert mit einer Abfrage nach "Darwin".
Darwin an sich ist der ursprüngliche, quell-offene BSD-Kern, die Basis von "Mac OS X". Es war damals ein freies UNIX-Betriebssystem von Apple und heute nur noch als Quellcode des jeweiligen Systems vorhanden, nicht aber (von Apple) Distributionen. Trotzdem erfolgt die Abfrage nach macOS auch bei echten Macs in deren ACPI mittels "Darwin". Somit können wir sicher stellen, dass unsere Manipulationen nicht etwa Windows betreffen. Neben der Deaktivierung von "EC0" erstellen wir ein "Dummy-Device" namens "EC". Dessen einzige Aufgabe ist es "da zu sein" und je nach verwendetem System einige Werte zur USB-Stromstärke zu bekommen, selbst ausführbar muss es nicht sein.
Kommen wir nun zu USB. Da der "XHCI" (der Standard-USB-Controller des Chipsatzes) unter 15 Ports hat, ist hier nichts auszuklamüsern, keine temporären Port-Limit-Patches zu nutzen. Sehr erfreulich. Dennoch ist es sinnvoll, die einzelnen Ports näher für macOS zu beschreiben. Das machen wir ebenfalls mittels einer SSDT. Schauen wir wieder in die ACPI rein, finden wir neben dem grundsätzlichen Gerüst in der DSDT noch eine weitere SSDT, die diese Ports näher beschreibt: die "SSDT AMI".
Hier finden wir neben den einzelnen Ports für XHCI (USB3 USB2), auch nähere Beschreibungen für die zwei ASMedia (USB3.1 Gen2, 10Gbit/s) an RP09 sowie RP11. Schauen wir uns zunächst XHCI an, so fällt auf, dass hier offenbar eine generische SSDT für eine Vielzahl von Boards vorliegt, die wie so oft in der ACPI zu finden ist. Hier sind Ports beschrieben, die gar nicht auf dem Board existieren. "SS/HS 01-06" existieren real (vier hinten am Board, zwei auf dem Board) jeder dieser physischen USB3-Ports enthält einen weiteren USB2-Port mit extra Datenleitungen, so dass wir schon jetzt auf 12 Ports effektiv kommen.
Merke: Das macOS Port-Limit von maximal 15 Ports gilt "je" Controller. Zusätzlich gibt es noch einen echten internen USB2-Port "HS14" (komplett intern verdrahtet ohne offene Schnittstelle) an dem "AURA" hängt, also ASUS' "Lichtsteuerungsgedöhns". Somit letztendlich 13 effektive Ports an "XHCI". Der Chipsatz X299 bietet jedoch insgesamt 26 Ports an, egal ob vom jeweiligen Boardhersteller auch genutzt. Somit sind hier in der ACPI (in der DSDT und weiterbeschreibende SSDT) eben alle möglichen Ports vorhanden.
Wir schreiben die aktiven und inaktiven Ports um, versehen sie mit den notwendigen Properties damit macOS "weiß", worum es sich handelt. Wie hier im Programm "Hackintool" zu sehen, sind die USB-Ports korrekt beschrieben über unsere SSDT, es ist somit keine extra "USB-Port.kext" notwendig (wobei wie im Bild zu sehen "XHC4" zu Thunderbolt gehört und nur dort auftaucht, wenn auch eine solche Karte eingesetzt ist):
Nebenbei bemerkt ist das nicht macOS-spezifisch, sondern grundsätzlich in den ACPI-Spezifikationen festgelegt. Scheint nur leider keinen Mainboardhersteller zu interessieren.
Und wenn es die Mainboardhersteller "richtig gut" machen würden, dann wäre neben den Abfragen zu diversen Windows-Varianten und weiteren Systemen innerhalb der ACPI auch "Darwin" Thema nebst angepassten Routinen. Denn "Darwin" selbst ist, wie wir gelernt haben, gemeinfrei.
Da wir schon gelernt haben, "wo eins ist, darf kein zweites sein", müssen wir die originale SSDT aus der ACPI entfernen, diese soll in Zukunft nicht mehr geladen werden. Werfen wir deshalb nochmal einen Blick auf den Header der originalen "SSDT AMI".
Hier sehen wir ein interessantes Detail, das uns ermöglicht, diese SSDT einwandfrei auszuwählen: "Length 3079". Zwar kann man SSDT auch nach Namen finden, oftmals aber ist das im Detail zu ungenau, gerade mit Leerzeichen im Namen. Somit können wir diese SSDT sehr einfach mit OpenCore entfernen.
OpenCore ACPI
Die Konfigurationsdatei "config.plist" kann man mit beliebige Texteditoren öffnen und bearbeiten, empfehlenswert sind aber "echte" Plist-Editoren, wie zum Beispiel "Plist Edit Pro". Um vorhandene SSDT aus der ACPI des Mainboards zu unterdrücken (die sind natürlich weiterhin vorhanden, werden aber nicht geladen), schauen wir uns den Bereich "ACPI" an. Wir haben für die "SSDT AMI" eine bestimmte Bitlänge gefunden, so sieht dann der Eintrag dazu aus:
Eine zweite SSDT wurde hier ebenfalls auskommentiert, diese "PTID" ist allgemein und für unser System nicht von Bedeutung.
OpenCore DeviceProperties
Werfen wir einen Blick in Device Properties, hier als Beispiel das Board-interne Audiodevice. Die Umbenennung des dahinterliegenden Devices "CAVS" (ACPI/DSDT Asus) zum Apple-konformen "HDEF" erfolgt durch eine Kext, da müssen wir nichts tun. Die Einträge selbst sind – wer bereits schon SSDT bearbeitet hat und "_DSM Methoden" kennt – selbsterklärend. Interessant ist, das egal welchen Typs wir hier deklarieren, zu diesem späten Zeitpunkt der Injektion ausschliesslich das Format "DATA" eingebunden wird. Benötigen wir darüberhinaus Einträge im Format "STRING" oder "NUMBER", so sind diese über eine SSDT vorzunehmen; diese Veränderungen der ACPI werden innerhalb der Bootphase deutlich früher abgearbeitet als OpenCores "DeviceProperties".
Wie kommt man nun überhaupt zu den Pfaden der gewünschten PCIe-Geräte? Hier helfen diverse Programme, zum Beispiel "Hackintool". In der Rubrik "PCIe" können wir uns sämtliche Geräte anzeigen lassen und nach belieben sortieren. Hier exemplarisch unser "HDEF". Ein Rechtsklick drauf, "Copy Device Path" angewählt, schon ist die Adresse in der Zwischenablage und kann in unsere config.plist eingesetzt werden.
OpenCore NVRAM
Hier gibt es diverse Einstellungen, wir wollen uns auf die Boot-Argumente beschränken. Eine allgemeingültige Aussage darüber, welche Einträge zu treffen sind, gestaltet sich schwierig. Mit den hier vorliegenden boot-args ist eine Basis geschaffen. Der erste Eintrag steht für "Keep symbols on Kernel Panic", der zweite schafft einen bestimmten Modus für den Ruhezustand und der letzte weist "WhateverGreen.kext" an, AGDP nach einem Patch von "Pike R. Alpha" zu modifizieren, "Board-ID" durch "Board-IX" zu ersetzen. Letzterer kann entfernt werden, wenn Probleme mit der Grafikkarte auftauchen.
OpenCore PlatformInfo
Generell kann für dieses System ein "iMac1.1"-SMBIOS empfohlen werden, auch wenn der Rechner sich doch eher anfühlt wie ein "MacPro". Dieser "Befindlichkeit" sollte man aber nicht nachgeben, denn CPU, Chipsatz und Speicheranbindung ähneln dem iMacPro deutlich – auch wenn wir freie PCIe-Slots haben und keinen "All in One Computer". Schaut man sich die ACPI des iMacPro an, so wird die Ähnlichkeit zum X299 noch deutlicher – denn der iMacPro basiert auf dem recht ähnlichen Chipsatz C422 mit einer XEON-W CPU. Sämtliche am Ende des Artikels downloadbare Files sind somit auf dieses SMBIOS hin optimiert.
Die "xxx" müssen mit den eigenen SMBIOS-Daten aufgefüllt werden, die "ROM" bitte mit der Hardware-MAC-Adresse des ersten Ethernet-Ports auffüllen (nur die Zahlenwerte hintereinander ohne Doppelpunkt). SMBIOS-Daten neu generieren lassen kann man sich unter anderem mit dem Programm "Hackintool" unter System\Serial Generator.
Dieser Artikel erhebt nicht den Anspruch der Vollständigkeit, auf dieser BASIS erhält man ein sofort startbares und solides System. Weiterreichende SSDT, speziell für Grafikkarten, sind nicht integriert, zu verschieden sind hier die Anforderungen. Aber durch "WhateverGreen.kext" ist ein grundsätzliches Funktionieren der eingesetzten Grafikkarte(n) gewährleistet.
Enthalten und eingebunden ist allerdings eine zusätzliche SSDT zur näheren Beschreibung für Thunderbolt3, HotPlug ist damit prinzipiell möglich. Empfohlen wird hier ausdrücklich eine "Titan Ridge Thunderbolt3" von Gigabyte. Optimalerweise auch mit alternativer Firmware, um das volle Potential dieser Schnittstelle auszuschöpfen. Die SSDT zu Thunderbolt bezieht sich auf deren korrekte Position in Slot-2.
Belegung der PCIe-Slots
Empfehlung laut ASUS: erste Grafikkarte in Slot1. Wenn zweite Grafikkarte, dann in Slot5. Thunderbolt-Controller in Slot2. Sollte es hier Probleme mit der Baubreite geben (erste Grafikkarte zu breit, nicht wassergekühlt), nicht verzweifeln, dennoch an der Slotbelegung festhalten. Wie geht das? Die erste Grafikkarte nach einen geeigneten Platz im Computergehäuse auslagern und mittels PCIe-Extender-Kabel verbinden. Moderne Gehäuse bieten so etwas an, auch wenn der Hintergrund hierbei eher der "Präsentation" (oft durch ein Glasfenster) gilt. Dennoch ist dieses Vorgehen förderlich für die optimale Belegung, mit der keine Probleme geschaffen werden.
Systembericht
Dateien
Danke, dass ihr es bis hier geschafft habt. Dies war kein klassisches Tutorial, ich möchte auch keinen "Support" anbieten. Was bleibt, ist ein lauffähiges EFI – als solide "Basis" geeignet – weitere Verbesserungen sind ausdrücklich erwünscht. OpenCore (Master 0.6.7) sowie alle Kexte sind frisch kompiliert (Stand 23. Februar 2021), System getestet und produktiv eingesetzt, läuft unter Catalina sowie Big Sur. Hier der Inhalt der beiden Zip-Container:
Nicht vergessen, die "config.plist" muss noch bei "PlatformInfo\Generic" an vier Stellen individualisiert werden, ansonsten sollte alles laufen. Viel Spaß!
Für Diskussionen, Fragen und Anregungen bitte hier entlang:
