AMD RADEON RX Grafikkarten ohne LILU & WhatEverGreen nutzen

  • ich würde es ebenfalls ausprobieren.... aber
    wie, oder woher krieg ich die Version 4296 von Clover
    ich finde nirgends einen Download der Installationsdatei....


    weiß des jemand?


    Mit freundlichen Grüßen

    mSata SSD 60GB Kingston (Clover Bootloader)
    SD 250 GB Samsung 850 EVO (Macintosh HD)
    1 TB HD WD (Daten)
    Wlan+Bluetooth - BCM94360CD - 802.11 A/B/G/N/AC + BLUETOOTH 4.0 PCI-Express
    Sound - externe USB Soundkarte (EC Tecnology)
    GraKa - AMD Sapphire Pulse Radeon Pro 560 4GB

  • Im Clover Configurator gibt’s eine Funktion dein Clover Bootloader zu updaten. Da kannst du die neue Version ziehen.

  • werd mich dieses wochenende auch dran machen! wahnsinn was die typen immer wieder raushaun - ebenso unsere vertreter hier, DANKE!

  • also irgendwie will das nicht so recht bei mir...


    @schluden mit der Updatefunktion von Clover komme ich nur bis Version 4289
    und mit der Installationsdatei von @rubenszy habe ich anschließend auch nicht mehr als Version 4289


    wie gesagt, es will nicht so recht
    warten wir noch ein Weilchen.......


    servus

    mSata SSD 60GB Kingston (Clover Bootloader)
    SD 250 GB Samsung 850 EVO (Macintosh HD)
    1 TB HD WD (Daten)
    Wlan+Bluetooth - BCM94360CD - 802.11 A/B/G/N/AC + BLUETOOTH 4.0 PCI-Express
    Sound - externe USB Soundkarte (EC Tecnology)
    GraKa - AMD Sapphire Pulse Radeon Pro 560 4GB

  • Ich habe gerade gelesen, dass es Neuigkeiten in Clover gibt! Ich habe zwar keine AMD Grafikkarte, aber vielleicht kann das ja jemand testen und sich freuen?


    Es geht speziell um diesen Commit in Clover: https://sourceforge.net/p/cloverefiboot/code/4296/
    Hier gibt's ne etwas detailliertere Beschreibung zum Commit: http://www.insanelymac.com/for…tions/page-5#entry2531908


    Angeblich braucht's dann weder WhateverGreen noch den DSDT Patch.


    Leider braucht es hier noch immer eine SSDT, um das HDMI-Audio einzubinden, denn das wird in der CLOVER rev.4296 nicht mit eingebunden.

    ASUS WS X299 SAGE/10G • Intel Core i9-7920X 12-Core 2.9GHz • 128GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 980 NVMe M.2 SSD 1 TB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x SAMSUNG 49" @ 5120 x 1440 (100Hz) via DP • LG OLED 55" TV @ 3840 x 2160 (100Hz) via HDMI
    WINDOWS 11 ENTERPRISE INSIDER (PRO950 NVMe) • macOS BIG SUR und MONTEREY latest Build (jeweils auf Samsung 980 NVMe) • OpenCore always latest

  • Nachdem auf IM schon einige tönen "In Clover gelöst. Thread hat sich erledigt. Wer kein Clover nutzt SSKM":


    Schön für diejenigen.


    Andere haben dennoch weiterhin ein Interesse. Und die Cloveristen mögen dann bitte einen eigenen Thread aufmachen.


    Wissen zur Lösung des Problems mittels DST/SSDT zu konzentrieren ist ja wohl nicht der schlechteste Ansatz.

  • Im Clover Configurator gibt’s eine Funktion dein Clover Bootloader zu updaten. Da kannst du die neue Version ziehen.


    Die lädt Dir nur die off. Releases, dazu gehört die 4296 nicht.

    iMac17,1 GA-Z170N WiFi F22f |i5-6600 HD530 |RX560 |16GB |250GB SSD |macOS 14.4.1 |*
    MacBook9,1XiaoMi Air 12,5"(erster XiaoMi im Forum)|M3 6Y30 HD515 |4GB |128 & 250GB SSD |macOS 11.6 |Clover
    MacBookPro15,4XiaoMi-Pro-15,6" |i5-8250U UHD620 |8GB |250 & 250GB SSD |macOS 14.4.1 |*
    MacBookPro16,1XiaoMi RedMi 14" (erster RedMe im Forum)|i7-10510U | 8GB | 512GB SSD | macOS 14.4.1 |*
    MacMini8,1 NVISEN Y-MU01(erster NVISEN im Forum)|i7-10510U |24GB |256GB SSD |macOS 14.4.1 |*
    MacMini8,1HYSTOU S210H (Adventskalender vs. DSM2 samt Fake Profil)|i9-9880H UHD630|32GB |250GB SSD |macOS 14.4.1 |*
    MacMini8,1HYSTOU P05B (erster Hack mit OpenCore im Forum)|I7-8550U UHD620|16GB |500GB SSD |macOS 14.4.1 |*

    * BootLoader OpenCore REL-100-2024-04-16


    Experte ist nicht immer gleich Expertise

  • Also bei mir funktioniert das nicht so richtig mit dem Clover. Sehr merkwürdig.


    hat sich erledigt, war etwas in der clover config.plist zu viel, läuft nun 1a



    PS: Gibt auch schon wieder eine neuer Version von Clover.

    Dateien

    Liebe Grüße, alex


     Mac mini Late 2020 – M1 – 16GB RAM – 256GB SSD

     MacBook Pro 15” Late 2015 – i7 4980HQ – 16GB RAM – 256GB SSD

     MacBook Pro 13” Late 2014 – i5 4278U – 8GB RAM – 120GB SSD

    iPhone 13 – iPhone 8 Plus – iPad Pro 12,9" – AirPods 1. Gen – AirPods Pro – Apple Watch S5 44mm




    2 Mal editiert, zuletzt von revunix ()

  • PS: das fällt mir jetzt erst auf: in Deiner DSDT steht der Patch an der völlig falschen Stelle! Der müsste eigentlich unter der Device PEGP kommen, und nicht schon, wie bei Dir unter Device PEG0. Frage: Müsste nicht eigentlich einfach PEGP GFX0 heißen und nicht beides existieren?
    Schicke mir bitte mal eine unmodfizierte DSDT (kannst Du im CLOVER Bootmenu mit "F4" machen).


    Ich befasse mich gerade nochmal damit und bin irgendwie immernoch nicht 100% durchgestiegen... :S


    Ich habe dir mal eine DSDT frisch aus dem BIOS gezogen, damit du sehen kannst, wie die Ursprungskonfiguration aussieht. Dabei ist in PEG0 nur noch PEGP zu finden, danach gehts mit PEG1 weiter... Dementsprechend erscheint der AMD7000Controller (und Anhängsel) im IOReg unter PCI0/PEG0/PEGP (IOACPIPlane:/_SB/PCI0@0/PEG0@10000/PEGP@0).


    Injecte ich mit einer SSDT jetzt ein Device mit dem Namen GFX0 nach PEG0/PEGP inklusive Miezes Patch, sowie einer _DSM Methode (siehe Anhang), funktioniert Sleep richtig, im IOReg hängt der AMD7000Controller dann aber weiterhin an PEGP und es gibt im IOReg kein Gerät Namens GFX0. Die _DSM Properties sind dementsprechend auch nicht unter GFX0 zu finden und erscheinen auch nicht unter PEGP.


    Erstelle ich hingegen eine SSDT, die Miezes Patch in das Device PEGP injected, funktioniert Sleep nicht, wahrscheinlich weil PEGP bereits vorhanden ist und nicht von der SSDT überschrieben wird...


    Vielleicht kannst du mich aufklären ?( :D

    Dateien

    • SSDT-GFX0.aml

      (629 Byte, 80 Mal heruntergeladen, zuletzt: )
    • VanillaDSDT.aml

      (67,92 kB, 72 Mal heruntergeladen, zuletzt: )

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • @kuckkuck


    versuche bitte mal die hier angehängte SSDT.

    Dateien

    • SSDT-GFX0.aml

      (754 Byte, 106 Mal heruntergeladen, zuletzt: )

    ASUS WS X299 SAGE/10G • Intel Core i9-7920X 12-Core 2.9GHz • 128GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 980 NVMe M.2 SSD 1 TB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x SAMSUNG 49" @ 5120 x 1440 (100Hz) via DP • LG OLED 55" TV @ 3840 x 2160 (100Hz) via HDMI
    WINDOWS 11 ENTERPRISE INSIDER (PRO950 NVMe) • macOS BIG SUR und MONTEREY latest Build (jeweils auf Samsung 980 NVMe) • OpenCore always latest

  • Respekt! Es funktioniert mal wieder tadellos, die Treiber erscheinen im IOReg jetzt unter GFX0 und die DSM Einträge sind auch mit dabei. Nur HDAU wird im IOReg nicht unter PCI0@0/PEG0@1/IOPP/HDAU@0,1 sondern unter PCI0@0/AppleACPIPCI/HDAU@3 gelistet, ich weiß nicht ob das von dir so gewollt ist.


    Du veränderst also die _ADR von 0x00 auf 0x0F und injectest das GFX0 Device nicht "in" PEGP sondern "neben" PEGP. Letzteres macht für mich perfectly sinn, aber wieso die Adress-Änderung? Damit GFX0 0x00 sein kann? :huh:

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.


  • Nur HDAU wird im IOReg nicht unter PCI0@0/PEG0@1/IOPP/HDAU@0,1 sondern unter PCI0@0/AppleACPIPCI/HDAU@3 gelistet, ich weiß nicht ob das von dir so gewollt ist.
    Du veränderst also die _ADR von 0x00 auf 0x0F und injectest das GFX0 Device nicht "in" PEGP sondern "neben" PEGP. Letzteres macht für mich perfectly sinn, aber wieso die Adress-Änderung? Damit GFX0 0x00 sein kann? :huh:


    ? ? ?
    lade bitte mal ein IORegExplorer-Ergebnis hier hoch, damit ich mir anschauen kann, wie da was jetzt eingebunden wird.

    ASUS WS X299 SAGE/10G • Intel Core i9-7920X 12-Core 2.9GHz • 128GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 980 NVMe M.2 SSD 1 TB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x SAMSUNG 49" @ 5120 x 1440 (100Hz) via DP • LG OLED 55" TV @ 3840 x 2160 (100Hz) via HDMI
    WINDOWS 11 ENTERPRISE INSIDER (PRO950 NVMe) • macOS BIG SUR und MONTEREY latest Build (jeweils auf Samsung 980 NVMe) • OpenCore always latest

  • In meiner Vanilla DSDT gibt es kein HDAU, sondern lediglich B0D3. (Das Device B0D3 ist in PCI0/B0D3)


    Ich habe jetzt mal mit der Vanilla DSDT gearbeitet und deine SSDT installiert. IOReg ist im Anhang. Wie du siehst gibt es damit kein HDAU-Gerät.


    Benenne ich B0D3 in HDAU um, gibt es ein HDAU Device in IOReg, jedoch unter PCI0/HDAU und nicht PCI0/PEG0/HDAU, wo es meines Wissens eigentlich hin sollte. Jetzt ist die Frage, was wohl die beste Lösung ist...


    Danke fürs Drüberschauen!

    Dateien

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

  • Versuche bitte mal diese SSDT. Diese sollte nun auch HDMI-Audio injecten.
    Sollte dies nicht der Fall sein, versuche bitte mal folgende Passagen in der SSDT:


    Code
    1. "hda-gfx",
    2. Buffer (0x0A)
    3. {
    4. "onboard-1"
    5. }


    wie folgt zu ändern:


    Code
    1. "hda-gfx",
    2. Buffer (0x0A)
    3. {
    4. "onboard-2"
    5. }


    Sollte in der SSDT 2x auftauchen. Da ich den "onboard sound" meines Motherboards nicht nutze (im BIOS komplett deaktivert), steht das bei mir IMMER auf "onboard-1". Sound geht bei mir via HDMI auf meinen Denon-AVR

    Dateien

    • SSDT-GFX0.aml

      (821 Byte, 86 Mal heruntergeladen, zuletzt: )

    ASUS WS X299 SAGE/10G • Intel Core i9-7920X 12-Core 2.9GHz • 128GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 980 NVMe M.2 SSD 1 TB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x SAMSUNG 49" @ 5120 x 1440 (100Hz) via DP • LG OLED 55" TV @ 3840 x 2160 (100Hz) via HDMI
    WINDOWS 11 ENTERPRISE INSIDER (PRO950 NVMe) • macOS BIG SUR und MONTEREY latest Build (jeweils auf Samsung 980 NVMe) • OpenCore always latest

    4 Mal editiert, zuletzt von Mork vom Ork ()

  • Habe ne frage ist es auch möglich mit dem Enoch Bootloader weil Clover will bei mir irgendwie nie funktionieren.

    Macbook:
    Mackbook 5,1 Os: High Sierra Festplatte: 1tb Ram: 6gb Cpu: core2duo 2Ghz Grafikarte: Geforce 9400m
    Hacki:
    MotherBoard:
    GIGABYTE GA-B450M-DS3H Ram: 32gb DDR4 CPU: Ryzen 7 2700x Grafikkarte: Nvidia Geforce 1060
    SSD: Sandisk 256gb M.2: Samsung evo 970 250gb System: Windows 10 64bit/Mac os x 10.13.6 High Sierra

  • Im Prinzip geht auch Chameleon (passende Sierra/HS Version vorausgesetzt) - doch nur dann, wenn du ein schon gut gepatches DSDT.aml für dein Board hast. Chameleon kann auch SSDT.aml nutzen und laden.
    Im Prinzip ja die Hauptunterschiede dass bei Clover (dank der vielen eingebauten DSDT fixes) auch ein booten ganz ohne DSDT möglich und bei Clovers kext und kernel patches möglich sind.
    Wenn man ein passendes DSDT.aml fürs Biard hat ist Chameleon gut möglich und für Einsteiger meist auch viel einfacher. Ohne DSDT.aml ist für Einsteiger + Profis Clover angesagt.

  • Wo würde ich die Daten finden ? Habe noch net mal den sound installiert weil das ist die einfachere Sache die nötig Kext zu finden. Aber was bringt mir ja sound wenn di karte streikt

    Macbook:
    Mackbook 5,1 Os: High Sierra Festplatte: 1tb Ram: 6gb Cpu: core2duo 2Ghz Grafikarte: Geforce 9400m
    Hacki:
    MotherBoard:
    GIGABYTE GA-B450M-DS3H Ram: 32gb DDR4 CPU: Ryzen 7 2700x Grafikkarte: Nvidia Geforce 1060
    SSD: Sandisk 256gb M.2: Samsung evo 970 250gb System: Windows 10 64bit/Mac os x 10.13.6 High Sierra

  • @Mork vom Ork Die DTGP Methode hat leider nicht geholfen, ich arbeite generell auch gerne ohne sie.


    Ich habe aber den Fehler gefunden, ist eigentlich ganz banal :)
    In deiner SSDT befindet sich das HDAU Gerät im GFX0 Device:

    Optisch gesehen erscheint HDAU also erst nach Aufklappen von GFX0.


    Das HDAU Gerät müsste aber eigentlich einfach nach PEG0, also quasi "neben" GFX0. Dementsprechend habe ich die SSDT wie folgt angepasst:

    Optisch gesehen erscheint HDAU also jetzt nach Aufklappen von PEG0, direkt nach/neben GFX0.


    Damit funktioniert alles bestens. Vielen Dank für deine Hilfe! Auf das Anpassen von _ADR in Miezes Patch wäre ich echt nicht gekommen!
    (Store (0x0F, \_SB.PCI0.PEG0.PEGP._ADR))

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.