Beiträge von Keksfamilie

Ich wurde gerufen Äh ja also falls du dich jetzt für Catalina entscheidest, dann ist das die einfachste Variante.

Falls du doch nochmal bei Mojave Unterstützung brauchen solltest, geb ich mein bestes

asr10 hatte heute kurz die Möglichkeit das mit einem Monitor der Ton über HDMI macht zu testen: Es taucht kein Audio Device für HDMI auf.

Hatte leider nicht genug Zeit, das genauer zu debuggen und hatte auch noch HDMI -> DVI-D Adapter dazwischen, das find ich auch immer super unsympathisch

Ich schaue, ob ich da nochmal Zugang zu dem Monitor bekomme die nächsten Tage

Sah für mich OOTB gut aus, SC/MC-Turbo stimmt, taktet beim nix tun runter und Sleep funktioniert ohne Probleme.

MacPeet ah so layout-id ist die 100

Es geben alle Ports ton aus/empfangen welchen, ich kann dir leider nicht sagen, ob die ganzen Ports fürs 5.1 Setup korrekt belegt sind, sound kommt auf jeden fall raus.

Moin,

jo ich habe sei ein paar Tagen Mojave auf Z490/Comet Lake (CML) am laufen (sogar mit nem 10600K wie du). War definitiv ein lehrreicher und zeitaufwändiger Weg bis alles lief (Hab nur noch Probleme beim boot mit zwei Monitoren, einen später anstecken is kein Problem).

Die CPU und iGPU müssen gefaked werden und du musst ein passendes SMBIOS finden, bei mir war es ein iMac 19,1, ich bin aber auch auf EFIs von Leuten gestoßen die mit einem iMac 18,3 und High Sierra unterwegs waren (mit dem SMBIOS habe ich aber keine Grafikbeschleunigung bekommen).

Onboard-Audio funktioniert dann vermutlich auch erstmal nicht, da war ich zuletzt hier am troubleshooten, die Methode die im letzten Post beschrieben ist sollte dann aber auch bei dir funktionieren: AppleHDA scheint nicht zuverlässig zu laden

Also: Ist machbar, läuft bei mir auch sehr stabil mit guter Performance, aber ist etwas knackig und viel ausprobieren, besonders wenn es dein erster Hackintosh ist. (War bei mir auch mein erster mit OpenCore, hab davor aber schon mal ein Paar auf Clover Basis gehabt)

So, jetzt kann ich mal in Ruhe tippen

MacPeet 709D0000

asr10 gute Frage... ich habe leider keinen Monitor mit Lautsprechern oder Kopfhörerausgängen Kanns also überhaupt nicht testen

Bei Comet Lake wird ja wie schon festgestellt das Audiogerät hinterm PCH "versteckt" und gibt ne Device-ID vom PCH aus. Die kennt MacOS nicht und was der Bauer nicht kennt frisst er nicht Daher muss also die ID gefaked werden. Da reicht es aber nicht, das über die DeviceProperties zu machen, ich zitiere CorpNewt:

Zitat

When you fake a device-id in DeviceProperties, it fakes it "at the surface" - i.e. it can be used to get another kext to load by matching an existing IOPCIMatch within the target kext

Sometimes there are further checks within the kext though - which would either need to be patched, or worked around.

Daher ist der Weg, der ganz oft zu finden ist, die ID auf einem "tieferen" Level zu faken, das geht mithilfe des FakePCIID.kext von RehabMan. Das alleine tut erstmal nichts, bietet aber eine Schnittstelle an die man sich mit anderen kexts hängen kann. Da gibts z.B. den bekannten FakePCIID_Intel_HDMI_Audio.kext. Dieser matched auf verschiedene IOKitPersonalities:

und injected dann entsprechend die gefakte ID.

Das matchen auf die IOKitPersonalities klappt halt bei Comet Lake (und anderen neuen Plattformen dann wohl auch) nicht, weil die natürlich andere IDs haben.

