Beiträge von CrazyHeinke

Zitat von griven

Nun ja Deine EFI ist ja nicht mehr so ganz wirklich auf dem aktuellen Stand...

Ich habe hier mal OC und alle Extensions auf die jeweils letzte Version gehoben teste mal damit: EFI.zip

griven nach dem hinzufügen meiner Seriennummer etc und dem boot-arge "-v" verhält sich die config leider genau gleich..

Ich hatte ein Upgrade von Sonoma auf Sequoia durchgeführt - morgen werde ich mal eine komplette Neuinstallation probieren und schauen, wie sich das verhält.

Vielen Dank trotzdem fürs über die Config schauen!

Zitat von Arkturus

ich kenne es nur so, dass zur Installation das Bootarg amfi=0x80 und später -amfipassbeta verwendet wird. Dass der Amfipass.kext zur Installation und bis nachg dem OCLP-Patch deaktiviert werden muss, ist irgendwie an mir vorüber gegangen. Ich hatte aber schonmal die Situation, dass Sequoia nur noch mit amfi=0x80 booten wollte. Und ich kann mich nicht erinnernm was der Workarround dazu war. Ich würde jetzt mal die Skywalker IOFamily deaktiviren, war da nicht auch mall was mit AppleALC.kext??

Vielleicht mall eine frühere EFI testen oder am besten hier mal zeigen.

Anbei mal meine EFI - wie sie unter Sonoma noch funktioniert hat.

Unter Sequoia erhalte ich den o.g. Fehler.

Wenn ich den AMFIPass.kext deaktiviere kann ich das System normal booten.

Zitat von griven

Lilu hast Du in der aktuellsten Developer Version (nightly Build) ?!?

Nein ich nutze die 1.6.8 RELEASE Version von Lilu.

Das könnte ich mal testen

Zitat von griven

Komisch habe ich so noch nicht gesehen das der Kext da Probleme macht...

Hast Du nur den AmfiPass aus dem OCLP Repo aktualisiert oder hast Du die IOSkywalkFamily und IO80211Family auch erneuert? Falls Du nur den AmfiPass erneuert hast erneuere die andern bitte auch denn andernfalls kann das schon so solchen Problemen führen. Wenn Du die auch erneuert hast und es trotzdem weiterhin zu Problemen kommt kann es auch sein das Du einmalig das BootArg AMFI=0x80 hinzufügen musst um Initial einmal an AMFI vorbei mit den eingebrachten Patches zu booten. Wenn der Rechner dann hochkommt und WLAN läuft kannst Du das BootArg wieder entfernen und es sollte auch mit AMFIPASS allein laufen.

Genau das ist auch mein Problem - habe auch im Forum keinen mit demselben Problem finden können.

Zumindest keinen, der bereits die Version AmfiPass.kext 1.4.1 verwendet.

Ja genau ich habe den Kext direkt von Git - Aktualisiert habe ich:

- AMFIPass.kext von der Version 1.4.0 auf 1.4.1 (OCLP/payloads/kext/Acidanthera)

- IOSkywalkFamily.kext von der Version 1.1.0 auf 1.2.0 (OCLP/payloads/kext/wifi)

Der IO80211FamilyLegacy wurde soweit ich das sehen kann nicht aktualisiert.

Mit amfi=0x80 funktioniert der Boot sowie Wifi und BT wunderbar! Das war meine initiale Konfiguration damit ich den OCLP Patches überhaupt laufen lassen kann

Jetzt versuche ich amfi=0x80 zu entfernen und dafür den AMFIPass.kext zu aktivieren - leider weiter ohne Erfolg

Hallo zusammen,

nach dem Sequoia Update erhalte ich bei jedem Boot den Hinweis "Memory Module Missconfigured".

Ich habe MacPro7,1 als SMBIOS und RestrictEvents in der aktuellsten Release Version verknüpft (1.1.4)

Bei Sonoma hatte das für mich immer gereicht für die RAM Konfiguration.

Hat einer von euch nach dem Update ebenfalls die Meldung erhalten ?

