Der Mac Pro Grafikkarten Thread, ab Mac Pro 1.1 bis 5.1...

Was soll ich da interpretieren jede radeon rx 560 auch eine nicht sapphire würde gehen?

Einige andere Drittanbieter-Grafikkarten*, die auf der folgenden Familie von AMD-Grafikprozessoren basieren, sind möglicherweise in einem Mac Pro (Mitte 2010) oder einem Mac Pro (Mitte 2012) ebenfalls mit macOS Mojave kompatibel:

  • AMD Radeon RX 560
  • AMD Radeon RX 570
  • AMD Radeon RX 580

 
Macschrauber schrieb:
Installiere Windows über die DVD im legacy / bios mode, nicht uefi, sonst gibts Probleme mit Zertifikaten in der Mac Firmware.
Zum Vergrößern anklicken....

Gibt es eine Möglichkeit die Zertifikate die Windows da reinschreibt (einfach) wieder zu entfernen?
 
Ja, solange die Maschine noch startet, kann man ein "blankes" (rekonstruiertes) ROM aufspielen; es sollte idealerweise von dem Board stammen, damit Seriennummer usw. nicht verloren gehen bzw. falsch sind.

Für das Firmwareupdate 4.1 -> 5.1 ist keine spezielle Mac-Karte mit Bootscreen nötig.
 
also starten tut der noch... aber es wurde kein Backup der Firmware gemacht, bevor Windows 10 vom USB Stick installiert wurde...
 
Zuletzt bearbeitet:
Das macht nichts, das kann jederzeit unter OSX/macOS gemacht werden, man muss nur zuerst in die Recovery booten und per Terminal-Befehl SIP deaktivieren (betrifft nur neuere Systeme, ältere OSX haben noch kein SIP).

Und solange Windows nicht mit GPT-Partitionsschema installiert wurde, passiert eh nichts.
 
festplattenmagier schrieb:
Gibt es eine Möglichkeit die Zertifikate die Windows da reinschreibt (einfach) wieder zu entfernen?
Zum Vergrößern anklicken....

Wie Udo schrieb, das Backup, was noch keine Zertifikate enthielt, zurückspielen.

Nvram resets, auch die drei hintereinander, löschen die Zertifikate nicht.

Solange ein Backup da ist (deswegen schreib ich mir ja immer einen Wolf nach dem Backup) kann man auch ein Rom rekonstruieren und so bereinigen.

Auch wenn es zu spät ist und die Firmware nicht mehr läuft. Dann muss eben der Chip raus und extern programmiert werden. Ich erneuer den bei der Gelegenheit wenn er eh draussen ist. Das Flash IC hat eine begrenzte Lebenszeit und da schadet es nicht es zu ersetzen.
 
Macschrauber schrieb:
der mein zweiter Hauptrechner ist
Zum Vergrößern anklicken....
Ist zwar OT aber was bitte schön, soll ein zweiter Hauptrechner sein? Ich weiß ja was ein Hauptrechner ist und was ein Zweitrechner ist aber ein zweiter Hauptrechner? Erscheint mir ähnlich wie ein optimiertes Optimum ;)
 
Wenn man zwei Wohnorte hat, gibt es auch zwei Hauptrechner
 
...laut Finanzamt geht das nich :p
 
Fl0r!an schrieb:
Die FB-Personalities bestimmen ja nicht nur die Port-Konfiguration, sondern haben auch Einfluss auf Power-Management, Multi-Monitor-Setups und ähnliches.
Zum Vergrößern anklicken....
Sorry für das Aufwärmen dieser ein Jahr alten Frage.

Aber könnte nicht ein alternativer Weg zum Aufrufen einer anderen Framebuffer-Presonality per Eintrag im ROM der Karte oder Erzwingen des Default-Framebuffers durch einen „falschen“ Eintrag der sein, einfach in der Info.plist des Treibers den Eintrag der Framebuffer-Personality, von dem man weiß, dass er von der eigenen Karte angesprochen wird, entsprechend einer anderen Personality abzuändern, von der man weiß, dass sie z.B. die Port-Konfiguration hat, die man gerne hätte?

