Beiträge von LetsGo
-
-
Hast du SIP deaktiviert?
-
Was hast du bei SIP eingestellt?
-
Update auf Monterey Beta8 durch!
neueste OC 0.7.4 Version commit 28e0afc
Damit ich das Update angezeigt bekommen habe, einfach SecureBootModel=j137 gesetzt. (iMacPro1,1 SMBios)
während des Download SecureBootModel=Disabled gesetzt und nach dem Download Restart. Update lief ohne Probleme durch. Jetzt nutze ich wieder SecureBootModel=Default.
kein iMac17,1 Trick nötig
kein AdviseFeatures=true nötig (zumindest bei Update nicht, wird möglicherweise bei Full Installern benötigt)
Ob SecureBootModel=Disabled während des Updates überhaupt nötig ist kann ich nicht sagen, aber so lief es zumindest ohne Probleme durch.
-
Die Bilder findest du in der EFI Partition. Also einfach mounten.
Wlan nutze ich nicht. Welche Karte nutzt du? Ansonsten denke ich gibt es für fast jede WIFI Karte schon einen Thread hier im Forum. Einfach mal mit der Suchfunktion stöbern.
Und meinst du mit PSX eventuell PXSX. Da könnte es sich dann möglicherweise um einen ASMedia USB Controller handeln. Vielleicht muss man da etwas beim Mapping machen.
-
Habe zwar gestern das Update mit dem iMac17,1 Trick gemacht. Aber ich habe eben die Device-ID (j137) nur gebraucht, damit ich das Update überhaupt angeboten bekam. Schätze mal iMac17,1 war wegen der T2 Firmware nötig und das Update wurde erfolgreich mit SecureBootModel=disabled durchgeführt.
-
Ich denke mal du musst bei der Stick Installation noch SecureBootModel auf disabled setzen. Advise Features sollte auf yes sein.
Und halt die neuste Nightly mit dem T2 Firmware Update nehmen.
Ist aber auch nur eine Vermutung.
-
Und mit welcher Einstellung bei SecureBootModel wurde dir das Update angeboten? default?
-
Ich denke, dass AdviseFeatures nur beim Full Installer notwendig ist. So wie ich das verstehe braucht man es bei Updates nicht. Kann mich aber auch irren.
-
Über das Problem (Update wird nicht angezeigt) gibt es sehr viel. Auch hier. Ich und andere mit iMacPro1,1 SMBIOS haben bei SecureBootModel j137 (statt default) eintragen müssen, um das Update angezeigt zu bekommen. Und das steht auch auf den vorherigen Seiten. Je nachdem, welches SMBIOS du verwendest, musst du halt den entsprechenden Wert eintragen.
-
Gut möglich, dass das jetzt ohne den iMac17,1 Trick funktioniert, da im neuesten OC Nightly die T2 Firmware aktualisiert wurde.
-
Das mit der Cpuid1Mask haben wir schon in seinem anderem Thread behoben. Das Programm passt die config.plist an die aktuelle sample.plist an (kann die aber natürlich nicht einfach selbständig ausfüllen, falls irgendwelche neue Einträge dazu kommen).
Der TE hat halt einfach nur die config.plist aktualisiert, aber nicht entsprechend angepasst. Da sollte man schon mit der OC Configuration.pdf Hand in Hand arbeiten. Und wie du sagst werden die Treiber aktualisiert.
An sich ein wirklich gelungenes Programm, da man mittlerweile auch die "Database" updaten kann. So wird das aktuelle OC geladen und in die App unter Contents/MacOS kopiert.
Die hinterlegten SSDT`s sind halt einfach die Prebuild OC SSDT`s + anscheinend ein paar "3rd party".
-
Mit dem Tool hat er zuvor die EFI repariert. Aber da er von OC 0.6.6 auf OC 0.7.4 umgestiegen ist, kann ich mir vorstellen, dass da schon einiges daneben gegangen ist. Ich würde an seiner Stelle die config.plist neu aufbauen.
Da war danach z.B: eine Datum/Zeitangabe bei Cpuid1Mask eingetragen, welche dort absolut nichts zu suchen hat.
Zwischen OC 0.6.6 und OC 0.7.4 gibt es sicher erhebliche Unterschiede zu beachten. Und die das Tool nicht einfach automatisch handhaben kann.
-
-
-
Außer, dass du es mit dem von mir verlinkten Tool mal versuchst weiß ich auch nicht weiter. Ich glaube nicht, dass es an der OC Version liegt, da ja sonst etliche Leute hier im Forum betroffen wären.
Vielleicht liegt es an einem deiner angeschlossenen Datenträger. Würde mal einen nach dem Anderen weglassen und gucken ob der Fehler danach immer noch besteht.
-
Kann gut sein, dass du dein SMBIOS in der USBMap.kext (plist) ändern musst. Ich habe zwar mit dem Tool noch keinen kext erstellt, aber gut möglich, dass dieser auch SMBIOS abhängig ist. Kannst auch hochladen, dann sehe ich mir das an.
Oder einfach Rechtsklick auf Kext ->Paketinhalt anzeigen -> Contents -> info.plist.
-
Hardwaredefekt kannst du ausschließen? Wackelkontakt am USB Port z.B? SSDT-USBX.aml benutzt du? Hat es beim USBMap Tool ein Update für 11.3+ gegeben und du benutzt noch eine ältere Version?
Ansonsten würde ich mal versuchen mit https://github.com/USBToolBox/tool die USB Ports unter WIN neu zu mappen.
Mit dem Tool kann man zwei verschiedene Kexte erstellen. Den UTBMap.kext und USBMap.kext.
Der UTBMap.kext muss in Verbindung mit dem USBToolBox.kext (hat einen executable path und ist einfach zum downloaden!) verwendet werden. Bei Verwendung dieser Kombi sollte SSDT-RHUB auch überflüssig sein.
Der USBMap.kext (SMBIOS abhängig) ist eine Standalone Lösung.
Für die Erstellung beider Kexte ist nur einmal in den Optionen etwas umzustellen. Somit kannst du bequem beide Kexte zugleich erstellen.
Man kann auch einen bereits existierenden Kext dementsprechend umwandeln, um Ihn mit USBToolBox zu verwenden. https://github.com/USBToolBox/kext
Ich hänge mal meine beiden Kexte an, damit du den Unterschied siehst. So hilft es dir eventuell bei der Konvertierung, falls du deinen bereits benutzten Kext umwandeln möchtest.
-
5T33Z0
Frage: Wenn ich z.B. den letzten OCAT (20210921) benutze, kann man irgendwo die OC Version auswählen. Falls man z.B. eine OC 0.7.2 EFI bearbeiten möchte. Sonst werden ja verständlicherweise immer Fehler angezeigt.Hat sich erledigt.
-
Habe zwar den Kext mit einem anderen Tool erstellt, aber bei mir hat sich nach den Updates auf 0.7.2 bzw. 0.7.3 nichts geändert.
Den XHCIPortLimit Quirk hast du nicht versehentlich beim Update aktiviert.
Ansonsten würde ich im Hackintool mal den Besen und refresh drücken um sicher zu gehen, dass die Ports wirklich nicht mehr so erscheinen, wie du sie gemappt hast.
SMBIOS Änderung hast du auch nicht vorgenommen, oder?