OpenCore Sammelthread (Hilfe und Diskussion)
- derHackfan
- Unerledigt
-
-
Oh, das habe ich wohl falsch gelesen, ich dachte, die iGPU soll nicht aktiv sein. Sorry, my fault.
-
HAllo,
Könnte mir jemand Helfen? Habe auf meinem Unraid Server erfolgreich Big Sure installiert.
Es geht um das Mainboard GA-X99-Ultra Gaming mit der Grafikkarte RX570
Ich bekomme die HD Soundkarte alc 1150 nicht zum laufen.
-
Kankea In deiner config.plist bei DeviceProperties->Add ist der Wert 99 der layout-id als 'Zahl' deklariert. Es muss jedoch 'Daten' sein (4 Byte). Den Zahlenwert 99 kannst du mit dem Hackintool->Calc zum Hexwert umrechnen und diesen Wert dort, gefolgt von 6 Nullen, in deine config.plist eintragen.
Eine andere möglichkeit wäre, die layout-id als boot-arg einzutragen alcid=99. Dann entfällt das umrechnen zu Hex und der Eintrag in den DeviceProperties ist obsolet und kann gelöscht werden.
Dort ist alles schön beschrieben -> https://dortania.github.io/Ope…ml#finding-your-layout-id
-
Ich hab mal unter Linux mir die soundkarte anzeigen lassen siehe Anhang.
Und höchst wahrscheinlich wird MAc auch die Intel HD Audio Treiber brauchen ? In Windows wird er aber als alc1150 angezeigt und realtek HD treiber funktionieren einwandfrei.
Gibt es spezielle mac kexts für Intel HD audio?
-
Wenn Du schon im Linux bist, dann mach doch mal einen Codec-Dump mit folgendem Befehl im Terminal unter Linux:
Die auf dem Desktop ausgegebenen Dateien postest Du dann hier. An Hand dieser Dateien sieht man dann auch, ob es wirklich alc1150 ist.
Im alc1150 in der AppleALC ist layoutID 99 für ein Gigabyte GA-Z97X-UD5H konfiguriert, was passen kann, aber nicht muss, da die Hersteller bei fast jedem Rechner irgendwas ändern, was die Audio-Knoten betrifft.
Die Probleme mit der Hex-Umrechnung in den Properties solltest Du aber erst einmal abklären, bzw. wie karacho schon schrieb, mit Bootflag alcid=99 braucht es keine Umrechnung.
Edit:
Hab ich vergessen, Du hast nicht wirklich ein IntelHD Audio, höchstens für HDMI, betreffs HDMI der iGPU.
Der normale Audio-Chip ist sicher ein Realtek, der durch den Intel-Controller gern versteckt wird, gerade bei den neueren Rechnern. Hier ist oft sogar ein FakePCIID nötig, um den Realtek-Chip anzusprechen.
-
Die Datei wurde erstellt unter Unraid gestarteten linux installations Stick.
Die Soundkarte wurde durchgeschliffen.
Wenn erwünscht kann ich das gleiche noch mal erstellen direkt gebootet vom Mainboard.
Ich hab noch mal direkt vom Mainboard gebootet und die CodecDump.zip erstellt.
-
Ich hab den Dump mal gewandelt. Es ist alc1150 und auch layoutID 99 in der AppleALC ist von den grundlegenden Knoten für Speaker/LineOut, HP, Mic's gleich und sollte somit halbwegs gehen.
Wenn aber so gar kein Gerät damit angezeigt wird, dann ist da noch was anderes nicht richtig. Vielleicht wirklich mal den empfohlenen Bootflag alcid=99 verwenden/testen!
Evtl. stimmt im ACPI-Bereich (DSDT/SSDT) noch was nicht, weil es evtl. kein HDEF-Device dort gibt. Ob HDAS to HDEF als Patch noch nötig ist, kann ich von hier aus natürlich nicht sagen, wobei teurere AppleALC's wohl sogar schon HDAS erkennen.
Aber Stop, in deiner config vom OC wird sowohl Lilu/AppleALC geladen, als auch VoodooHDA steht auf Yes.
Ich denke so gehts sicher nicht.
-
Hätte jemand von den Profis Lust und Zeit per Anydesk sich drauf zu schalten und sich das mal anschauen? Ich bin nicht so der MAc User, mache es für einen Freund sitze schon 3 Tage will natürlich das er auch Sound nutzen kann.
-
um den NVRAM zu löschen, benötige ich auf beiden ThinkPad's jeweils Unterstützung durch Clover + F11, weil OC weder mit CleanNvram.efi, noch ResetSystem.efi den an sich funktionierenden NVRAM löschen können. Das betrifft alle Versionen, die ich bisher auf ThinkPad's benützte, aktuell OC 0.7.2.
Hat jemand eine Rat, was an der EFI verbessert werden könnte?
Oder ist das Problem bei ThinkPad's ein generell hinzunehmendes?
-
Hab da ein Problem beim booten.
Ich habe in der config.plist den Wert NVRAM> csr-active-config 00000000 auf FF0F0000 geändert und erfolgreich in "BS" gebootet.
Allerdings habe ich dann einige tage später wieder den Wert von FF0F0000 auf 00000000 geändert, nun ist es so das er im Bootvorgang hängen bleibt.
OpenCore Ver. 0.7.2. BigSur 11.5
Wenn "BS" gestartet wird unter der funktionierenden. "csr" FF0F0000 erhalte ich hier ein Fehlerbericht
panic(cpu 0 caller 0xffffff800f828fa6): "Rooting from the live fs of a sealed volume is not allowed on a RELEASE build\n"@/System/Volumes/Data/SWE/macOS/BuildRoots/d7e177bcf5/Library/Caches/com.apple.xbs/Sources/apfs/apfs-1677.141.1/kext/apfs_vfsops.c:2047
Backtrace (CPU 0), Frame : Return Address
0xffffffa04fb8aec0 : 0xffffff800c68e04d
0xffffffa04fb8af10 : 0xffffff800c7d4e13
0xffffffa04fb8af50 : 0xffffff800c7c540a
0xffffffa04fb8afa0 : 0xffffff800c632a2f
0xffffffa04fb8afc0 : 0xffffff800c68d86d
0xffffffa04fb8b0e0 : 0xffffff800c68db63
0xffffffa04fb8b150 : 0xffffff800ce9dc0a
0xffffffa04fb8b1c0 : 0xffffff800f828fa6
0xffffffa04fb8b9b0 : 0xffffff800f832357
0xffffffa04fb8b9e0 : 0xffffff800c91954c
0xffffffa04fb8bb60 : 0xffffff800cbd5473
0xffffffa04fb8be80 : 0xffffff800c6bc577
0xffffffa04fb8bfa0 : 0xffffff800c63213e
Kernel Extensions in backtrace:
com.apple.filesystems.apfs(1677.141.1)[242980A5-2BD9-3F6C-85A9-59DC3D26221C]@0xffffff800f7ac000->0xffffff800f91bfff
dependency: com.apple.driver.AppleEFINVRAM(2.1)[DC3B80FD-4D23-3608-8AA2-9C526D44F5D3]@0xffffff800dafe000->0xffffff800db07fff
dependency: com.apple.driver.AppleEffaceableStorage(1.0)[F406C391-FAEB-3AA0-B21B-081304E18302]@0xffffff800db11000->0xffffff800db16fff
dependency: com.apple.iokit.CoreAnalyticsFamily(1)[89D4D6FD-0230-3AF2-9B37-12A0BE51DFE4]@0xffffff800df6d000->0xffffff800df73fff
dependency: com.apple.iokit.IOStorageFamily(2.1)[6CD2A6EC-9FFC-370D-8FEE-C8016E5C6BBA]@0xffffff800f26f000->0xffffff800f280fff
dependency: com.apple.kec.corecrypto(11.1)[8CCFD77D-8824-3F8C-82D3-AF011B1C38FC]@0xffffff800f949000->0xffffff800f9dafff
dependency: com.apple.security.AppleImage4(3.0.0)[D403F64D-BB8C-3CE2-B75A-94982F595EC4]@0xffffff800db7d000->0xffffff800db8dfff
Process name corresponding to current thread: kernel_task
Boot args: -v darkwake=2 agdpmod=pikera alcid=15 brcmfx-country=DE
Mac OS version:
Not yet set
Kernel version:
Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64
Kernel UUID: FECBF22B-FBBE-36DE-9664-F12A7DD41D3D
KernelCache slide: 0x000000000c400000
KernelCache base: 0xffffff800c600000
Kernel slide: 0x000000000c410000
Kernel text base: 0xffffff800c610000
__HIB text base: 0xffffff800c500000
System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)
System shutdown begun: NO
Panic diags file unavailable, panic occurred prior to initialization
Hibernation exit count: 0
System uptime in nanoseconds: 5843856888
Last Sleep: absolute base_tsc base_nano
Uptime : 0x000000015e28c695
Sleep : 0x0000000000000000 0x0000000000000000 0x0000000000000000
Wake : 0x0000000000000000 0x0000000bc73e0218 0x0000000000000000
Beim Bootvorgang
-
-
cobanramo, mir ist etwas ähnliches aufgefallen: Wenn ich von Monterey per Neustart in Catalina (mein Arbeitssystem) boote, dann funktionieren Maus und Tastatur im macOS Login-Screen nicht - im OpenCanopy ist alles bestens. Maus und Tastatur sind per USB an einem Thunderbolt-Display angeschlossen. Ich muss dann den Thunderbolt-Stecker ziehen und wieder verbinden. Danach funktioniert wieder alles. Beim Neustart von Catalina in Catalina / Monterey tritt dieses Problem nicht auf. Auch beim Einschalten (Kaltstart) des Rechners funktioniert in beiden Systemen alles wie gewollt. Ich führe das bisher noch auf Monterey zurück, da es nur beim Wechsel von Monterey zu Catalina auftritt.
-
12.0 Beta 6 regelmäßig die BT Maus tot
Unter Monterey Beta 4 oder sagen wir mal bis Beta 4 liess sich bei mir mit BCM94360NG die Bluetooth nicht aktivieren, obwohl das ding ja OOB läuft. ich stempelte es unter Beta probleme ab. Mit Beta 5 tat es wie es soll, jetzt mit Beta 6 auch.
Ehrlich gesagt konnte ich nicht ausgiebig testen aber bisher tut es was es soll.
im OpenCanopy ist alles bestens. Maus und Tastatur sind per USB an einem Thunderbolt-Display angeschlossen. Ich muss dann den Thunderbolt-Stecker ziehen und wieder verbinden. Danach funktioniert wieder alles.
Das wiederum ist ne klassische Thunderbolt Initialisierung problem denke ich, meins liegt definitiv nur unter OpenCanopy im zusammenhang mit Monterey. Hab das Gefühl der schaltet den auf eine art ab so das beim nächsten start OpenCore nicht mehr initialisieren kann bis eben ein anderes Betriebsystem gestartet und initialisiert hat.
-
Hab leider ein ähnliches Problem. Im BIOS und unter OpenCanopy funktioniert meine Apple Bluetooth Maus und Tastatur, sobald es aber ins MacOS bootet verliert es die Verbindung. Dann hilft nur noch Neustarten oder das neu verbinden mithilfe einer Kabelmaus.
-
sobald es aber ins MacOS bootet verliert es die Verbindung
Welcher MacOS? welcher Wlan/Bluetooth Karte? Das wiederum scheint aber konfigurations problem zu sein.
Gruss Coban
-
Sodele. OC 0.7.3 Final Release läuft hier. Super, dass man jetzt auch Linux dank den Treibern OpenLinuxBoot.efi und ext4_x64.efi direkt und ohne Grub chainloading booten kann. Nice Job und ein Dankeschön an die Developer dafür.
P.S. Alles weitere dazu ist in der Differences.pdf audführlich beschrieben.
Edit: Die ScanPolicy ist dementsprechend noch anzupassen, wenn nicht gerade 0 benutzt wird.
-
Achtung beim Update auf die heute veröffentlichte OC0.7.3 RELEASE Version:
die gröbste Änderung an der config.plist liegt diesmal hier:
ALT:
NEU:
Habe ich persönlich beim ersten "überfliegen" übersehen! Booten war dann erstmal nicht mehr.
Nach dem Anpassen booten wieder fehlerfrei möglich.
U HAVE BEEN WARNED !
PS: ich finde diese Anpassung gut, denn so kann man mehrere Driver in die Config aufnehmen und via "Enabled 0/1" ein- und ausschalten.
-
Mork vom Ork ich meine das wäre bei der Anfang der Woche erhältlichen nightly schon der Fall gewesen.
gibt es nennenswerte Unterschiede, die mich bewegen müssten auf das Release zu gehen oder reicht das erst mal? -