Also, konkretes Beispiel, um den zweiten DVI einer geflashten Radeon HD 7950 zu aktivieren, Hamachi...

<key>ATY,Hamachi</key>
<dict>
<key>aty_config</key>
<dict>
<key>CFG_USE_SM</key>
<true/>
</dict>
</dict>

...abändern, entsprechend Orinoco...

<key>ATY,Orinoco</key>
<dict>
<key>aty_config</key>
<dict>
<key>CFG_NVV</key>
<integer>2</integer>
<key>CFG_USE_CP2</key>
<true/>
<key>CFG_USE_HDMI20</key>
<true/>
</dict>
<key>aty_properties</key>
<dict>
<key>PP_EnableLoadFalconSmcFirmware</key>
<integer>1</integer>
<key>PP_Falcon_QuickTransition_Enable</key>
<integer>1</integer>
</dict>

...zu...

<key>ATY,Hamachi</key>
<dict>
<key>aty_config</key>
<dict>
<key>CFG_NVV</key>
<integer>2</integer>
<key>CFG_USE_CP2</key>
<true/>
<key>CFG_USE_HDMI20</key>
<true/>
</dict>
</dict>

...oder...

<key>ATY,Hamachi</key>
<dict>
<key>aty_config</key>
<dict>
<key>CFG_NVV</key>
<integer>2</integer>
<key>CFG_USE_CP2</key>
<true/>
<key>CFG_USE_HDMI20</key>
<true/>
</dict>
<key>aty_properties</key>
<dict>
<key>PP_EnableLoadFalconSmcFirmware</key>
<integer>1</integer>
<key>PP_Falcon_QuickTransition_Enable</key>
<integer>1</integer>
</dict>
</dict>

...?
 
Die Port-Definition liegt in der Binary des Treibers, nicht in der Info.plist. Aber ja, das geht natürlich, erfordert aber eben eine Modifikation auf dem Dateisystem (samt Wiederholung nach jedem System-Update sowie deaktivieren alle aktuellen Sicherheitsfeatures). Finde es aus dem Grund eher unschön...
 
Fl0r!an schrieb:
Die Port-Definition liegt in der Binary des Treibers, nicht in der Info.plist.
Zum Vergrößern anklicken....
Aber die Info.plist entscheidet doch, welche Port-Definition angesprochen wird, oder?

Klar ist das eine Modifikation des Kexts, die nach jedem Update neu vorgenommen werden muss. Selbstverständlich nachdem man eine Sicherungskopie des unveränderten Kext gezogen hat! Natürlich muss man auch noch (temporär) SIP deaktivieren und die Permissions reparieren, damit das gepatchte Kext läd. Aber demgegenüber steht ja Zerlegen des ROM, Dekomprimieren des EFI, Einträge suchen, Ändern, Rekomprimieren, Zusammenbauen und Flashen. Und das eventuell mehrfach, bis man einen „funktionierenden“ Framebuffer gefunden hat. Erscheint mir vom Aufwand her umständlicher.

Aber grundsätzlich denkst Du, dass es funktionieren könnte?
 
Ne, die Info.plist enthält nur einige zusätzliche Konfigurationseinstellungen, die auf Basis des gewählten Framebuffers aktiv werden. Die eigentliche Port-Definition ist in der zugehörgen Binary.

Wie man das ändert ist z.B. auf den einschlägigen Hackintosh-Seiten dokumentiert. Clover & Co bote/bieten dafür ja auch Methoden, um die Binaries on the fly patchen zu können, d.h. ohne Änderung im Dateisystem.
 
  • Gefällt mir