Nun gehen dann viele hin, setzen eine device-id in den DeviceProperties wie z.B. 70A10000 (wäre im Bild die zweite), was dann dafür sorgt, dass die IOKitPersonality im FakePCIID matched, damit dann wieder eine device-id gefaked werden kann Doppelt gemoppelt. Man kann das ganze dann etwas sauberer machen, in dem man keine DeviceProperty nutzt um die device-id zu faken, sondern einen kext baut, der direkt auf die vanilla/originale device-id matched.

Als Template kann man einen der vorhandenen IOKitPersonality Einträge nehmen, alle anderen rauslöschen (werden ja nicht benötigt) und dann IDs austauschen.

In meinem Fall habe ich folgendes als Vorlage genommen, meine vanilla device-id war die c8060000:

und geändert in:

cJ0AAA== entspricht der id 709d0000.

Bei dem IOPCIPrimaryMatch dran denken, dass der Vendor mit in den String kommt (weil Intel hier 8086) und die byte-order einhalten.

Die beiden Kexts dann nicht vergessen in der OC Config zu aktivieren

Ich hoffe ich habe das jetzt so alles korrekt wiedergegeben, ist eigentlich kein Hexenwerk.

Ah ok. Habe grade gesehen, dass die SSDT-HPET als eigener Table in MaciASL gefunden wird, scheint also zumindest geladen zu werden. Im IORegistryExplorer finde ich das HPET device:

EDIT:

So inzwischen eine ganze Menge schlauer geworden und Audio geht endlich Die HPET fixes brauche ich mit meiner Platform anscheinend nicht und die IRQs waren nicht das Problem. In meinem Fall reicht es, die PCIID für das HDEF device mithilfe von rehabmans FAKEPCIID.kext zu faken. Habe mit CorptNewts Unterstützung einen Injector Kext für FAKEPCIID gebaut der den oft benutzten Rundumschlag von FAKEPCIID + FAKEPCIID_Intel_HDMI_Audio + fake der device-id in den DeviceProperties etwas eleganter mit weniger bloat löst. Werde dazu morgen noch was ausführlich schreiben um das dokumentiert zu haben Aber jetzt gehts erstmal in die Heia für mich

Wenn Änderungen durch eine SSDT vorgenommen werden, sind die dann auch in der aktuellen System DSDT sichtbar (die, die sich öffnet wenn man MaciASL aufmacht)? Oder tauchen da nur Renames auf.

So viel Hilfe, so viel zu lesen Fettes Danke euch allen schon mal.

Jetzt komme ich erstmal wieder mit den dummen Fragen:

Ihr schreibt ja davon, dass der Rename von _CRS zu XCRS nicht an der richtigen Stelle ausgeführt wird. Wenn ich mir das dann mal in live am System anschaue, sieht das derzeit so aus:

Sieht für mich als Dummie so aus, als ob das schon renamed wurde? Nach was muss ich denn suchen und dann mithilfe der Skips nach hinten verschieben?

Habe den SSDT-HPET auch mal versucht an MacPeet 's Variante anzugleichen (einfach _CRS durch BUF0 ersetzt), also das Zeug in BUF0 schreiben zu lassen anstatt in _CRS. Aber mit wenig Erfolg, es tat sich am BUF0 genau: nix. Falls ich das alá MacPeet mache, müsste ich aber den rename auch rausnehmen oder?

Soweit ich das verstehe, will ich, dass am Ende beim aufrufen der _CRS Methode die IRQNoFlags rausfallen. Da _CRS in MacPeets Fall einfach das BUF0 Objekt (? sind wir hier in der OOP? :D) returned und das BUF0 die IRQNoFlags hat, funktioniert das.

Der Ansatz von SSDTTime ist es die "alte" _CRS Methode umzubenennen damit die "aus dem Weg" ist und dann seine eigene _CRS Methode einzufügen die direkt die IRQNoFlags besitzt, ohne auf BUF0 zurückzugreifen.

Versteht das mein Gehirn soweit richtig?

ozw00d Da hast du Recht... was man so online findet, ist CML auf 0x1b,0x0.

Ich bin nach dem gegangen, was mir gfxutil ausgespuckt hatte:

Warum weicht das bei mir ab?

MacPeet Danke für die Erklärung,

einmal Pre-SSDTTime:

RTC hatte die 8, TIMR die 0. Nach kopieren der Patches in ACPI/Patch sieht das wie folgt aus:

Die 0 und 8 wurden also erfolgreich aus den Devices entfernt. Wenn ich dich richtig verstanden habe, sollten die jetzt an das HPET Device gebunden werden mithilfe des HPET Patches. Den habe ich also auch in den ACPI Ordner geschoben und in die config.plist hinzugefügt. Da steht als Kommentar noch dabei "HPET _CRS (Needs _CRS to XCRS Rename)", dieser wurde auch in ACPI/Patches eingetragen. Das HPET Device scheint aber nicht die IRQNoFlags zu übernehmen (auch wenn diese im SSDT-HPET.aml deklariert werden):

Habe mal die Ergebnisse die SSDTTime erzeugt hat angehängt (da ist auch meine Vanilla-DSDT dabei) und mein aktualisiertes EFI. Hab ich da noch was übersehen?

MacPeet Hi, ich habe das neue Update heute schon voller Vorfreude ausprobiert gehabt... ne

Ich habe auch bereits alle Layout IDs die für den ALC892 ausprobiert die gelistet sind, aber ohne Erfolg. Ich dachte, AppleHDA taucht trotzdem auf, auch wenn mit zu wenigen weiteren Children? Unabhängig davon habe ich es aber mit keiner ID geschafft das zum laufen zu bringen (und auch nie Ausgänge/Eingänge bekommen).

Codec Dump(s) (0 ist Realtek, 2 ist Intel HDMI) habe ich soeben angefertigt und hier angehängt Kann mit denen selbst nicht so viel anfangen, hast du da ne Resource zum nachlesen? Oder kannst mir selbst erklären was man jetzt mit denen macht?

Ja genau, DP ging OOTB. Habe da mal die Einträge rausgenommen und danach auch mal den port count patch reingesetzt... Hatte nichts gebracht, verhält sich wie vorher.

apfelnico Hi, da hast du recht, sorry, da hab ich den Screenshot verhauen.

So hier ein Screenshot ohne Suchfilter, aber auch ohne AppleHDA:

Habe da noch eine Vermutung entwickelt, das Audiodevice "versteckt" sich ja hinter dem PCH, in meinem Fall ist das ein Comet Lake PCH, welches ich aber unter Mojave betreibe. Während des Bootvorgangs taucht die Warnung "Unknown PCH" auf, was bis jetzt keine Probleme bereitet hatte. Könnte das dafür sorgen, dass sich AppleHDA da nicht attachen kann?

AppleALC kommt augenscheinlich damit klar, hier der Auszug aus dem Hackintool:

6c8 taucht in den Debug Logs als controller 1 wie folgt auf (controller0 ist die iGPU):

hackmac004 bin mit Mojave unterwegs, da gibts die 0x9BC5 noch nicht.

Hallo zusammen,

habe auch wie meine Vorredner das Problem, dass ich nach dem Start nur einen funktionierenden Monitor habe (und den nicht lange). Habe das mal abgefilmt.

Aus- und Einstecken eines beliebigen Monitors behebt das Problem.

Wie man sehen kann ist das eine Display an Connector 0, das andere an 2:

Und ich habe auch schon probiert mit und ohne CNConnectorAlwaysConnected das Problem zu lösen, ohne Erfolg.

Derzeit sieht das in der OC plist so aus (con 0 ist HDMI, da musste ich pipe und busid ändern, con2 ist DP der direkt funktionierte):

Habe auch igfxonln=1 und igfxagdc=0 gesetzt.

Das ist leider nicht das Problem, selbst wenn die layout-id Mist wäre, sollte sich AppleHDA trotzdem an das HDEF device attachen. Habe sicherheitshalber mal alle layouts ausprobiert, aber nie taucht AppleHDA auf.

Servus

Zitat von OSX-Einsteiger

Hast du es schon mit der

device-id 9B3E0000 probiert ?