Kann jemand sagen, ob eventuell eine neue Version vom Restrict Events Kext Abhilfe schafft, bzw. ob daran bereits gearbeitet wird?

Hallo zusammen,

ich habe heute morgen das Update auf die macOS Version 15.0 gestartet.

Das Update lief schnell und ohne Probleme durch. Nach dem Update habe ich den Broadcom WLAN-Patch wieder durchgeführt - auch dies mit erfolg. (OCLP v2.0.1)

Aus Sonoma weiß ich, dass ich im Anschluss AMFI wieder aktivieren muss - also habe ich versucht wie unter Sonoma gewohnt den AMFIPass.kext aus dem OCLP einzubinden.

Sobald dieser in meiner Config aktiviert ist, startet mein System nicht mehr. (Ja der Kext ist bereits auf dem aktuellsten Stand 1.4.1)

Ich habe es versucht mit dem boot-arge -amfipassbeta und ohne - Macht keinen Unterschied. (wird eigentlich seit 1.4.0 nicht mehr benötigt, wenn ich mich richtig erinnere)

Hat einer von euch noch eine Idee, warum der AMFIPass Kext mein System so stört?

Selbe Konfiguration unter Sonoma mit dem 1.4.1 Kext läuft ohne Probleme.

Über einen Tipp wäre ich sehr dankbar !!

G.com anbei einmal meine EFI Konfiguration - es wäre super, wenn da vielleicht mal jemand mit drauf schauen kann

Das USB Mapping habe ich wie gesagt via USBToolBox/tool v0.2 erstellt. (unter Windows 11)

Die ACPI´s habe ich mittels SSDTime erstellt (unter Windows 11)

- EC, PLUG, RTCAWAC

- USB-Reset (Deaktiviert weil diese bei meinem Board nicht benötigt wird)

Weiter habe ich die USBX aus dem OpenCore Post-Install Verzeichnis hinzugefügt...

und aktuell wie gesagt der Versuch der FixShutdown-USB-SSDT.

Ergänzung:

Ich habe den ACPI Abschnitt einmal entfenrt und die folgenden SSDTs manuell neu erstellt anhand der Anweisungen vom Dortania Guide und den Vorlagen:

- SSDT-AWAC-DISABLE

- SSDT-PLUG

- SSDT-EC-USBX

- SSDT-RHUB (diesen in der config wieder deaktiviert)

Anschließend natürlich ein NVRAM Reset - leider ohne Erfolg - scheint dann also was mit meinem USB port mapping zutun zu haben?

Hi,

ich habe eine neue OpenCore Installation - alles funktioniert super außer dem ausschalten

Mir ist bekannt, dass es einen FixShutdown-USB-SSDT.dsl in Kombination mit folgendem ACPI Patch _PTS to ZPTS Patch gibt.

Diese Methoide scheint bei mir nicht zu funktionieren - vorausgesetzt ich habe die aml richtig konfiguriert.

Die folgenden 3 habe ich getestet:

1 - Search for _PRW find: _SB.PC00.XHCI

2 - _SB.PC00.XHCI.PMEE

3 - Search for PMEE find: _SB.PC00.LPCB.SIO1.PMEE

Wenn ich meinen PC ausschalte, geht er zwar aus und fährt korrekt herunter, aber startet nach 3 Sekunden wieder.

Specs:

- Gigabyte Z590i Aorus Ultra (Bios version F10)

- OpenCorePkgRelease 1.0.1

- Mac OS Sonoma 14.6.1

Ich habe eine eigene USB port Konfiguration via USBtoolBox v0.2 erstellt - USB ports funktionieren so wie sie sollen und auch der Ruhezustand funktioniert einwandfrei.

Vielleich kann mir hier ja jemand behilfreich sein?

Im Anhang füge ich meine DSDT mal an.

Ich habe meine Config jetzt noch einmal zurück gebaut.

Sprich AppleIGC deaktiviert und AppleIntel210Ethernet.kext inklusive BootArg ("e1000=0") wieder hinzugefügt.

Interessanterweise blieb jetzt mein Netzwerkadapter aktiv inkls. meiner gezogenen IP (via DHCP). Auch nach einem CleanNVRAM..

Allerdings friert mein PC immernoch ein sobald ich die USB Verbindung zu meinem QNAP herstelle. (unter Ventura lief das ohne Probleme)

Alle anderen USB Themen funktionieren super - die USB Config habe ich auch schon unter Ventura knapp 1 Jahr ohne Probleme verwendet.

Nachdem ich die Kexts wieder rückgängig gemacht habe wurde nach dem letzten Absturz auch der Netzwerkadapter QNAP QA (virtueller Port für die USB Quick Access Variante) unter MacOs angelegt. Leider stürtzt das komplette System trotzdem immer ab sobald ich den NAS via USB verbinde.

Hat hierzu vielleicht noch jemand eine Idee?

Zitat von cobanramo

Diesen Kext gab es zuletzt unter Monterey, danach wurde umgebaut und entfernt,

die Intel i225V v3 vom Z590 wird seit dem nur noch von Dext Driver "com.apple.DriverKit-AppleEthernetE1000" bedient.

Das funktioniert auch wunderbar unter Ventura und Sonoma.

Wenn du unter Ventura oder Sonoma den "AppleIntel210Ethernet.kext" vom Monterey einsetzen willst musst du auch den bootarg mitbenutzen damit die Dext Driver "com.apple.DriverKit-AppleEthernetE1000" von dem es normal startet unterdrückt wird.

dk.e1000=0 --> Bootarg für BigSur

e1000=0 --> Bootarg für Monterey, Ventura und Sonoma

Das problem hier unter Sonoma ist das die Intel i225V v3 mit dem standardmässigen Dext Driver "com.apple.DriverKit-AppleEthernetE1000"  IOSkywalkFamily.kext mitbenützt.

Ohne OCLP Modern Wifi patch startet das ganze auch normal und tut seine sache.

Mit OCLP Modern Wifi patch wird die IOSkywalkFamily.kext ersetzt und gepatscht, daher passt irgendwas nicht mehr.

Bei mir wirkt sich das so aus das Wifi funktioniert aber LAN Chip keine DHCP adressen beziehen kann usw.

Ergo müssten die OCLP Dev`s das weiter stricken damit das ganze Netzwerkstack die den Skywalk Kext mitbenutzt auch mitpatchen.

Da sie vermutlich nur den Wifi Teil anpassen ist es für Desktop Benutzer halbgar. bei Laptops ohne Lan Port mag das gut klappen.

Ich vermute hier sogar das all die Lan Chips die den Skywalk Kext mitbenötigen probleme haben.

Anders sieht es mit dem alten Intel Treibern wie vom Monterey "AppleIntel210Ethernet.kext" aus.

Hier wird die IOSkywalkFamily.kext nicht mitbenötigt und daher wirkt sich das eben nicht auf die Intel i225V v3 aus.

Wie schon oben erwähnt muss man daher die Dext Driver mit Bootarg unterdrücken damit die AppleIntel210Ethernet.kext" geladen wird.

Die AppleIGC.kext ist ein umgebauter Linux Driver der bei mir vom Catalina bis Sonoma durchgehend den Intel Chip startet.
Starten heisst eben noch lange nicht das es sauber funktioniert, die Kext bringt leider mehr probleme als nutzen.
Sie verursacht konfikte mit AHCI, bricht bei mir den Sleep und kann keine Recovery`s mehr starten.
Ansonsten wäre das die beste lösung gewesen.

Gruss Coban

Alles anzeigen

Das ist absolut korrekt bis Ventura habe ich auch den Kext mit dem bootargs "e1000=0" verwendet.

Nach der Neu Installation von Sonoma wurde mein I225 auch korrekt erkannt nur nach dem WiFi Patch nicht mehr...

Bei mir macht sich das allerdings so bemerkbar, dass der komplette Netzwerkadapter nach dem Patch nicht mehr sichtbar ist.

Wenn nur keine DHCP Adresse gezogen wäre, könnte man diese ja auch einfach manuell setzen..

Hallo zusammen,

ich habe ebenfalls auf Sonoma 14.0 aktualisiert (Neue Installation).

Im Anschluss an die Installation habe ich den WiFi Patch für meine BCM94360NG angewendet.