Reaktionen: flyproductions
Fl0r!an schrieb:
Ne, die Info.plist enthält nur einige zusätzliche Konfigurationseinstellungen, die auf Basis des gewählten Framebuffers aktiv werden. Die eigentliche Port-Definition ist in der zugehörgen Binary.
Zum Vergrößern anklicken....
Gibt es denn irgendwo eine Art „Tabelle“, aus der ersichtlich ist, welche Frambuffer welche Port-Konfiguration auslösen? Oder kann man da „universell“ auf Deine „No Injekt“-Variante setzen, die ja, soweit ich das verstehe, die Port-Konfiguration entsprechend dem erzwingt, was im VBIOS eingetragen ist (was meines Erachtens eigentlich sowieso das Beste wäre).
 
Was spricht gegen den generischen "RadeonFramebuffer"? Da funktionieren alle Ports OOB. Bootscreen könnte man mit Karten der 7xxx-Reihe ja trotzdem haben.

@Fl0r!an, warum wurde der Mechanismus mit den FBs so irrsinnig umständlich umgesetzt? Ich kann da keine Vorteile erkennen, wenn unter OSX die Zuweisung automatisiert erfolgen würde.
 
Udo Martens schrieb:
Was spricht gegen den generischen "RadeonFramebuffer"? Da funktionieren alle Ports OOB. Bootscreen könnte man mit Karten der 7xxx-Reihe ja trotzdem haben.
Zum Vergrößern anklicken....
Nix!

Wenn der sich ohne irgendwelche „schädlichen Nebenwirkungen“ aktivieren lässt, sehe ich darin sogar den Königsweg.

...wobei der, so, wie ich das verstehe, ja gar nicht so „generisch“ ist, sondern einfach nur die Einstellungen da her nimmt, wo sie eigentlich hingehören, nämlich aus dem genau auf die jeweilige Karte zugeschnittenen VBIOS, und nicht von irgendwo sonst.
 
Udo Martens schrieb:
@Fl0r!an, warum wurde der Mechanismus mit den FBs so irrsinnig umständlich umgesetzt? Ich kann da keine Vorteile erkennen, wenn unter OSX die Zuweisung automatisiert erfolgen würde.
Zum Vergrößern anklicken....
Hm, "historisch gewachsen", würde ich sagen. Bis 10.6 war das so, dass OS X keine automatische Konfiguration der GPUs hatte, die wurde eben immer über die Framebuffer Personalities vorgenommen. Das bedeutete auch, dass PC-GPUs nicht nur keinen Bootscreen hatten, sondern eben gar nicht liefen, außer man nutzte zusätzliche Software (ATY_Init).
Mit 10.7 kamen dann erstmal generische Treiber. Man könnte vermuten, dass es den Apple-Entwicklern selbst zu nervig wurde, für jeden Prototyp und jedes Testsystem sowas händisch vorzunehmen. Vielleicht waren sie aber auch einfach nur nett. :) Die hatten anfangs noch Probleme, so gingen z.B. häufiger Multi-Display-Setups auf diesem Wege nicht.

Ist aus meiner Sicht aber alles Geschichte, mit halbwegs aktuellen GPUs funktioniert die generische Variante problemlos. Mit Ausnahme von Grafikkarten, von denen es eine offizielle Mac-Edition (und damit einen hundertprozentig passenden Framebuffer) ist das auch den Weg, den man wählen sollte. Das Problem ist halt, dass die FB-Personalities nicht nur die Port-Definitionen regeln, sondern auch so Sachen wie Powermanagent & Co. Da kann viel Schief gehen.

Keine Ahnung, ob man bei einem echten Mac nicht einfach Lilu & Whatevergreen reinknallen kann und fertig, das wäre recht elegant und wartungsarm.
 
  • Gefällt mir
Reaktionen: flyproductions
Am kuriosesten finde ich, dass es FBs gibt, für die es garkeine Hardware (von Apple selbst) gibt. Zu Evaluierungszwecken Mittel der Wahl, aber im finalen System hat das eigentlich nichts mehr zu suchen ;)

Funktionieren die aktuellen AMD-GPUs denn noch nach dem gleichen Schema, nur mit GOP anstelle UGA?
 
Ich denke schon, aber mein letzter Stand ist etwa aus der Zeit der Polaris-GPUs. Bin etwas raus, glaube mein Mac Pro war vor 'nem Jahr das letzte Mal an...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten