Z490 Vision G - OpenCore 0.7.5 zeigt nur Windows Partition beim Booten

  • 5T33Z0


    Deinen Ärger kann ich nachvollziehen. Meine Frau hat das gleiche Board und auch das i225 Problem.

    Alle meine Versuche waren auch erfolglos. Mehrfach dachte ich ich hätte etwas ernsthaft beschädigt. Auch unter Windows lief das Lan dann nicht mehr. Nach endlosem rumprobieren dann doch wieder.

    Habe jetzt auch eine andere Lan Karte eingebaut um das System Dual Boot mit Windows 11 und Monterey nutzen zu können. Das interne LAN im Bios ausgeschaltet. Natürlich nicht vollständig befriedigend.


    Vielleicht hat Apple ja ein Einsehen und unterstützt es irgendwann wieder. Der 82574L meines alten Quo Boards war auch einige Monterey Betas tot und läuft jetzt wieder, allerdings ist der Durchsatz zum Server geringer als unter BigSur.


    Die Hoffnung stirbt zuletzt.

  • Das Z490 Vision G gegenüber Z590 G ist der Chipsatz und die Anbindung zur nativer Unterstützung der PCIe 4.0 Anbindung vom 11er CPU. Bei der D Reihe kommt noch TB dazu dass komplett anders mit USB und Peripherie angebunden wird. Hier spielt auch die BIOS Version ein große Rolle.


    Zu den G Boards, wird von Dortania selbst empfohlen, dass man auf 490er Boards bleiben soll, ich wollte aber den 590er da mir PCIe 4.0 Anbindung schon wichtig war.


    Die Vorgehensweise die ich beschrieben habe, habe ich selbst auf meinem 490er getestet und schreibe hier keine unwissentliche experimente, sondern das, was ich gemacht habe um etwas zum laufen zu bringen oder irgend welche Fehler in Bezug auf ein Wiederstand einer Version von macOS.


    Leute, ich will doch nicht dass aus meinen Berichten und Ausführungen einem User seiner Hardware Schaden zugefügt wird! Um Himmels Willen. Natürlich will ich weiter helfen da, wo ich kann, stellt mich doch bitte nicht als XYZ da!


    Also, die Gigabyte Z490er Boards sind die stabilsten in Bezug auf Hacki, meine Erfahrungen beruhen auf das BIOS F20. Ich betone, dass neuere BIOS Versionen zumindest bei den Z590er, gewisse WIN11 Implementierungen eingeführt wurden und somit den Ruhestand komplet ausgehebelt haben.


    Dass der Z490er Board gar nicht bootet hatte ich einmal, dass ich es stromlos gemacht hatte, CMOS reset tätigte und das BIOS auf Standart setzte, dann alle Settings wie auf Dortania empfohlen wurde und die entsprechen OC Version mit den dortigen Setting vorgenommen. Netzwerkkarte I225-V war Anfangs zum Abgewöhnen. Jetzt mittlerweile ab der 11.5.* Version über den Boot-arg dk.e1000=0 zum laufen gebracht wird, dennoch darf man keine zusätzliche Ansprechungen bei



    Jetzt wird es hier polemisch, da manche es gar nichts hier deklarieren, also alles leer lassen unter Device-Properties, andere wiederum das gesamte Board aufführen. Hier kann es auch zu Fehler führen.


    Auf den Z490er muss man nicht unter Kernel, Quirks, DisableRtcCheksum aktivieren.


    Ich habe vorhin wieder alles so gemacht wie ich e beschrieben hatte was meine Wenigkeit gemacht hatte um dieses vermaledeite Karte zum laufen zu bringen und das Board bootet, startet Linux, WIN11 und macOS11 / 12 mit Netzwerk Anbindung voller Anbindung.


    Wirklich sorry wenn jemand hier durch meinen Ausführungen etwas negatives entstanden ist! Ehrlich ich beabsichtige hier keinen zu schaden!

    Bootloader: Open Core

    MoBo: Gigabyte Z690 Gaming X

    WiFi : BCM4360

    CPU : Intel Core i9 Intel Core i9-12900KF
    GPU : Radeon RX 6800 16GB
    Mem : 32 GB DDR4 3600 4x 8GB
    SSD M2: OSX 13
    SSD M2: WIN11 / Linux
    Case: UMX6S Silver

    Real Mac: 18,3

  • greecedrummer 5T33Z0

    All diese Beschreibungen bewirken nichts im Sinne der Lauffähigkeit. "AAPL,slot-name" für ein "internes" Device zu nehmen ist an sich unsinnig. Der einzige Zweck dessen ist, damit dieses Gerät im Systembericht unter PCI gelistet wird. Und in dem Fall dann nicht wie normal in einem bestimmten PCI-Slot, sondern eben in einem "Phantasie-Gebilde". "device-type" könnte hilfreich sein, ist aber in der Regel schon erkannt, auch über die Geräteklasse. "model" ist dann abschliessend nur "wichtig" durch den ersten Eintrag, damit hier auch ein Device namentlich steht und nicht dessen Adresse.

    Wirklich helfen könnten die Angaben zu "device-, vendor-, sub-vendor- und sub-device-id" sowie "compatible". Hier könnte man von den eigentlichen Daten abweichende Beschreibungen festlegen (spoofen), so dass in den Treibern hinterlegte Adressen angesprochen werden und somit eine Kext andockt. In diesem Fall würde ich aber NICHT diese OpenCore-Funktionalität bemühen, sondern dieses über eine SSDT bereitstellen. Denn diese werden frühzeitig beim Systemstart eingebunden, gegenüber OpenCores inject. Der Eintrag "name" könnte gegenüber "model" noch hilfreich sein (ebenfalls frühzeitig über SSDT) und hat mitunter nicht nur einen "kosmetischen" Auftrag. Denn je nach gewähltem SMBIOS "kann" für eine bestimmte PCI-Adresse ein bestimmtes Gerät von macOS erwartet werden, was dann von der tatsächlichen Bestückung abweicht. Das sieht man wunderbar in der IORegistry. Ein Beispiel: man hat nichts weiter deklariert, in einem PCIe-Slot steckt beispielsweise eine Soundkarte. Diese mag nicht laufen, obwohl die Treiber dazu installiert sind. Im IOReg sieht man einen Eintrag "name <ethernet>". Warum? Weil eben auf dieser Adresse bei diesem Apple-Gerät ein Ethernet-Gerät vorhanden ist. Schon wird eine völlig unpassende Geräteklasse bemüht, dessen Treiber laufen natürlich nicht und docken nicht an, die vorgesehenen Treiber werden auch nicht geladen, weil das Gerät nicht gefunden wird. Hier kann über eine SSDT frühzeitig nachgeholfen werden. Ob das jetzt im konkreten Fall auch so ist, keine Ahnung, habe ich nicht, kann ich nicht testen. Aber dieses Szenario macht deutlich, dass selbst eine einwandfreie Hardware (oder mit korrekten Adressen geflashte) unter bestimmten Umständen eben nicht von allein laufen mag, weil eben von macOS aufgrund einer bestimmten PCIe-Position (Device Path) auf ein anderes Gerät geschlossen wird. Das ist auch nicht unbedingt ein "Fehler" von macOS gegenüber anderen Systemen wie Linux oder Windows – macOS ist nunmal grundsätzlich für eine Handvoll bekannter Macs bestimmt, und nicht für uns Hackentosher. In diesem Kontext ist ein "läuft auf jeden Fall ohne Probleme" nie hundertprozentig vorhersagbar.


    Vorteil OpenCore Device Properties:

    unkompliziert, in der Regel funktionierend für kosmetische Eingriffe

    Nachteil OpenCore Device Properties:

    erst zu einem späten Zeitpunkt realisiert, viele Properties durch ACPI und macOS in der Folge festgelegt, eigene Properties können ausschliesslich im Format "DATA" injiziert werden und öfter werden andere Formate verlangt, eigene Properties können nicht bereits gleiche vorhandene mit anderen Werten "überschreiben".


    SSDT:

    Properties können in den Formaten "DATA", "Number" und "String" übergeben werden, und da die ACPI (und SSDT als Teil dessen) zuerst noch vor dem System geladen wird, werden diese Properties auch "festgeklopft". Nachteil ist das Zusammenspiel von SSDT und anderen Tabellen der ACPI, vornehmlich anderer SSDT und DSDT im Auge zu behalten, die Skriptsprache zu verstehen, kann im Detail recht aufwändig werden.

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

  • apfelnico Danke für die Erläuterungen. Dass "AAPL,slot-name" allein nichts bewirkt, ist mir bewusst. Der Device Property Eintrag ist bei mir eh anders:


  • apfelnico


    Ist mir schon klar nur um erwähnt zu haben, weil hier ein paar unterwegs waren die überall angesetzt hatten und sich verrannt hatten in Bezug auf Ansprechung. Unterstelle hier niemanden etwas und belehre niemanden mit Halbwissen aus Forengeschnacke wie es bei manchen üblich ist ...


    Dennoch danke für eure Ausführungen. Sorry wenn jemand glaubt dass ich so negativ in forum auftrete, hat schon ein grund dass manche das Forum verlassen haben. Ich verfolge auch in anderen Beiträgen dass man fasst schon mit dem Hackebeil auf einander losgeht... Bin nicht im Alter hier zu streiten vor allem mit Vorwürfen maltretiert zu werden.

    Das ist ein Hackintosh Forum und keine Programmierer Gilde wie es hier manche handhaben wollen...

    Also bitte ich auch um Rücksicht und nicht gleich negativ werden 5T33Z0 und herablassend. Die Qualität lässt so zu wünschen übrig.


    Mir ist bewusst dass manche Mitglieder Koriphäen sind wie Code schreiben, Programmierung usw, und dass sie zweifelsohne eine geistreiche Bereicherung sind, dennoch finde ich persönliche Anmache unangebracht! Angekommen?


    Dass ich dein Board in folge meiner Anleitung zerschossen habe, in indirekter Form, tut mir leid. Nochmal, wollte niemanden schaden. Für mich ist das Thema beendet.

    Bootloader: Open Core

    MoBo: Gigabyte Z690 Gaming X

    WiFi : BCM4360

    CPU : Intel Core i9 Intel Core i9-12900KF
    GPU : Radeon RX 6800 16GB
    Mem : 32 GB DDR4 3600 4x 8GB
    SSD M2: OSX 13
    SSD M2: WIN11 / Linux
    Case: UMX6S Silver

    Real Mac: 18,3

    Einmal editiert, zuletzt von greecedrummer ()

  • 5T33Z0 hast du deinen Intel PRO 1000 Controller wieder zum Funktion gebracht?

    Ich habe mir genau so einen aber mit einem Port bestellt und heute eingebaut, allerdings funktioniert er automatisch nicht.


    Habe schon versucht selber was in config.plist einzutragen, hoffentlich auch mit richtigen Values, hat aber nicht geholfen.


    Bevor der Controller angekommen ist habe ich leider auch die "Lösungen" von greecedrummer probiert, um den integrierten Controller zum Funktion zu bringen, vielleicht geht der neue Controller deswegen bei mir auch nicht... xD


  • leberkaes


    Den I225 musste ich deaktivieren, die Intel PRO 1000 funktioniert – ohne Device Properties. Alerdings mus Vt-D deaktiviert sein und/oder DisableIoMapper Quirk muss aktiviert sien, damit der Intel Pro 1000 läuft.


    Hatte zwischenzeitlich die DMAR Tabelle mal gedroppt und Vt-D enabled und DisableIoMapper deaktviiert, weil das als mögliche Problemlösung für den I225 Controller aufkam. Hat das Problem allerdings auch nicht gelöst und zudem ging dann die Intel PRO1000 nicht mehr. Daher weiß ich das.

    Einmal editiert, zuletzt von 5T33Z0 ()

  • 5T33Z0


    Aber wird die Virtualisierung in macOS noch möglich wenn VT-d auf Enabled bleibt und DisableIoMapper auf Enabled gesetzt wird?


    Hatte zwischenzeitlich die DMAR Tabelle mal gedroppt und Vt-D enabled und DisableIoMapper deaktiert, weil das als mögliche Problemlösung für den I225 Controller aufkam. Hat das Problem allerdings auch nicht gelöst und zudem ging dann die Intel PRO1000 nicht mehr. Daher weiß ich das.

    Achso. Schade... aber danke dass du versuchst, und danke dass du mir so viel geholfen hast. Ich bin neu in der Hackintosh-Welt, aber versuche alles so schnell wie möglich lernen damit ich auch irgendwann mithelfen könnte.



    EDIT:

    DisableIoMapper ist bei mir schon Enabled aber der Intel PRO 1000 Ethernet Adapter wird einfach nicht gezeigt.

    Ich habe auch versucht VT-d im BIOS zu deaktivieren, das Problem bleibt aber.

  • Hatte zwischenzeitlich die DMAR Tabelle mal gedroppt und Vt-D enabled und DisableIoMapper deaktiert, weil das als mögliche Problemlösung für den I225 Controller aufkam. Hat das Problem allerdings auch nicht gelöst und zudem ging dann die Intel PRO1000 nicht mehr. Daher weiß ich das.

    Hast du mehr als 16 GB RAM? Die Geschichte mit dem VT-d und dem DMAC/DMAR kam damals auf, weil bestimmte Netzwerkkarten unter Big Sur nicht funktionierten bei Leuten, die mehr als 16GB RAM hatten. Entweder VT-d disabled und RAM =< 16GB oder VT-d enabled und DMAC/DMAR angepaßt. Bei mir trat damals das Problem mit dem Apple Thunderbolt-Ethernet-Adapter auf. Ich musste aber neben dem Bearbeiten der DMAR-Tabelle und Droben der originalen zusätzlich noch einen DMA-Controller (DMAC) per SSDT erzeugen bevor alles funktionierte.

    Power Mac G5
    (Late 2004)



    CPU: Intel Core i9-9900K (Coffee Lake)
    Mainboard: GIGABYTE Z390 M GAMING
    Grafik: SAPPHIRE Pulse Radeon RX 580
    Bootloader: OpenCore (0.9.8)
    Operation Systems: macOS "Ventura" 13.6, macOS "Sonoma" 14.3,
    macOS "Catalina" 10.15.7
    Power Mac G4
    (Quicksilver)



    CPU: Intel Core i3-10103F (Comet Lake)
    Mainboard: ASROCK H470M-HDV/M.2
    Grafik: MSI Radeon RX 560 AERO ITX 4G OC
    Bootloader: OpenCore (0.8.7)
    Operation Systems: macOS "Ventura" 13.1, Windows 10 Professional

    Stopinprogress...

    Lenovo Thinkpad X1 Tablet Gen3 Intel Core i7-8550U, Intel® UHD Graphics 620, 16 GB LPDDR3, Thunderbolt 3, Intel Dual-Band Wireless-AC 8265, 802.11ac Dual-Band 2x2 Wi-Fi® + Bluetooth 4.2, Touchscreen & Stift

  • Vorhin Logic gestartet, Flexpitch aktiviert, um Spur zu analysieren. Boom, instant reboot, BIOS Reset inklusive.


    Dann mit Clover gestartet. Alles in Butter. Gleiche Einstellungen, gleiche SSDTs (wo benötigt). Läuft :D

  • leberkaes


    Wie sieht die Karte denn in einem Tool wie Hackintool aus.


    Sieh mal bei PCIe nach wie die Karte aufgelistet ist.

  • VT-D muss deaktivert sien bzw DisableIOMapper aktiviert.


    Eventuell auch mal die Netzwerkeinstellungen löschen:


    sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

    sudo rm /Library/Preferences/SystemConfiguration/preferences.plist

  • 5T33Z0



    Herzlichen Glückwunsch zum Erfolg mit dem I225 Controller.


    Wäre es mein Rechner würde ich mich auch sofort ranmachen.


    Leider steht das System bei meiner Frau und die ist strikt gegen Lösungen die bei jedem Update diesen langwierigen Lösungsprozess benötigen.


    Shanee auf insanelymac hofft ja auf einen Patch. Ich dann auch und drücke da mal die Daumen.

  • ... entgegen jeden Vorwurf das ich hier Mist schreibe oder einem das Board zerschieße ... hier sind meine Beweise dass alles Läuft! Außerdem sind noch X User hier Unterwegs die es ja bestätigt haben dass es heklappt hat ... und ja sogar mit 12.1.0. Habe extra nochmals gestern Abend mit Clover und OC probiert und war online.#


    Fazit: mit I225 Controller null Probleme!

    Bootloader: Open Core

    MoBo: Gigabyte Z690 Gaming X

    WiFi : BCM4360

    CPU : Intel Core i9 Intel Core i9-12900KF
    GPU : Radeon RX 6800 16GB
    Mem : 32 GB DDR4 3600 4x 8GB
    SSD M2: OSX 13
    SSD M2: WIN11 / Linux
    Case: UMX6S Silver

    Real Mac: 18,3

  • greecedrummer


    Wir haben es verstanden. Es hat auch NIEMAND behauptet, dass Du Mist schreibst. Es ist nur so: Du hast ein 2.5 Gbit Router und damit scheint der Controller mit den vorhanden Treibern zu funktionieren - out of box.


    Deine Config hat jedenfalls keinen Einfluss darauf, denn die Einträge, die Du unter DeviceProperties verwendest, haben keinen verändernden Einfluss auf die Eigenschaften des Controllers selbst – worauf Apfelnico ja bereits hingewiesen hatte.


    Aber bei anderen Leuten mit einer Gbit Ethernet Verbindung ist es eben nicht der Fall und es funktioniert dorrt nur mit beta 8 kexts – unabhängig von DEINEM Fazit.


    Es wäre auch schön, wenn wir es jetzt darauf beruhen lassen könnten. Es nervt einfach nur noch mega!

  • 5T33Z0 schön dass ich nerve, trotzdem funktioniert der Controller mit 1 GBit Router und Netwok-Controller ( Habe hier mehr als 12 unterschiedliche die alle gehen) ohne Probleme, dass will ich auch geschrieben haben. Deine Aussage stimmt nicht wegen 2.5 GBit Router ... Kollege von mir hat auch das selbe Board mit 1 GBit Router, läuft!

    Bootloader: Open Core

    MoBo: Gigabyte Z690 Gaming X

    WiFi : BCM4360

    CPU : Intel Core i9 Intel Core i9-12900KF
    GPU : Radeon RX 6800 16GB
    Mem : 32 GB DDR4 3600 4x 8GB
    SSD M2: OSX 13
    SSD M2: WIN11 / Linux
    Case: UMX6S Silver

    Real Mac: 18,3