Beiträge von apfelnico

Ich schreibe mal etwas, weil ich hier erwähnt wurde. Bitte haut euch nicht.

Zitat

Habe das halt neulich in USB ssdts gesehen, die PLD Einträge. Also entweder man füllt sie dann auch tatsächlich richtig aus, oder man lässt sie weg. (…) "PLD" ist vollkommen irrelevant für das USB port Mapping. De geht es nur um die physische Lokation des USB Ports im Gehäuse-Kontext.

Nach ACPI ist genau geregelt, bei welcher Beschreibung der _UPC auch eine _PLD zu erfolgen hat. Ob das nun relevant ist oder nicht; es ist aus Sicht der ACPI-Vorgabe richtig. "Richtig ausfüllen" – viele Positionen kann man mit "0x0" belassen, man muss jetzt nicht Farbe, Position, Form und Gruppierung festlegen, wenn Eintrag und Wert vorhanden ist, ist der ACPI genüge getan und die originale Vorlage gibt auch nicht mehr her.

Sehr wohl gibt es darüber hinaus aber Positionen innerhalb der _PLD, die fürs System interessant sein können. Wie zum Beispiel UserVisible, Ejectable und EjectRequired. Diese gehen deutlich über die sehr rudimentäre Beschreibung via _UPC hinaus und können helfen, zum Beispiel interne Ports besser zu beschreiben, auch für Energiesparmaßnahmen, Sleep etc.

Dann ist noch die Frage, wie man die eigene modifizierte SSDT ins System bekommt. Normal ist ja eine genau dafür in der ACPI des Mainboards vorhanden (möglicherweise auch schon in der DSDT beschrieben). Diese SSDT muss ja nun durch OpenCore gezielt entfernt werden, dafür die eigene modifizierte eingebunden*. Wenn jetzt der Rechner über OpenCore läuft und darüber auch andere Betriebssysteme neben macOS laufen, dann sollte die eigene SSDT – da ja die originäre SSDT nicht mehr vorhanden – auf eben dieser aufgebaut sein. Mit Osi-Weichen kann gezielt für macOS (Darwin) differenziert Parameter festgelegt, so das andere Systeme nicht weiter berührt werden.

Und bevor ich da alles über den Haufen werfe, weil sich macOS (vielleicht/angeblich) nicht für sämtliche Parameter interessiert, mache ich das doch lieber ACPI-konform (wie es auch in der ACPI sämtlicher Intel-Macs aussieht), so das die Eingriffe "minimal invasiv", für macOS verständlich und für alle anderen transparent sind.

Wie gesagt, wenn man es richtig macht, ist es nie nur eine zusätzliche SSDT wie zum Beispiel speziell für eine Grafikkarte oder irgend einen anderen Controller auf einer zusätzlichen PCIe-Karte – sondern eine SSDT, die ausgetauscht gegen eine vorhandene gesetzt wird. Und da ist (meiner Meinung nach) besondere Sorgfalt nötig.

*Denn wenn eine SSDT bereits vorhanden ist die bestimmte Geräte beschreibt, dann kann NICHT eine zusätzliche SSDT das selbe Gerät mit selben Methoden beschreiben. Diese werden dann in der Regel nicht akzeptiert.

Ob das nun alles zu "akademisch" ist?

Deshalb ist das ja auch nicht mehr mein favorisiertes Verfahren. Man muss eben genau hinschauen, hat es mitunter mit einem komplizierten Geflecht zu tun. Im Zweifel ist da eine beschreibende KEXT sehr viel einfacher einzubinden, diese gilt dann auch nur ausschließlich für macOS – und wenn in OpenCore angegeben – auch explizit für bestimmte Versionen von macOS.

Dennoch kann es Spaß machen, bestimmte Tabellen der ACPI, die oftmals für ganze Mainboardklassen universell angelegt sind, zu überarbeiten und ans individuelle System zu optimieren. Und da ist man sicher nicht schlecht beraten, Vorgaben der ACPI sich anzuschauen und danach zu arbeiten, zumal in den offiziellen Unterlagen oft auch hilfreiche Beispiele und gute Erklärungen zu den Funktionen bereit stehen.

Bin unterwegs, kann erst Mittwoch Abend reinschauen.

Mach das alles direkt am MacBook Pro

Zitat von karacho