csr-active-config aktualisiert (03080000),

das boot-args "amfi=0x80" ergänzt,

Secure Boot Model aktualisiert "Disabled",

Folgenden Kext blockiert "com.apple.iokit.IOSkywalkFamily"

und die 2 Kexte eingebunden "IOSkywalk.kext", "IO80211FamilyLegacy.kext" (inklusive Plugin)

Anschließend habe ich den OCLP 1.0.1 Release zum patchen verwendet und siehe da WiFi, AirDrop etc funktioniert wunderbar.

Hierbei ist mir aufgefallen, dass der oben genannte WiFi Patch in Kombination mit dem "AppleIntel210Ethernet.kext" nicht funktioniert.

(Der I225-V Port von meinem Board wird nicht mehr erkannt)

Ohne den o.g. WiFi Patch funktionierte die Erkennung meiner ETH Karte problemlos mit dem Apple Kext.

Also habe ich den Kext entfernt und durch den "AppleIGC.kext" ersetzt. Jetzt funktioniert sowohl WiFi als auch Ethernet.

Leider funktioniert mit dem "AppleIGC.kext" mein QNAP USB Quick Access nicht mehr - hierbei wird ein Virtueller Netzwerkadapter erzeugt.

Sobald ich die USB Verbindung herstelle laufe ich in einen Kernel Panic. Wenn ich die USB Verbindung beim booten bereits hergestellt habe laufe ich nach der Anmeldung in eine Kernel Panic.

Daher meine Frage an euch wie habt ihr den I225-V unter Sonoma am laufen?

Vielen Dank schon einmal vorab!

Hallo zusammen,

ich habe gestern ebenfalls auf Sonoma 14.0 installiert (Neue Installation).

Im Anschluss an die Installation habe ich csr-active-config aktualisiert (03080000),

das boot-args "amfi=0x80" ergänzt,

Secure Boot Model aktualisiert "Disabled",

Folgenden Kext blockiert "com.apple.iokit.IOSkywalkFamily"

und die 2 Kexte eingebunden "IOSkywalk.kext", "IO80211FamilyLegacy.kext" (inklusive Plugin)

Anschließend habe ich den OCLP 0.6.8 Release zum patchen verwendet und siehe da WiFi, AirDrop etc funktioniert wunderbar.

Hierbei ist mir aufgefallen, dass der oben genannte WiFi Patch in Kombination mit dem "AppleIntel210Ethernet.kext" nicht funktioniert.

Also habe ich den Kext entfernt und durch den "AppleIGC.kext" ersetzt. Jetzt funktioniert sowohl WiFi als auch Ethernet.

Nach dem ich mich ein bisschen in die AMFI Thematik eingelesen habe würde ich nun ebenfalls gerne das boot-args "amfi=0x80" wieder entfernen und dafür den Amfipass.kext und das boot-args "--amfipassbeta" hinzufügen.
Wo habt ihr alle den Amfipass.kext her, also wo finde ich den ich nenne es mal Herkunftsdownload?

Des Weiteren würde mich interessieren, ob ich nach dem Patchen SecureBoot in MacOS wieder einschalten kann?

Als abschließenden Test habe ich die WiFi Karte noch einmal in den Build eines Freundes eingesetzt um zu testen, ob diese einwandfrei funktioniert.

Da meine WiFi Karte dort ohne Probleme lief und ich im Bios absolut nichts dies bzgl. finden konnte, denke ich dass die Karte wirklich nicht direkt im originalen Slot des Aorus Boards funktioniert.

Das ist natürlich nennen wir es mal suboptimal

Ich habe gerade mal auf der Gigabyte Seite für mein Board geschaut und dort wird der m2 Port für die WiFi Karte einfach gar nicht mehr erwähnt

Gerade habe ich aber noch einen Artikel gefunden indem jemand beim Aorus Ultra die originale Karte erfolgreich gegen eine BCM94360NG getauscht hat.

Link

Zitat von atl

Der CNVi-Slot hat ebenso wie der normale M.2 A+E Key slot eine Anbindung an USB, aber keine an PCIe. Somit gehen nur CNVi-Karten und der USB-Teil von normalen M.2-WiFi-Karten.