Ja, hatte ich meine ich auch schon drinne gehabt... Hab dann mal das SMBIOS geändert auf nen iMac19,1 und es funktioniert

Ich tue mal so als wäre nie was passiert

Vielen Vielen Dank dir! Ich werf mal ein Bier rüber

Jetzt läuft fast alles auf dem Hacki, lediglich Audio gibts noch nicht. Wenn du grade so nen Lauf hast, vielleicht fällt dir da noch was ein? AppleHDA scheint nicht zuverlässig zu laden

Guten Mittag,

Ich baue grade einen Hackintosh aus einem i5-10600K (Comet Lake) auf einem MSI Z490-A Pro. Der i5-10600K hat eine UHD 630 iGPU, aber genau diese bekomme ich nicht "normal", also außerhalb des VESA software rendering modus zum laufen.

Mojave startet unter Comet Lake nativ nicht, daher musste ich eine ältere CPU emulieren, Cpu1Data steht auf EB060800 00000000 00000000 00000000.

Die UHD 630 gab es ja bereits schon in Coffee Lake, sollte also auch in Mojave laufen? Die device-ids scheinen sich aber trotzdem geändert zu haben von Coffee Lake zu Comet Lake. Der 10600K ist die 0x9BC5, ein 8600K die 0x3E92.

Was ich schon probiert habe:

- als device-id c5 9b 00 00 (der echte Wert) benutzen, macht einen Fallback auf VESA, vermutlich ist die device-id in Mojave noch nicht bekannt.

- WhateverGreen Doku besucht und eine CFL device-id genommen (probiert mit 0x3E9B und 0x3E92) und Framebuffer 0x3E9B0007, liefert keinen Erfolg, hier ein "Screenshot", danach taucht ganz kurz das Apple-Logo auf, es wird wieder schwarz, ich sehe noch kurz die Initialisierung der Netzwerkkarte. Dann erscheint ein Cursor links oben (den ich auch mit der Maus bewegen kann) und der flackert auf schwarzem Hintergrund, mal ist er auch wieder kurz weg, ich sehe wieder die Initialisierung der Netzwerkkarte bevor wieder der Cursor mit schwarzem Hintergrund auftaucht.

- Die Methode über das Hackintool sich die DeviceProperties erzeugen zu lassen alá igpu framebuffer patching blackscreen problem beheben. Als Generation CFL ausgewählt:

und Spoof Video Device ID wie folgt:

Bei den Connectors habe ich auch schon Bus-IDs umgestellt (1 2 3, 2 3 4, etc...) oder auch mal nicht angefasst, laut Anleitung erkennt WEG das inzwischen aber schon ganz gut? Und theoretisch habe ich ja auch mit der zweiten Methode "Erfolg" gehabt, ein Cursor war sichtbar. Verbunden bin ich via DP.

Bei den erzeugten Patches vom Hackintool hatte ich nicht mal einen Cursor zu sehen, da tat sich nach dem Netzwerk nichts mehr.

Im BIOS hab ich das shared memory auf 64MB eingestellt, sollte also eigentlich ohne Tricks auskommen, habe es aber auch mit dem framebuffer-stolenmem 00003001 probiert.

Hat da schon jemand mit Erfolg gehabt oder kann mich etwas an die Hand nehmen?

Viele Grüße

Keksfamilie

Hallo zusammen,

ich habe Probleme auf meinem Hackintosh Sound zum laufen zu bekommen.

In den Soundeinstellungen taucht kein Ein- oder Ausgang auf und wenn ich einen Blick auf den IORegistryExplorer werfe, sehe ich, dass ein HDEF Device auftaucht, aber kein untergeordnetes AppleALC:

So sollte das wohl eigentlich aussehen (Quelle: Dortanias Guide):

Ich habe auch immer wieder den Fall, dass AppleHDA nicht geladen wurde:

Beim nächsten Reboot taucht es mit etwas Glück aber wieder auf, ändert aber nichts daran, dass ich keine Geräte bekomme.

Habe schon mit diversen Werten von alc-delay rumprobiert, selbst bei 3000ms (maximum) tut sich nichts.

Kann mir jemand weiterhelfen?