und
Ist "vollzitagfähig"
Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenund
Ist "vollzitagfähig"
PJH, das mit dem Namen ist ok, ich wusste ja wer gemeint war
Was dein noch bestehendes Problem angeht, so würde ein Screenshot vielleicht weiterhelfen und auch die Infos, welche ich in meinem letzten Beitrag angefragt hatte.
Da Bluetooth ja „intern“ über den USB-Bus angebunden ist, kann dein Problem auch mit einem falsch/unvollständig konfiguriertem USB-Stack zusammenhängen.
Das ist aber mehr eine Vermutung als das ich dies wissen würde.
Ein Screenshot aus den „Systeminformationen“ wäre toll. Ich habe dir mal die entsprechen Punkte als Grafiken angehängt. Dort siehst du wie es auf meinem originalem MPB ausschaut.
Für mich als Feedback wäre noch interessant, was du denn jetzt genau gemacht hast, die Methode von toleda mit der wireless_bcm94352-110-v4.0.command.zip, oder den Weg von Rehabman mit FakePCIID for BCM94352 gegangen bist ?
Ich würde auch erst einmal mit der internen GPU anfangen und schauen ob sie ausreicht.
Wenn es eine 4160/70 CPU wird, ist dort eine HD4400 eingebaut. Leistungsmäßig reicht die selbst für hohe Ansprüche im Bürobetrieb aus.
Was zu klären wäre, was das endgültige Board an Anschlüssen mitbringt - HDMI/DVI oder gar DP und was für ein Monitor für den Rechner vorgesehen ist.
Wenn es ein iTX-Board wird, wäre auch der einzige PCI-Steckplatz belegt, was ebenfalls dagegen sprechen würde.
Der einzige Grund zum jetzigen Zeitpunkt für eine kleine Nvidia wäre nur die möglicherweise einfachere Installation eines Hacks.
Hallo MacGrummel, danke für die umfassende Antwort, mein Posting war auch nicht als Kritik wegen der Unvollständigkeit deiner Anleitung gedacht.
Der Aufhänger war lediglich, das ich über deinen, von mir zitiertem Satz gestoßen bin und vorher auf der englischsprachigen Seite den Post gelesen hatte.
Mein Beitrag bezieht sich konkret nur auf den Spoilerblock "Bei Clover ..." und dreht sich nur um die Clover-, bzw Clover Configurator spezifischen Einträge
Der bisherige Satz, "das aus unbekannten Gründen irgend etwas vertauscht werden muss", verwirrt mMn mehr als er in einem "Kochrezept" hilft.
Vielleicht macht es den Spoiler deutlicher, wenn dort stehen würde, was man nun genau im Clover Configurator eintragen muss und dies sind nach meinem Stand
- ROM, MLB (in RT Variables)
- und Custom-UUID + Inject System ID (in System Parameters)
Der Eintrag SmUUID aus dem Bereich SMBIOS des CloverConfigurator (welcher die Hardware UUID darstellt) muss NICHT gefüllt werden.
Wäre das so korrekt ausgedrückt ?
Super Idee, Hobbit,
ich werde die geplante Beschreibung meines Builds an deinem Gerüst ausrichten und bald posten (verschiebt sich aufgrund des guten Wetters).
Hier einmal meine subjektiven Erfahrungen mit den drei Bootmöglichkeiten, die ich in der Reihenfolge meiner Hackintosh-Entwicklung aufgelistet habe.
Chameleon (Chimera bzw. Unibeast/Multibeast)
pro
+ der Klassiker, für den viele Anleitungen im englischsprachigen Bereich existieren
+ Trennung zwischen Bootloader und nachgelagerter Installation von Erweiterungen (kext)
contra
- trotz der Möglichkeit kexte im Extras Ordner während des Bootvorgangs einzufügen, fehlt die Möglichkeit von Clover in kexte zu injecten
- für mich daher zu statisch und unflexibel
Ozmosis
pro
+ super für Einsteiger, die "nur" mit OS X arbeiten wollen!
+ toller Support hier im Forum
contra
- mMn nur für Gigabyte Boards optimal einsetzbar.
- problematisch, sofern der freie Speicher im BIOS nicht ausreicht um alle kexte unterzubringen. Dann brauche ich doch den Extras Ordner mit den Einschränkungen die Chameleon hat.
- Abhängigkeit von externer Seite zB bei BIOS- oder Ozmosis-Updates, da die Einfachheit natürlich auch mit sich bringt, das der Enduser sich mit den Hintergründen des System nicht beschäftigen kann/will.
Clover
pro
+ extrem mächtig und flexibel
+ kann eigenständig Optimierungen vornehmen, zB bei der Wahl einer Systemdefinition oder dem Ersetzen von PCIids
+ kann in kexte injecten, dh. es besteht bei nicht zu exotischen Builds die Möglichkeit, S/L/E komplett unangetastet zu lassen.
+ kann den Kernel on-the-fly patchen, so dass idR kein custom Kernel erstellt und gepflegt werden muss.
+ kann die ACPI-tables patchen, was ansonsten per DSDT oder SSDT statisch erfolgen müsste. (Wobei Letzteres in Maßen vorzuziehen ist)
contra
- sehr mächtiges, aber mMn auch ein sehr selbstständig agierendes System, welches das troubleshooting schwerer macht, da zB ein erneuter Reboot den Unterschied zwischen KP oder Systemstart ausmachen kann.
- auf den ersten Blick verwirrend viele Optionen, die einen in der falschen Kombination zum Wahnsinn treiben können.
- Notwendigkeit sich tiefer damit zu beschäftigen, wie ein PC zum Mac werden kann.
- benötigt Planung, welche der oben beschriebenen Features genutzt werden sollen (oder nicht) - hier gilt weniger ist mehr.
Mein Fazit
Für den Anfänger Ozmosis, für den Fortgeschrittenen Clover, Chameleon als „Old-school“ Alternative
Clover ist hier ganz klar mein Favorit, WENN man geplant vorgeht.
So sollte mMn die Bereiche DSDT, SSDT und Systemdefinition statisch gehandhabt werden, die Bereiche kext-injection mittels Hilfe von Zusätzen wie FakePCIid oder audio_CloverALC durch Clover. Danach bleiben dann nicht mehr viele „Optionen“ übrig, die in Clover eingetragen werden müssen und Clovers „Eigenintelligenz“ ist etwas gebändigt …
MacGrummel
Bei meinen aktuellen Recherchen zu Clover bin ich vielleicht auf die Antwort auf deinen Satz in deiner Anleitung gestoßen.
ZitatSmUUID und Custom-UUID müssen aus irgend einem Grund hier aber vertauscht eingetragen werden
Google bitte einmal "Clover v.2 Instructions". Im post #23 "iCloud fix" ist der Grund für die Vertauschung aus meiner Sicht erklärt.
Wenn ich es richtig lese, wird aus der Custom-UUID die Hardware UUID errechnet und muss nicht mehr explizit angegeben werden.
Dies deckt sich mit meiner aktuellen Konfiguration bei der nur ROM, MLB und Custom-UUID (incl. Inject System ID) benötigt werden, die Hardware UUID bzw. SmUUID dagegen leer ist, sie aber trotzdem in der Hardwareübersicht und iMessage Debug auftaucht.
Dies wäre dann insofern interessant, da dann eine neue Systemdefinition nicht zu Problemen mit iMessage führen dürfte.
In meinem konkreten Fall hatte ich vorher gar nichts im Bereich SMBIOS angegeben.
Clover hat für mich daher die Systemdefinition Macmini6,2 beim Booten festgelegt.
Nachdem ich eine externe GPU eingebaut hatte wurde daraus plötzlich ein iMac13,1.
Da ich aber verhindern wollte, dass mir Clover meine Systemdefinition mit jeder Hardwareänderung verändert, habe ich im SMBIOS explizit iMac13,1 ausgewählt. Dabei wurde natürlich keine SmUUID angelegt, trotzdem blieb die Hardware UUID gleich.
Spricht also dafür, das es sich verhält wie im posting von slice erwähnt ... oder liege ich falsch ?
Moin jaques, gut zu hören, das du was passendes gefunden hast, ich bin bei der gleichen GPU gelandet.
Ich habe meine ersten Erfahrungen hier gepostet, vielleicht gibt dir das einen Anhaltspunkt was Lautstärke/Stromverbrauch angeht.
Bei mir ist es zwar eine EVGA mit 4GB geworden, aber dein Preis ist schon unschlagbar ...
Dein Gehäuse ist ein echt schönes Teil, dagegen wirkt mein Bitfenix Prodigy geradezu riesig.
Die Bauform und die Größe des Netzteils stelle ich mir aber auch einschränkend vor, eine GTX 980 zusammen mit einem i7 4770k wird das wohl zusammen nicht aushalten, die GTX 960 aber wahrscheinlich schon, oder ?
Auf der Website des Gehäuseherstellers sieht man auch ein Setup mit Wakü, passt denn deine Noctua da rein ?
Dazu ein Tipp zum Mainboard - achte beim Kauf darauf, das der Abstand vom Prozessorsockel zum PCIe-Slot groß genug ist um den Kühler auch korrekt eingebaut zu bekommen - bei meinem Asrock ist das genau nicht der Fall, so dass ich ihn quer einbauen musste. Bei meiner CPU ist der Kühler aber Nebensache, bei deinem aber nicht.
Ausserdem würde ich noch berücksichtigen, ob dir hier für dein Board ein Ozmosis-Bios gebaut werden kann, der alle wichtigen Teile noch im BIOS unterbringen kann. Bei dem Wifi-Board wirst du wahrscheinlich eine neue Mini-Pci-karte brauchen, die kompatibel ist, von daher wäre das noch einzuplanen, oder gleich wegzulassen.
Gerne, ich bin heute in "Dokumentierlaune", ausserdem sehe ich es genau wie Trainer.
Speziell die gehäuften Clover-Fragen und die Möglichkeiten, die sich für NICHT-Gigabyte-Board User ergeben, wollte ich mal befriedigen.
Ich plane heute noch einen "Clover-troubleshooting" Artikel und einen speziell zu meinem Build, der dann alles zusammenbringt und vielleicht als Startpunkt (vielleicht sogar Blaupause) für ähnliche Projekte dienen kann.
Dies ist eine deutsche kommentierte Anleitung, in der ich versuche, das sehr gute aber englische Original [Google "RehabMan OS-X-Fake-PCI-ID“] zu erläutern.
A. Kurzanleitung (ohne Erläuterung)
- EFI mounten
- neueste RehabMan-FakePCIID-XXX.zip (Google "RehabMan OS-X-Fake-PCI-ID bitbucket“) downloaden/entpacken
- FakePCIID.kext und die gewünschten kexts in /EFI/kexts/10.XX legen
- config.plist um CPU,LAN,USB spezifische Einstellungen bereinigen
- gepatchte kexts in S/L/E durch Originale ersetzen (zB. IONetworkingFamily.kext)
- reboot
- Überprüfen ob es geklappt hat und freuen …
B. Langanleitung
Ich habe versucht hier möglichst "feinschrittig" vorzugehen und auch möglichst viel zu erklären, daher ist die Anleitung umfangreicher geworden ...
Bitte GANZ durchlesen, da sich dadurch die meisten Fragen schon von alleine lösen …
Was macht das FakePCIID.kext im Einzelnen ?
Das Script erweitert die Funktion von Clover, während des Bootvorgangs
1. neue kexte einzubinden (idR in EFI/CLOVER/kexts/10.XX auf der EFI Partition) UND
2. Bereiche in originalen kexte(n) in S/L/E zu ersetzen.
Während man ansonsten nur das Eine oder das Andere nutzt, kombiniert FakePCIID.kext beide Varianten.
FakePCIID.kext ist dabei das „Hauptprogramm“ welches alleine nichts bewirkt, sondern erst in Verbindung mit den weiteren kexts im Paket die Arbeit erledigt.
Dies sind im zZ dieses Posts
a. Patches um LAN und WLAN Adapter im System lauffähig zu machen (die Namen sind selbsterklärend)
- FakePCIID_AR9280_as_AR946x.kext
- FakePCIID_Intel_GbX.kext
- FakePCIID_BCM57XX_as_BCM57765.kext
- FakePCIID_BCM94352Z_as_BCM94360CS2.kext [Randbemerkung hierfür kann man auch (Google "toleda wireless_half-mini“ versuchen - dies aber nicht in Kombi mit dieser Anleitung !]
b. Prozessorensignaturen oder Intel HDMI Sound einzupflegen
- FakePCIID_HD4600_HD4400.kext
- FakePCIID_Intel_HDMI_Audio.kext
c. USB2 über USB3 Ports zu ermöglichen
- FakePCIID_XHCIMux.kext
Genaueres ist bitte der Originalanleitung zu entnehmen, die aber recht technisch ist …
Durch die FakePCIID.kext werden die gewünschten Bereiche beim Bootvorgang automatisch gepatched OHNE die Originale in S/L/E dauerhaft zu verändern, so dass idR auch NACH minor-Systemupdates (10.10.3 -> 10.10.4) keinerlei Anpassung mehr nötig wird.
Dies ist DER Riesenvorteil gegenüber den herkömmlichen Methoden!
Speziell in meinem Fall gab es für die BCM57781 einfach keine lauffähige kext …und ich habe sie ALLE! ausprobiert…
Ausserdem war ich es leid bei jedem Systemupdate von Apple alles von vorne anpassen zu müssen und darauf zu achten, das meine interne Karte auch wieder als intern und en0 erkannt wurde …
Hierdurch, durch eine konservative DSDT und SSDT und den toleda Soundpatch kommt mein System jetzt komplett ohne Eingriffe in S/L/E aus und die Optionen in der config.plist sind minimiert worden.
Grundlagen (Voraussetzungen)
- installiertes Clover (im Bsp r3241) und ergänzend Clover Configurator (im Bsp 4.23.0)
- neueste RehabMan-FakePCIID-XXX.zip (Google "RehabMan OS-X-Fake-PCI-ID bitbucket“)
- Bereinigung der config.plist um nicht benötigte Optimierungen (dies ist knifflige Teil, wo man behutsam vorgehen sollte).
- Originale Apple kexte in S/L/E
Installation
- man entpackt das ZIP idR in ~/Downloads
- bevor man das Script nun ausführt, MUSS! die EFI gemountet werden, idR geht dies am Einfachsten via Clover Configurator via Tools/Mount EFI
-- hier zuerst (Check Partition) ausführen und die gewünschte Partition raussuchen (sofern mehrere Disks oder USB-Sticks im System vorhanden sind)
-- danach mit (Mount EFI Partition) die gewünschte Partition einbinden und im Finder überprüfen, ob sie auch angezeigt wird.
Abhängig davon, wie sicher man gehen möchte, empfiehlt sich das Ausprobieren vom USB-Stick oder direkt vom Systemlaufwerk.
[Randbemerkung - Um sich einen kompletten Clover-Installationstick zu erstellen, benutzt man am elegantesten [Google „Clover_v2.3k_Special Edition“] - dieser kombiniert das Erstellen eines OS X Bootsticks mit der Installation und Konfiguration von Clover]
In jedem Fall würde ich iterativ vorgehen, sprich ein Patch nach dem Anderen und jeweiligem Reboot.
Nach einem Reboot überprüft man in
-Apple/Über diesen Mac/Systembericht ob der Prozessor korrekt erkannt wurde
-- in Hardware/LAN bzw Netzwerk/WLAN, ob die Karte korrekt erkannt wurde und ob das Lan auch als EN0 UND INTERN erkannt wurde
-- in Netzwerk ob alles da ist.
Dann ist alles in Butter und wir machen ne
C. Troubleshooting
Sollte mal etwas schief laufen und man zu viel auf einmal gewollt haben, so kann man im Bootmenü von Clover unter (Optionen) auch händisch Einstellungen der config.plist (NUR für den diesen Bootvorgang) setzen oder entfernen.
Ich dokumentiere dies genauer in einem extra Thema und verlinke es hier sobald es fertig ist.
Darüber hinaus müsstet ihr einen Thread aufmachen, der sich auf diese Anleitung bezieht und folgendes enthält
0. Eine vollständige Signatur eures Systems (Ist immer gut)
1. Screenshots von Apple/Über diesen Mac/Systembericht (speziell Hardware, Hardware/LAN bzw. Netzwerk/WLAN)
2. Screenshot eures EFI-Ordners (speziell EFI/CLOVER/kexts/10.XX)
3. Eurer config.plist
1-3 natürlich vor dem reboot anfertigen und extern speichern …
... UND bitte jetzt erst mit dem Durchführen beginnen
Dies ist eine deutsche kommentierte Anleitung, welches das sehr gute aber englische Original https://github.com/toleda/audio_CloverALC ergänzt und um ein Bsp. erweitert.
A. Kurzanleitung (ohne Erläuterung)
- EFI mounten
- rootless=0 und CSRActiveConfig = 0x3 oder 0x67 in der config.plist einstellen.
- audio_cloverALC-110.command downloaden/entpacken/ausführen (bei Fehlern bitte Bereiche C und D bemühen)
- reboot
- Überprüfen ob es geklappt hat
- 
B. Langanleitung
Ich habe versucht hier möglichst "feinschrittig" vorzugehen und auch möglichst viel zu erklären, daher ist die Anleitung sehr umfangreich geworden ...
Bitte erst GANZ durchlesen, da sich dadurch die meisten Fragen schon von alleine lösen ... anders als bei einer Mathearbeit in der Schule ;-), wo das keiner macht ...
Was macht das Script im Einzelnen ?
Das Script bedient sich der Funktion von Clover, während des Bootvorgangs
1. neue kexte einzubinden (idR in EFI/CLOVER/kexts/10.XX auf der EFI Partition) UND
2. Bereiche in originalen kexte(n) in S/L/E zu ersetzen.
Während man ansonsten nur das Eine oder das Andere nutzt, kombiniert dieses Script beide Varianten.
Es erzeugt nach erfolgreichem Durchlauf
1. eine realtekALC.kext in EFI/CLOVER/kexts/10.XX
2. fügt mehrere Abschnitte in der config.plist im Abschnitt <key>KextsToPatch</key> hinzu
3. setzt folgende Parameter in config.plist
/Devices/Audio/Inject/1
/Boot/Arguments/kext-dev-mode=1
/SystemParameters/InjectKexts/YES
4. Lädt eine originale AppleHDA.kext und die realtekALC.kext
Danach wird die Soundkarte direkt vom System erkannt UND bleibt dies idR auch NACH minor-Systemupdates (10.10.3 -> 10.10.4).
Dies ist DER Riesenvorteil gegenüber den herkömmlichen Methoden!
Grundlagen (Voraussetzungen)
- installiertes Clover (im Bsp r3241) und ergänzend Clover Configurator (im Bsp 4.23.0)
- audio_cloverALC-110.command (Google "toleda audio_CloverALC")
- und natürlich einen onboard Soundchip, welcher auch gepatched werden kann (Originalanleitung unter B.)
- rootless=0 und CSRActiveConfig = 0x3 oder 0x67.
rootless=0 ist seit 10.11 ohne Funktion wird aber vom Script geprüft, CSRActiveConfig ermöglicht dem Script ab 10.11 unsignierte Kexte in S/L/E (und noch einiges mehr) zu schreiben.
Installation
Wie in Abschnitt C.1. der Originalanleitung beschrieben
- entpackt man das Script idR in ~/Downloads
- bevor man das Script nun ausführt, MUSS! die EFI gemountet werden, idR geht dies am Einfachsten via Clover Configurator via Tools/Mount EFI
-- hier zuerst (Check Partition) ausführen und die gewünschte Partition raussuchen (sofern mehrere Disks oder USb-Sticks im System vorhanden sind)
-- danach mit (Mount EFI Partition) die gewünschte Partition einbinden und im Finder überprüfen, ob sie auch angezeigt wird.
- führt man das Script audio_cloverALC-XXX.command durch Doppelklick aus und gibt sein Passwort ein.
- Das Script fragt dann die einzelnen Paramater ab, bzw. belegt diese idR schon korrekt vor.
ABWEICHEND von Abschnitt C 1.iv ff. (welcher noch die alte Scriptversion 1.0.4 wiedergibt) sieht dies im meinem Fall so aus ...
Confirm Realtek ALC898 (y/n): y (siehe Abschnitt B.1 der Originalanleitung, dies sollte aber idR passen)
Enable HD4600 HDMI audio (y/n): n (in meinem Fall nein, ansonsten auf y belassen)
Clover Audio ID Injection (y/n): y (ja klar)
Use Audio ID: 1 (y/n): y (siehe Abschnitt B.2 der Originalanleitung, dies sollte aber idR passen)
Dies ist die Ausgabe in meinem System, in der man auch erkennen kann, was genau alles passiert ist.
Nach einem Reboot überprüft man in
Apple/Über diesen Mac/Systembericht in Hardware/Audio bzw PCI, ob der Audio Controller korrekt erkannt wurde
und konfiguriert in
Apple/Systemeinstellungen/Ton/Ausgabe das man einen "Internen Lautsprecher" neben den anderen möglichen Geräten hat.
Dann ist alles in Butter und wir machen ne 
C. Troubleshooting
Macht dazu doch bitte einen neues Thema auf, welches sich auf diese Anleitung bezieht und folgendes enthält
0. Eine vollständige Signatur eures Systems (Ist immer gut)
1. der Terminalausgabe des obigen Scriptes (bitte vor dem Reboot EXTERN speichern)
2. Screenshots von Apple/Über diesen Mac/Systembericht (speziell Hardware/Audio UND Hardware/PCI)
3. Screenshot eures EFI-Ordners (speziell EFI/CLOVER/kexts/10.XX)
4. optional der config.plist
... UND BITTE erst mit dem Durchführen beginnen, wenn es keine Fragen mehr gibt
D. FAQ
F: Ich bekomme folgende Fehlermeldung (Error: no IOReg/HDEF; BIOS/audio/disabled or ACPI problem)
A: Dies bedeuted, das entweder die Soundkarte im BIOS disabled oder die DeviceID der Soundkarte (noch) nicht bekannt ist.
Im ersten Fall muss die Soundkarte im BIOS aktiviert werden, im Zweiten in der clover config.plist (manuell der Eintrag ACPI/DSDT/Fixes/FixHDA_8000 auf true) oder via CloverConfigurator in der Section ACPI/FixHDA gesetzt werden.
F: Das Script bricht ab, da bestimmte Vorraussetzungen nicht erfüllt sind.
A: rootless=0 und CSRActiveConfig = 0x3 oder 0x67 in config.plist eintragen.
rootless=0 ist seit 10.11 ohne Funktion wird aber vom Script geprüft, CSRActiveConfig ermöglicht dem Script ab 10.11 unsignierte Kexte in S/L/E und noch mehr zu schreiben. Anschließenden Reboot nicht vergessen
Edit 26.10.15 - jetzt mit direktem Link...
Edit 27.10.15 - Erweiterung um rootless/SIP(CSR) und FAQ
Moin, nein das "on-the-fly" patching ist nicht kompliziert, sondern bietet große Vorteile, da es eben nicht in S/L/E Apple Kexte ersetzt, sondern während des bootens Teile der Kette so verändert, das sie hinterher eben die Definitionen enthält, die zu deiner Device passen.
Dies ist eine der "Funktionen" von Clover, die über einen reinen Bootloader weit hinausgehen.
Vielleicht postet du einmal genau, was du bis zum Einbinden der WLAN-Karte alles in Clover konfiguriert hast.
Vorher EFI_Partition zB über Clover-Configurator einbinden
0. Hast du Clover mit der Option "Install for UEFI booting only" oder "Installiere Clover in der ESP" installiert ?
1. Einstellungen in der config.plist
2. hast du eine DSDT und/ODER SSDT in CLOVER/ACPI/patched ?
3. Welche Treiber hast du in "Drivers64UEFI", bzw. "drivers64" eingebunden
4. Welche Einträge stehen bei dir in CLOVER/kexts/10.10 ?
Ich füge dir einmal einen Screenshot meines Systems ein, damit du besser siehst wo sich das alles befindet.
Des Weiteren müsstest du einmal beschreiben, was du den von dem von mir geposteten Anweisungen auf der Toledo Seite ausgeführt hast und was das Ergebnis im Terminalfenster oder in der EFI Struktur/config.plist ergeben hat.
Danach kommen wir weiter, ansonsten eher nicht.
EDit:
Alternativ zur "on-the-fly" Methode, hast du das schon versucht ?
ok, Lebenszeichen der Karte sind ja schon einmal positiv.
Was bei der Sache wichtig ist, gerade wenn du mit Clover arbeitest, ist
Entweder
1. gepatchte Kexte in S/L/E unterzubringen
Oder
2. das on-the-fly patching von Clover zu nutzen.
Nicht Beides mischen, da 2. darauf aufsetzt, das es einen "vanilla" kext in S/L/E gibt, in das Clover dann injizieren kann.
Die Script von toleda sind eigentlich super simpel zu benutzen, ich selber nutze es um meine Soundkarte durch Clover patchen zu lassen.
Wenn man einmal das Prinzip verstanden hat, wird klarer, warum man nicht mixen soll.
Am Bsp. der Soundkarte beschrieben (dein WLAN-patch müsste ähnlich durchgeführt werden)
- Mounten der EFi-Partition
- Aufrufen des Scripts und Beantworten der Fragen
- Nach Abschluss des Scripts kann in EFI/Clover/kexts/10.X eine neu kext liegen
und/oder in der config.plist ein/zwei Einträge im Bereich "KextsToPatch" hinzugekommen sein.
Das wars dann, auf diese Art überlebt man auch Systemupdates und es ist viel robuster als direkt in S/L/E rumzufummeln.
Wenn ich nach deiner Karte google, dann springt mich die Seite von Toleda "toleda/wireless_half-mini" direkt an.
Ich habe mir die Beschreibung nur kurz durchgelesen, in diesem Abschnitt ist eigentlich alles beschrieben.
Vielleicht wäre es ein Versuch es damit zu probieren ?
Ihr habt beide recht .... nur war das ja auch nicht mein Anliegen
Meine derzeitiges System kann jetzt schon (W)QHD sprich 2560x1440@60Hz via DP + 1920x1080 via DVI oder HDMI ansteuern.
Da aber die Anschaffung eines HD-Monitors eher ein Rückschritt wäre, möchte ist ein/zwei WEITERE WQHD oder 4K Displays anschließen, jeweils mit 60Hz.
Dazu war die Alternativenbewertung gedacht.
Unter Windows wäre das alles deutlich einfacher, da man dort via MST auch zwei WQHD Displays via daisy-chain ansprechen kann, sofern Monitor/Graka DP 1.2 unterstützen.
Dies wäre unter Windows mit Variante 2 so möglich, mit OS X aber nicht - zumindest ist das mein jetziger Stand.
OS X sieht MST von Haus aus nicht vor, da DP ja über Thunderbolt läuft (und dort nur ein Display pro Bus erlaubt ist).
Von daher bleibt nur der Weg mit mehreren DP oder HDMI 2.0 Ports mit zB einer GTX 970.
Oder sehe ich da etwas falsch ?
Edit 2015-07-24
Da die Frage entweder zu speziell, oder trivial war, habe ich die letzten Tage einen Selbstversuch unternommen
Das Ergebnis ... es funktioniert wie von mir gewünscht, allerdings war es natürlich nicht mit Einbau und Installation der Webdriver getan ...
Ich habe mir vorgenommen hierzu noch einen extra Beitrag zu verfassen, daher hier nur etwas über die Gründe und Besonderheiten der von mir ausgewählten Teile.
Ich wollte ja NUR meine Bildschirmfläche vergrößern und bin daher bei einem Dell P2715Q 4K Monitor und einer EVGA GTX 960 gelandet.
Die Grafikkarte habe ich ausgewählt, da sie 3 über DP Anschlüsse verfügt, man also auch drei 4K Monitore betreiben könnte.
Da ich KEINE hohe Grafikleistung für Spiele brauchte, konnte ich gegenüber einer GTX 970 rund 100€ einsparen.
Diese Summe ist dann in den 4K Monitor geflossen, den ich dem 1440p-Nachfolger meines U2713HM vorgezogen habe.
Für die alltägliche Arbeit läuft der Monitor trotzdem nur auf den für 27 Zoll optimalen 1440p, welches KEINERLEI Einschränkung der Bildschärfe gegenüber meinem U2713HM erkennen lässt. Hier leistet OSX wirklich Erstaunliches in der Skalierung ...
Sollte ich einmal mehr "Fläche" benötigen, so kann ich aber auf 3008x1692 oder 3840x2160 umschalten.
Die Grafikkarte verbraucht im Bürobetrieb ca 20 Watt und arbeitet dabei unhörbar. Die Lüfter schalten sich erst ab 60 Grad überhaupt erst an und regeln sich dann schon fast wieder ab.
Probleme gab nur dadurch, das ich ein bestehendes optimiertes System so abändern musste, das hinterher wieder alles passte.
So wurde aus einem MacMini 6,2 ein iMac 13,1 (Facetime/iMessage hat es überlebt!), die DSDT musste um den HD4000 Ballast befreit werden und auch die SSDT musste neu generiert werden.
Zudem war das System kurzfristig anfälliger gegen Kernelpanics, so das auch dies in Clover berücksichtigt werden musste und der Punkt NVIDIA Inject brachte zwar die EVGA in der Systemdefinition, aber dafür mit 0MB und nur ein Monitor war ansprechbar. (Letzteres wird bestimmt noch abgefangen, wenn die Clover Leute die richtige Systemdefinition (ähnlich wie für die EVGA 970 GTX) einpflegen).
Dabei habe ich wieder noch mehr über Clover gelernt - das Ding ist mMn im Vergleich zu Ozmosis wie Linux vs OS X -Komfort vs Flexibilität.
Ich hoffe dies hilft Anderen bei der Entscheidung, wenn es darum geht, das Passende auszuwählen.
OK, ich habe das Ganze hier sehr gut erläutert gefunden, scheint ein ansonsten sehr emotionales Thema zu sein...
Hier wird VRAM (Volatile Random Access Memory) und nicht NVRAM (Non-Volatile Random Access Memory) beschrieben, dies nur um Verwirrung vorzubeugen.
Zu deinen Alternativen, die GTX960 hat "nur" eine 128bit Anbindung an das Speicherinterface, somit also deutlich weniger als die 224bit Anbindung der GTX970 für die 3,5GB Speicher, ist in der EVGA Ausführung mit 4GB Speicher aber 100€ günstiger. Test hier.
Der Part der mich interessiert, ist die Anzahl an Monitoren in 1440p oder 4K @60Hz, die angesteuert werden können, ohne das ein Chromasubsampling durchgeführt wird. Da die EVGA GTX960 (04G-P4-3966-KR) das zu schaffen scheint, ist sie momentan mein Favorit.
Da sämtliche Tests die ich finden konnte immer auf Windows basieren und zudem immer Spieltest sind, bleibt die Frage, was einem unter OSX eine GTX 980, bzw 970 mehr bringt als eine 960 ?
Speziell für den Anwendungsbereich Photobearbeitung oder Videoschnitt.
Zusatz - Speziell würde mich interessieren wie CUDA auf mehr Speicher anspricht, sprich ob die 3,5GB limit der 970 überhaupt zum tragen kommt.
Kann dies Jemand (möglicherweise aus eigener Praxis) hier beantworten ?
sn0wleo meinst du die nur teilweise schnelle Anbindung des VRAMs ? Oder was hat es mit dem (N)VRAM auf sich ?
Was funktioniert denn nicht, das Erstellen des USB Sticks oder das booten in Parallels ?
Ich verwende ja Fusion, dort muss man den USB Stick der VM direkt zuordnen (dh. auf nicht Nachfragen stellen ), dann die VM booten und direkt danach den USB-Stick mit der VM verbinden.
Ggf. noch einmal einen Reset der VM, aber dann klappt es bei mir.
Geht das nicht kann man ja auch von Yosemite "Upgraden" ... Bei einem CleanInstall von Yosemite sollte das vertretbar sein ...
Edit
Eine deutlich bessere und elegantere Lösung ohne USB Disk und Image Erstellung beschreibt Dave Parsons, wenn man nach "daveparsons VMware Fusion Guest" googled.
Probiere ich gleich mal aus, ob das auch mit ELCap PB1 funktioniert und poste es dann hier ...
Dave Parsons Artikel sind aber auch so lesenswert, zB wie man die für iMessage benötigten Parameter in Fusion "reinreicht" ...
Edit2
Auch das scheint nicht mehr direkt zu funktionieren, aber wozu weiss Google alles ...
Hier ist der Patch damit das auch mit ElCap durchläuft.
Aber alles nur für Fusion, vielleicht git es ja etwas ähnliches auch für Paralells ...
OESIX
nein da liegst du falsch,das hat sich gerade ab Lion geändert, sprich zu dem Zeitpunkt an dem OSX Server als APP zu installieren und keine eigenständiges Installation mehr ist.
Wenn du nach kb.vmware 2005793 oder 1000131 suchst, findest du die entsprechenden Dokumente in denen definiert ist, unter welchen Umständen OS X virtualisiert werden darf.
Kurz gesagt, laut Apple ist Grundlage hierfür eine Virtualisierung auf Apple Hardware - dies liegt in meinem Falle vor !
Dadurch, das SL als DVD vertrieben wurde, sprich nicht mit einem Mac gebundelt verkauft wurde und alle weiteren Versionen von OSX nur Updates von SL sind, ergibt sich durch eine rechtliche Besonderheit in Deutschland die Legitimation, diese DVD auch auf Fremdhardware einzusetzen.
Die Besonderheit ist, dass die Softwarevereinbarung, die einen Betrieb nur auf Macs vorsieht erst nach Öffnen der Verpackung (also nach dem Kauf) für den Kunden ersichtlich wird und damit unwirksam ist. Solange Apple dies juristisch nicht klären lässt, gilt dies wohl so.
Daraus kann man natürlich auch die Ungültigkeit der Virtualisierung auf NUR Apple-Hardware ableiten, usw...
UND das ist auch der Grund, warum von Jedem, der sich einen Hackintosh bauen möchte, erwartet wird, diese DVD zu erwerben.
Dies ist zumindest die Erläuterung, welche ich bislang gehört habe. Ich will damit bitte auch keine Diskussion starten ...
Moin, ich kann dir nur indirekt weiterhelfen, da ich genau den gleichen Effekt bei VMWare Fusion beobachte.
Das Script, welches mir ein bootfähiges ISO-Image für Yosemite erzeugt, funktioniert bei El Capitan nicht, zumindest bootfähig ist es nicht.
Ich habe mir damit beholfen, einen USB-Stick via DiskmakerX zu erstellen und diesen dann der VM zuzuweisen... oder eben den normalen Upgradeweg von 10.10.4 zu gehen
Würde mich aber auch sehr interessieren, was sich hier bei El Capitan geändert hat ...
Dies ist das Script, was ich verwendet habe ...