Wie kann ich denn erkennen, ob ein Slot diese Anbindung hat, oder nicht.
Im Forum gibt es mehrere Benutzer, welche das Gigabyte Z590i Vision D im Einsatz haben und dort funktionierte der Austausch scheinbar ohne Probleme.

Also habe ich überlegt mein MB gegen das Z590i Vision D zu tauschen, allerdings kann ich wenn ich die beiden Boards vergleiche keinen Unterschied fest stellen:

Link

Bei beiden Boards sind die folgenden "Erweiterungsslots" gelistet, wobei der letzte Eintrag der für die integrierte WiFi Karte ist: (Quelle Geizhals)

1x PCIe 4.0 x16, 1x M.2/M-Key (PCIe 4.0 x4, 2280/2260),

1x M.2/M-Key (PCIe 3.0 x4/SATA, 2280/2260, Rückseite),

1x M.2/E-Key (Intel CNVi, 2230, belegt mit WiFi+BT-Modul)

Auf GitHub hat bspw. SchmockLord ebenfalls eine EFI gepostet mit dem Gigabyte Z590i Vision D in der er die originale WiFi Karte ersetzt hat.

Zitat von GitHub

Wifi/BT: Intel AX201, replaced by a Broadcom BCM94360NG for macOS Compatibilty. Works out of the box. The BCM94360NG fits into the original WiFi-card housing and sits under the IO-shield. Original antennas fit.

Ich habe gesehen es gibt so Adpater Karten für einen normalen M2 Steckplatz wo ich dann die Wifi Karte installieren kann - das sollte bei meinem Board aber funktionieren, oder ?

kann mir hier ggf. jemand ein Adapter empfehlen, gerne mit Link

SchmockLord das Gigabyte Z590i Vision D hat bei Geizhals dieselbe Beschreibung des Steckplates wie das Aorus Ultra.

Du hast die WiFi Karte doch ebenfalls hinter der IO Blende direkt mit der originalen getauscht, oder?

Ich kann mir nicht richtig erklären warum unter Windows BT erkannt wird und WiFi nicht - also wenn der Steckplatz nicht kompatibel ist dürfte doch auch gar nichts erkannt werden?

Ich habe gerade mal die genaue m2 Beschreibung meines alten Boards und des neuen raus gesucht:

Gigabyte Z590 Vision D

1x M.2/ E-Key (PCIe/ Intel CNVi, 2230, belegt mit WiFi+BT-Modul

Gigabyte Z590i Aorus Ultra

1x M.2/ E-Key (Intel CNVi, 2230, belegt mit WiFi+BT-Modul

Hier scheint es doch einen Unterschied der Steckplätze zu geben - kann es daran liegen?

CNVi Slot steht bei beiden, aber der eine ist ein PCIe Slot gewesen.

Ich hatte zuvor ein Gigabyte Z590 Vision D Board im Einsatz und dort die BCM94360NG Karte direkt in dem M2 Slot angeschlossen das funktionierte sowohl für Windows als auch für Mac.

Jetzt bei dem neuen Board habe ich alles gleich angeschlossen - der Slot sitz hier wohl unter den Antennen und nicht unter einem m2 festplattenslot.

Hallo zusammen,

ich habe heute meinen neuen Build zusammen gestellt und dort auch wieder meine BCM94360NG in einem Gigabyte Z590i Aorus Ultra verbaut.

Nach der Windows 11 Installation ist mir aufgefallen, dass WiFi nicht erkannt wird - Bluetooth wird allerdings erkannt und funktioniert ohne Probleme.

hat einer von euch eine Idee wieso BT funktioniert und WiFi nicht mal bei den Netzwerkadaptern erkannt wird? Die neusten Treiber habe ich runter geladen und installiert.

kann es an Windows 11 liegen?

kann es sein das eine der beiden Antennen nicht richtig sitzt, oder würde BT dann auch nicht funktionieren

Vielleicht hatte jemand einmal eine ähnliche Situation und kann hier von seinen Erfahrungen berichten