Posts by apfelnico

    Applepaul10

    Es liegt nicht nur am NVMe-Modell. Dein Mainboard hat vier PCIe-Slots und einen M.2. Alle diese entsprechen PCI3 3.0. Deine CPU kann 16 Lanes per PCIe 3.0 bereitstellen und zusätzlich sich per 4 Lanes mit dem Chipsatz (PCH) unterhalten.

    Die vier PCIe Steckplätze sind 1x 16 (Lane), 1x 8, 1x 4 und 1x 1. Die letzten beiden sind mit dem PCH verbunden. Nur die beiden ersten direkt mit der CPU. Normalerweise steckt im ersten Slot eine Grafikkarte, die für sich 16 Lanes beansprucht. Somit ist hier das Limit erreicht. Steckst du hingegen in den zweiten Slot (maximal 8 Lanes) eine Karte (zum Beispiel eine PCIe->NVMe Karte), dann wird automatisch Slot 1 nur noch mit 8 Lanes laufen, womit die Grafikkarte auch gut zurecht kommt, die Einbußen sind recht marginal. Nur hier im Slot 2 kann bei dir eine NVMe zur Bestform laufen.

    Die NVMe benötigt PCIe 3.0 4 Lanes, das bietet auch Slot 3. Nur ist dieser nicht mehr direkt mit der CPU verbunden, sondern mit dem Chipsatz (PCH). Bringt also nix, dann kann sie auch direkt im M.2 Sockel verbleiben. Auch hier wird direkt ein PCIe 3.0 4 Lanes angeboten. Wo ist dann das Problem? Weil am Chipsatz noch der Standard USB-Controller, oftmals weitere USB-Controller (3.1 Gen2), SATA, Soundchip, und Ethernet hängen. All das konkurriert mit deiner NVMe und buhlt um das enge Tor zum Prozessor. Der PCH kann je nach Modell seinerseits bis zu 24 Lanes bereitstellen, ist aber nur mit 4 Lanes mit dem Prozi verbunden. Deine NVMe wird also nie so frei laufen können, wie direkt an der CPU angebunden. Das ist normal …

    Es wird eine andere Klasse aufgerufen, um die zusätzlichen Properties zu injecten. Ähnliches mache ich über eine SSDT. Viele Wege führen nach Rom. Denke aber, du wirst diese Einstellungen schon in einem Device Namens "USBX" festgelegt haben. Der zusätzliche "IONameMatch" zeigt eben auf das Device "XHC". Muss nicht sein, kann auch kontraproduktiv sein, wenn das Device mal nicht so heißt. Klar schaut da "Hackintool" nach, sonst stände es ja nicht drin. Aber gibt man diese Kext weiter, und jemand hat grundsätzlich identische Hardware verbaut, nur sein USB-Controller heißt in der ACPI eben "XHCI", dann wird diese Kext nicht ausgeführt, da der Controller "XHC" nicht vorhanden ist. Der "IOProbeScore" ist dann entscheidend, wenn zwei ähnlich gelagerte Kexte um die Zuständigkeit buhlen. Es wird dann diejenige geladen, deren Score höher ist. Das ist dann wichtig, wenn sonst eine vorhandene Apple-Kext geladen wird, die grundsätzlich und allgemein funktioniert, nur nicht speziell auf die Bedürfnisse angepasst ist. Dann kann man diese "Helper"-Kext (ohne eigenen ausführbaren Code) laden, um mit deren Hilfe und eigenen Anweisungen (zusätzliche Properties) eine daraufhin geeignete Kext anzusprechen. Oder letztendlich auch die, die sonst auch geladen wird, nur eben zuvor die eigene, um dem System mitzuteilen, das es nur diese und jene Ports am Controller gibt (die Aufgabe letztendlich dieser Kext).

    Ich hatte mal den Fall, wartete auf eine extrem wichtige Sendung. Ich sehe am Fenster wie der Postbote vorfährt. Es klingelt, ich drücke den Türöffner. Wohnte damals im dritten Stock zur Miete. Ich renne runter, niemand da. Huch? Schaue raus, kein Postauto mehr. Ich schaue im Briefkasten – der nebenbei bemerkt innen im Treppenhaus angebracht war – da steckte ein Zettel drin. Darauf stand: "Paket konnte nicht zugestellt werden, da die Haustür verschlossen war"!

    Ich weiß nicht, ob das arme Würstchen entlassen wurde, aber ich hatte mächtig stunk gemacht. Der hatte doch tatsächlich diesen Zettel schon vorher ausgefüllt und beim öffnen der Tür direkt in den Briefkasten gesteckt. Und was für eine dämliche Begründung bei einem innenliegenden Briefkasten …

    Der FwRuntimeServices.efi übernimmt die Arbeit der MemoryFixes...

    Einen Teil davon. Der größere Anteil ist direkt in OpenCore gewandert.

    oder OCQuirk?

    Das ist für Clover. Es ersetzt den Teil, der sonst in OpenCore schon integriert ist. Nur die "FwRuntimeServices.efi" reicht in Clover nicht aus. Beides kann als modernere Alternative die sonst dort verwendeten (verschiedenen) AptioMemoryFixes ersetzen.


    https://github.com/acidanthera/AptioFixPkg

    https://github.com/ReddestDream/OcQuirks

    Je nach dem, was sonst noch so am PCH angebunden ist, wird's eh eng. Besser direkt direkt am PCIe-Bus, der mit dem Prozi spricht. Bei einfachen Boards heißt es da natürlich, der Grafikkarte nur noch 8Lanes zu gönnen …


    Auch wenn die NVMe nun nicht maximal performt, ist die effektive Leistung dennoch mehr als ausreichend. Würde da nix dran schrauben …

    Meine USB Ports sind mitels Hackintool (USBPorts.kext und ssdt) konfiguriert. Überschüssige Ports sind deaktiviert, damit ich das Port Limit nicht erreiche. Wie siehts den mit den Ports auf der Titan Ridge aus? Fallen die auch unter das Port Limit?

    Es gilt: maximal 15 Ports je Controller. Heißt also, 15 an XHCI (Standard über PCH (Intel Chipsatz)), weitere über zum Beispiel ASMedia (oft USB3.1(2) Gen1/2) und natürlich auch via TB-Controller.


    Clover config-plist habe ich mir nicht angesehen, habe da jetzt gerade keine Zeit zu. Aber anbei die Ordner "drivers" und "kexts". Ersetze die mal mit deinen vorhandenen. Nix weiter dazu packen, komplett austauschen.

    Files

    • drivers.zip

      (67.45 kB, downloaded 9 times, last: )
    • kexts.zip

      (1.41 MB, downloaded 9 times, last: )

    Sunraid hast Du CSM Aktiv im UEFI? Mir ist aufgefallen das dieser Parameter mit der Thunderbolt Geschichte in Konflikt steht.

    Ich habe CSM teilweise aktiv, für die wichtigsten Sachen nutze ich jedoch UEFI. Diese Einstellungen musste ich nehmen, da sonst mein Rechner nicht mit den bereits eingeschalteten externen Thunderbolt-RAIDs (Pegasus2 R8) hochfahren wollte. Dieser blieb ohne CSM schon während der Anzeige des ASUS-Logos (Boot-Phase) stehen, hatte somit nix mit Hackintosh zu tun, war demzufolge unter Windows auch so. Mit sonstigen Thunderbolt-Gedöns hatte ich diesbezüglich keine Probleme, auch konnte ich NACH hochfahren des Rechners selbstverständlich per HotPlug das RAID anstecken. Aber so geht es halt immer:


    Edit:

    Wenn diese sehr speziellen Probleme nicht auftauchen, spricht nichts dagegen, CSM zu deaktivieren und ausschliesslich UEFI zu fahren. Das ist ja eh die generelle Empfehlung.

    Die Karte taucht unter PCI im Systembericht nur auf, wenn diese per SSDT eingebunden ist. Das die dann dort steht, ist nur Kosmetik, aber man sieht dann, ob die Treiber auch korrekt geladen wurden. Auch tauchen dann dort in PCI weitere Geräte auf, die am Thunderboltbus hängen – auch nicht verkehrt. Und natürlich bringt diese SSDT (die möglicherweise auf die eigenen "Pfade" angepasst werden muss) HotPlug.


    Grundsätzlich funktioniert die Karte aber auch einfach so. Also einstecken, im BIOS alles korrekt einstellen, fertig. Ein "aktivieren" über Windows ist nicht nötig. Was nun schon funktionieren sollte: TB-Gerät bei ausgeschalteten Rechner anschliessen und ggf. einschalten, dann den Rechner starten. In macOS sollte nun das Thunderbolt-Gerät vorhanden sein (mitunter noch Herstellersoftware und Treiber installieren). Nachträgliches Ein/Ausschalten bzw. An/Abstöpseln geht aber nicht und kann unter Umständen den Rechner zum Absturz bringen. Dafür einfach die SSDT integrieren. Dann funktioniert auch das.


    Wenn die Karte erkannt wird, steht unter Systembericht/Thunderbolt nur, dass Treiber geladen sind.

    Eigentlich steht dort das Gegenteil:

    Quote

    Thunderbolt: Es sind keine Treiber geladen.

    Das macht aber nichts. Damit auch diese Treiber wie im Original geladen werden, müsste man ein originale Firmware von Apple auf den Controller flashen. Vielleicht gelingt das ja demnächst … ;)

    Quote from CMMChris

    iMacPro1,1 Board-ID Spoof in einem anderen SMBIOS

    Quote from Achilles31

    … wird man im IMAcPro 1.1 …

    Nein, anderes SMBIOS. Also ungleich iMacPro. Denn im iMacPro gibt es keine IGPU. Aber mit beispielsweise iMac18.3 SMBIOS wird zusätzlich die iMacPro-ID (7BA5B2D9E42DDD94) verwendet inkl. shikivga …

    Man kann sich das einfach machen. Nimm das Programm "Hackintool", gehe auf "Installed" und wähle nach dem alles zur Ruhe gekommen ist, diejenigen Kexte an die du neu kompilieren (lassen) willst. Dann klickst du unten von den drei Symbolen in der Mitte das rechte an (Compile Selected). Nach Abschluss der Prozedur (dauert eine Weile) findest du auf dem Schreibtisch einen neuen Ordner "Hackintool_Build", darin befinden sich im Ordner "Release" deine neuen Kexte.


    Edit:

    Oder gleich hier downloaden :)

    Eigentlich gar nichts aber hier wurde geschlussfolgert, das es wenn es schon kein CUDA mehr gibt auch kein Nvidia Treiber kommt.

    Völlig richtig, das hatte ich auch gegenüber CMMChris geschrieben, das es völlig unterschiedliche paar Schuhe sind. Wobei ein Zugpferd für Nvidia eben CUDA war. Nichts weiter.
    Erschwerend kommt aber hinzu, das trotz neuem modularen MacPro dieser nicht etwa als „BareBoone“ kommt, sondern auch fertig bestückt. Der Absatz dieses prestigeträchtigen Stücks wird wohl auch deutlich unter den anderen Macs liegen, also was bleibt da für Nvidia?

    Ich war damals mit meiner Käsereibe und dicker Nvidia sehr zufrieden, ein furioses Comeback wäre aus verschiedenen Gründen schön, aber ist es wahrscheinlich?

    Du kannst da nichts "reinbasteln". Im besten Fall versteht das OC nicht, im schlimmsten Fall bootet da nix.


    Normalerweise wird der Speicher korrekt erkannt. Wenn du in der config.plist von CLOVER diese Einträge rausnimmst, hast du dann auch diese Anzeige? Dann hast du eher ein Hardwareproblem, das Clover lediglich per Kosmetik "verschleiern" kann.