Wer jetzt darüber entsetzt ist...schaut auf meinen Avatar.

Nein! Doch! Ohh!

Einmal im Jahr darf das. 😂

Mach gerade Schnittchen. 😂

Bin vorbereitet 😂:

Es gibt KEINE Software dazu. Eine spezifische SSDT, deren Grundlage die von Apple ist. Und eine modifizierte Firmware auf dem Controller. Impulse dazu und Grundlagen sind damals HIER entstanden.
Wenn du eine IORegistry Datei (mit IORegistryExplorer erstellt) hier hochlädst, kann dir mit einer spezifischen SSDT geholfen werden.

Im Übrigen habe ich zwei x299 Systeme mit solchen Karten und gehörte zum damaligen Team, welches das ermöglichte. Thunderbolt läuft noch heute perfekt auf diesen Maschinen. 😊

Software dazu kann also im weitesten Sinn sein: IORegistryExplorer, MaciAsl ( zum editieren von DSDT und SSDT, Software zum flashen von bestimmten Controllern sowie die modifizierten Firmwares. Alles im Netz und hier zu finden. Da dein Controller (im Systembericht unter Thunderbolt) erkannt wird, ist dieser bereits erfolgreich modifiziert. Es bedarf eben einer näher beschreibenden SSDT. Diese muss an die tatsächlichen PCIe-Pfade deines Systems angepasst werden. Etwas anderes steht in deiner gesuchten Anleitung nicht drin.
Interessant ist noch, wie mit einem eventuell vorhandenen Thunderbolt-Connector vom Mainboard umgegangen wird. Normalerweise verbunden mit Kabel zum Controller, kann bei einer geflashten Karte auch Pin 3 und 5 gebrückt werden.

Mein erster Hackintosh war 1994 ein Amiga4000 mit ShapeShifter. Es musste ein Original MacRom ausgelesen werden und dann lief auf der recht ähnlichen Hardware System 7 und macOS 8. Somit hatte ich auf einem etwa halb so teurem Amiga (mit Grafikkarte, SCSI-Controller und Netzwerkkarte zunächst etwa 6.000 DM), gegenüber der Apple Quadra meines Vaters. Zum Teil leistungsfähiger. 😊

Es wird kein Treiber, keine Kext benötigt. Sehr wohl eine aufs genutzte System angepasste SSDT. Diese ist notwendig und bei entsprechenden Macs original in deren ACPI enthalten, also völlig normal.
Darüber hinaus ist grundsätzliche Thunderbolt-Fähigkeit, übers BIOS bereitgestellt und mit korrekten Einstellungen versehen, wichtig. In einem MacPro 5.1 läuft diese dann auch aus gegebenen Gründen nur eingeschränkt, schon allein, weil dieser nicht einmal PCIe 3.0, sondern geringer beisteuert. Um diesen eine SSDT „unterzuschieben“, muss dazu OpenCore genutzt werden.

Festplatte wird nicht erkannt - ist leider sehr unspezifisch. Ist es eine Thunderbolt-Festplatte oder eine USB-C Festplatte? Beide benutzen den gleichen Stecker, sind aber technisch grundverschieden. Beides ist mit der Karte möglich, aber ebenfalls völlig unterschiedlich voneinander realisiert und muss nicht sofort autark laufen. Hotplug ist nur mit korrekter SSDT möglich.

Zusammengefasst: dein Thunderboltcontroller wird im Systembericht angezeigt und scheint somit grundsätzlich zu funktionieren. Ohne SSDT ist kein Hotplug mit Thunderbolt möglich, sehr wohl funktionieren bereits vor Systemstart angeschlossene Thunderbolt-Geräte. Wird hingegen eine USB-C Festplatte angeschlossen, so wird diese nicht angezeigt, weil der ebenfalls auf der Karte vorhandene USB-Controller noch nicht korrekt eingebunden ist. All das hat vielfältige, komplexe Gründe.

Das hat auch Firmen, die glaubten sich an freie Arbeit von wenigen Enthusiasten bereichern zu können und Controller von zum Beispiel Gigabyte mit einer modifizierten Firmware zu flashen, erkennen lassen, dass das eben nicht reicht. Es war wesentlich komplexer und in bestimmten Konstellationen lief das reibungslos wie beim Original.

Zitat von karacho

Vor allem mit den Plugins. Echt der Hammer. Allein schon, dass man damit für Linux-Distro's persistence Dateien erstellen und diese dann für die jeweilige *.iso Datei zuordnen kann, und man dann beim Start einer Distro gefragt wird, ob man mit oder ohne persistence booten will... Auch für Windows gibt es diverse Einstellungen im Plugin-Webinterface bezüglich TPM und CPU wie bei Rufus.

Ich freue mich, das ich auch mal sagen kann: Ich verstehe nur Bahnhof. 😂

„Da ich schon seit einiger Zeit eine leistungsstarke Workstation benötige, war ich angenehm überrascht, die auf den chinesischen x59-, x79- und x99-Chipsätzen basierenden Boards zu entdecken.“

Damit bist du mehr als ein Jahrzehnt zu spät. Ist doch völlig aus der Zeit gefallen. Da ist absolut nichts leistungsstark daran, außer der Energieaufnahme. Zu Zeiten, als es mal aktuell war, war es auch schon keine gute Idee, ein chinesisches Mainboard zu nutzen.

Deine schon vorhandene SSDT ist völlig in Ordnung, du benötigst nicht noch eine. Schon gar nicht „dazu“, sondern entweder die eine oder andere.

Dein Problem ist auch nicht Thunderbolt, sondern USB. In deinem Fall konkret USB2 via USB-C. So ist das Rode-Dingens angeschlossen. Und zumindest der USB2-Anteil deiner Schnittstelle scheint nicht aktiv zu sein. Oft ein durchgeleiteter „Companion“ vom XHC(I). Möglicherweise dort via USB Mapping Kext deaktiviert.

Zitat von Mieze

Hingegen bekommst Du Probleme, falls du einen HS-Port, der keinen SS-Partner hat, als 0x03 definierst.

Völlig richtig, ich schrieb nichts anderes.

Zitat von Mieze

Im Übrigen dürftest Du nur dann ohne Kext klarkommen, wenn die ACPI-Strukturen fehlerfrei sind

Schrieb ich ebenfalls, "korrekt" ist doch nicht misszuverstehen. Was beweist, das sich macOS drum "schert". Sei es drum, auch schrieb ich, dass sich heute kaum jemand damit auseinandersetzen möchte (*), es geht ja mit einer Kext. Ich hatte lediglich darauf hingewiesen, dass zusammengehörende Paare von HS/SS gleich deklariert werden, wie man in jeder zugehörigen SSDT sehen kann, unabhängig davon, ob von Mainboardherstellern für eigentlich andere Systeme vorgesehen, oder Apple, weil diese nun nach Standard vorgehen. Wenn man es aus "Gründen" anders machen möchte, bitte schön. Aber nicht als Standard verkaufen, "muss immer so gemacht werden".

*mögliche "fehlerhafte" SSDT zu fixen, weil macOS deren zum Teil komplexen Konstrukte um _UPC/_PLD nicht verstehen mag, weil viele Variablen mit eingebaut sind, die zum Teil aus dem BIOS ausgelesen werden müssen, je nach Stand, welche Ports dort als aktiv definiert sind, sowie diese ACPI ohnehin nicht für exakt ein Board sind, sondern oftmals alle Boards einer Klasse vom Hersteller mit unterschiedlichster Bestückung von USB-Ports. Kann man fixen und direkt deklarieren und ja, 15 Port-Limit sagt mir auch etwas.

Zitat von Mieze

Was diese beiden Methoden zurückliefern ist entscheidend dafür, ob macOS den Port überhaupt erkennt, aber ansonsten schert sich macOS herzlich wenig um diese Werte, insbesondere nicht, ob der Port hier als intern oder extern markiert ist.

Selbstverständlich "schert" sich macOS darum. Wenn korrekt definiert, bedarf es keiner Kext.

Zitat von Mieze

Der Begriff "Connector Type" ist auf den ersten Blick etwas verwirrend, da SS-Ports immer mit einem HS-Port kombiniert sind, mag man spontan versucht sein den HS-Port auch als 0x03 zu definieren, denn es ist ja die gleiche Buchse.

Und in diesem Fall auch korrekt, nichts ist daran verwirrend. Lediglich alleinige HSxx werden als 0x00 oder 0xFF, oder Sonderfall, USB-C mit alleinigen USB2 – gibts ne eigene Bezeichnung für, fällt mir gerade nicht ein (Edit: glaube 0x08), kann die nicht alle herbeten.

Ebenfalls bei USB-C mit USB3 und USB2 (Standard). da werden beide(!), also HighSpeed und SuperSpeed (HSxx und SSxx) als 0x09 oder 0x0A (je nach dem, ob switch vorhanden oder oder exklusive Adressleitungen, bezogen auf Verdrehen des Steckers). Niemand kommt da auf die Idee, den USB2-Anteil als 0x00 zu deklarieren. Schau dir dazu Apples eigene(!) DSDT/SSDT an. Ich habe da Beispiele von iMac Pro und Mac Pro Intel, das denke ich mir doch nicht aus. Machen das also Apple und die gesamte PC-Branche falsch, sollte Apple mal hier bei einigen im Forum nachfragen, wie man es richtig macht?

Es spielt insofern eine Rolle, als das es korrekt, idealerweise schon vom Hersteller, deklariert werden kann. Wie geschrieben, in der ACPI festgelegt, in der Dokumentation mit Beispielen durchexerziert. Was macOS aktuell mit diesen Standards macht, weiß ich in der Tat nicht. Kann mich aber sehr genau daran erinnern, dass das mal eine Rolle spielte. Explizit nur interne USB2 Hubs. Auch die selbst waren als intern deklariert. Zumindest hat man gesehen, das daran (am Hub) verschiedene Treiber hingen. Bei internen ein anderer, unter macOS. Diese Unterteilung gab es wie gesagt nur für USB2 Hubs. Bei USB3 war es immer der gleiche.

Wurscht. Wenn du sagst, spielt aktuell keine Rolle mehr, um so besser. Setzt sich ja eh keiner mehr mit der ACPI auseinander. 😀

Ich sprach ja von der Ausnahme der festverdrahteten internen Ports, die noch durch Hubs verteilt sind. Also komplett intern aufm Mobo.
Dafür gibt es direkt Beispiele in der ACPI Spezifikation, wie solche Geräte definiert werden.
Ich bezog mich ja nur auf die Aussage: „weil man Ports an einem Hub nicht als internal definieren kann“.

Was bezogen aufs Beispiel richtig, aber allgemeingültig falsch ist. Die üblichen Tools zum erstellen eine Kext berücksichtigen das nicht, mit SSDT sehr wohl machbar.

Zitat von Mieze

TheSnooze Ja, der BT-Dongle MUSS direkt am USB-Port des Boards hängen, weil man Ports an einem Hub nicht als internal definieren kann.

Bei festverdrahteten internen sehr wohl, ist Teil der ACPI. Auch diese Ports werden per DSDT oder weiterreichende SSDT korrekt definiert.

Zitat von TheSnooze

Spaßeshalber habe ich mal einen Blackmagic RAW Speedtest gemacht. Obwohl ich mir nicht vollends im Detail bewusst bin, was der genau testet, spricht das Ergebnis schon für sich: Die GPU scheint in Ordnung aber die CPU hat ein Ding weg, so wie's aussieht.

Der testet halt, wie gut der Rechner mit BMDs RAW Format zurechtkommt. Ist ein RAW von deren Filmkameras. Also direkt vom Kamerachip abgegriffen unter Umgehung der sonst üblichen Kamera-internen Korrekturen und Wandlungen. Je nach Wahl moderat komprimiert. Hat extrem heftige Datenraten und benötigt Unterstützung von geeigneten Grafikkarten. Und der Rest, interne Geschwindigkeit zu den Datenträgern muss auch passen.
Das dabei eine CPU völlig versagt, ist normal. Die hat üblicherweise bei diesem Vorgang nix zu tun.

Hab jetzt gerade keinen Zugriff auf den Hackintosh. Wie das mit WLAN geht, ist hier aber schon gut erklärt worden, ist ja nicht X299 spezifisch. Wenn Sequoia, dann OCLP Root Patches. Da ist noch einiges in der config.plist einzutragen und auszuklammern, das kann ich jetzt nicht herbeten.

AirDrop: muss am Rechner erlaubt sein, wenn dann vom iPhone geschickt wird, muss es am Mac auch angenommen werden, der Benutzer muss aktiv zustimmen.