Beiträge von SuDoDmz

    Echt nicht. Aber dein Tipp mit Dortania hat Abhilfe geschafft! Ich musste lediglich die ECs ausmisten, die nicht zu meinem System passen und die SSDT um ein MethObj ergänzen, dann noch das EC unter den LPCB und fertig ist die Brühe :)

    In der Zwischenzeit bin ich auch dem LPCB selbst auf die schliche gekommen: im neuen AppleLPC.kext fehlen neuerdings ein ganzer Haufen Einträge (sind nur noch die Uraltsysteme a la ICH10, ICH9 und einige wenige NVIDIA vorhanden), also musste meine SSDT-LPCB kurzerhand dran glauben. Jetzt kann ich anfangen Windows zu "debuggen" und mir eine ältere Version des Logitech G Hub zulegen. Seit dem letzten Update bleibt meine Hardware nämlich nicht mehr auf seinen statischen Einstellungen und friert sogar zeitweise auch ein.


    EDIT: Und die Thunderbolt-SSDT kann ich mir bald vielleicht auch schenken. Hab' im englischen Forum (Name sei ungenannt :D ) recherchiert und einer der eifrigen User hat seit längerem schon angefangen mit dem BIOS zu experimentieren, nämlich die TBPXE von Apple ins Gigabyte BIOS zu integrieren (daher auch die DMAR.aml für VT-d und Eth. über TB und weiterhin stabiles WLAN).


    Update: Hab' die EFI im ersten Post mit einem Update versehen (funktionierende SSDTs nun enthalten). Nächstes Update (hoffentlich), wenn auch Windows lauffähig ist unter OC.

    Nee keine Ironie, auch kein Sarkasmus... ;-)


    Warum die EC nicht will sehe ich mit meinem Halbwissen nicht wirklich zielorientiert.

    Halbwissen würde ich das nicht nennen. Immerhin hast du mein RTC lauffähig gemacht :) Ich könnt' schwören das ist wieder irgendeine mikroskopische Kleinigkeit, die ich übersehe. Und dann muss ich die alle nochmal durchtüfteln, um zu sehen, wieso welcher unter Windows geladen wird. Btw. ich war ein bisschen im englischen Forum unterwegs (da hatte ich ja bereits eine OC.zip aus Faulheit heruntergeladen). Die EC bei dem Ersteller dort ist ganz anders deklariert (hab's mal angehängt). Besagte Opencore EFI bootet bei mir sogar Windows, aber bei ihm sind die Gerätschaften HDEF, SATA, IGPU (und vielleicht mehr, hab's jetzt nicht explizit kontrolliert) alle in der config.plist abgelegt, statt, wie bei mir, in SSDTs.


    Ach ja, meine LPCB findet ja seltsamerweise auch keine Verwendung mehr. Da Opencore nicht zu maulen scheint, gehe ich mal davon aus, dass sie geladen wird, aber properties bleibt blank, in der SysInfo ist sie nicht mehr gelistet und der AppleLPC.kext wird entsprechend auch nicht geladen. Ich hab' ein wenig rumgelesen und man scheint das zwar nicht mehr zu brauchen, mich würde aber trotzdem interessieren, wieso das auf einmal nicht mehr läuft.

    Dateien

    • SSDT-EC.aml

      (77 Byte, 63 Mal heruntergeladen, zuletzt: )

    Kann ich machen, aber ich muss ja auch was dazulernen: [meld]





    Deine EC SSDT war nicht so ganz sauber würde ich meinen, teste mal diese:


    SSDT-EC.aml

    Beim EC sehe ich, dass das USBX Device unten angehängt wurde, statt, wie bei mir, in die Mitte geballert :D sollte ich sonst noch was wissen? Was war bei mir "unsauber"?

    EDIT: Ich sehe grad' das USBX Device steht "im Freien" und das EC wird im _SB erstellt, statt im LPCB



    und bei deiner RTC was glaube auch was...bin kein ACPI Experte aber testen kann ja nicht schaden...


    SSDT-RTC.aml

    Und beim RTC erfolgt eine Objektreferenzabfrage vor dem _STA des originalen RTC Geräts. Ferner wird hier das Gerät RTC1 angelegt (bei mir RTC0), komischerweise aber im Scope des originalen RTC. Es sieht zwar so aus, als würde das Device trotzdem am richtigen Platz erstellt werden, aber wäre es nicht besser es direkt außen vor (oder meinetwegen zum Schluss) zu machen statt im Scope des LPCB zu deklarieren? Was macht die SSDT anders/besser, als meine? Was muss ich hier sonst noch wissen?


    liegt meistens daran jo...

    Sarkasmus? :D

    du hast mit deinen SSDTs schon vieles im Programm, das kannst du auch in eine SSDT schreiben und die DTPG Methode in diese integrieren, sowas wie "alles für das Mainboard" und jede Hardware die separat montiert ist dann als separate SSDT, macht es einfacher denke ich, so sind die X299 Tutorials hier auch Unterwegs.

    Hier stehe ich auf dem Schlauch. Meinst du ich soll alle mainboardinternen Geräte in einer SSDT zusammenfassen und jeweilige AICs/PCI-Slots dann separat? Dann hätte ich jetzt nämlich wahrscheinlich eine große SSDT, die nicht geladen wird und wir würden uns alle 'n Wolf suchen :D




    Kleines Update/EDIT: die SSDT-RTCwird jetzt geladen (keine Ahnung, wieso). Das ursprüngliche RTC Device war immer noch vorhanden, also hab' ich die Objektreferenzabfrage rausgenommen und jetzt funktioniert sie ordnungsgemäß (mit nur dem Unterschied zu meiner SSDT, dass die Plätze vertauscht sind, aber hey).


    SSDT-EC nach, wie vor Fehlanzeige. Ich ab' jetzt mal das USBX Device in seine eigene SSDT gepackt und die wird auch geladen, EC will nach, wie vor, ums Verreckens Willen nicht.

    Sodele,


    ich hab' ma hier 'ne Liste zusammengestellt:


    ALS0 - Ambient Light Sensor (hab' ich gemacht, weil ich das Gerät ALSD in der DSDT hab', selbe Adresse)

    DMAR - wegen VT-d

    DTPG - für property injection (hab' ich schon ewig von KGP)

    EC - Das EC Gerät (wird NICHT geladen, mein H_EC Gerät soll hier deaktiviert werden und das EC Gerät entsprechend erstellt)

    HDEF - Umbenennung meines HDAS zu HDEF, Rest kosmetischer Eintrag

    IGPU - Benennt das GFX0 Gerät zu IGPU um, ferner werden hier framebuffer, Anschlüsse etc. eingetragen (IOReg meldet auch, dass entsprechende Treiber benutzt werden)

    IMEI - Umbenennung heci zu IMEI damauch der MEI Treiber genutzt wird

    LPCB - wird seltsamerweise nicht geladen merke ich gerade (kein Eintrag), da wird nämlich AppleLPC drangehängt, komisch (vielleicht wegen des SMCSuperIO.kext, hab' ich erst kürzlich angefangen zu nutzen)

    NOCNVW - deaktiviert das CNVi Gerät

    PLUG - für das plugin-type der CPU

    PMC - für NVRAM

    RTC - Umbenennung meines RTC Geräts zu RTC0 (wird auch im verbose Boot als nicht geladen gemeldet, wie mein EC Gerät!)

    SATA - Umbenennung SAT0 zum aplekonformem SATA

    SBUS - SMBus Gerät

    TB - Thunderbolt Controller (Hotswap, DROM und der Rest)

    THSS - Thermal Controller

    USBW - für tastaturbezogene sleep/wake Probleme

    XHC - Original SSDT-6.aml, bearbeitete System SSDT für USB Mapping (originale DMAR und die SSDT-6 werden in der config ausgeschlossen)


    DSDT reiche ich gleich nach.


    EDIT: ich hab' unter OS X zahlreiche Fehlermeldungen in meiner DSDT festgestellt (ist die originale vom System), liegt vielleicht auch nur am iASL


    In den diversen anderen EFIs werden Injections über die config.plist vorgenommen Ich umgehe das und mache es rein über ACPI. Für bereits vorhandene Geräte habe ich den Eintrag "Scope" zum Ergänzen verwendet, keine Sorge :) lediglich nicht applekonforme Geräte habe ich per _STA zero deaktiviert (mit OS-bedingter Abfrage) und entsprechend ein neues Gerät per "Device (Name gemäß Apple-Nomenklatur)" angelegt.

    Dateien

    • DSDT.aml

      (265,17 kB, 61 Mal heruntergeladen, zuletzt: )

    Jepp, die SSDTs haben alle Zweck :)


    Das habe ich ohnehin noch vor (und, wie schon erwähnt, habe ich bereits einige Verdachtskandidaten), aber ich will ja, dass sie alle funktionieren und ich finde den Fehler nicht.


    DSDT kann ich nachreichen, aber was meinst du mit doppeltem Eintrag?


    Ich weiß, ich wollte das aber rein über ACPI gelöst haben.

    Den Guide kenne ich bereits und auf Clover hatte ich ohnehin keinen Zugriff, ist also 100% Opencore. Bspw. habe ich im BIOS auch VT-d aktiviert, in Opencore DisableIOMapper aber deaktiviert und stattdessen wird eine Custom DMAR.aml geladen. Ich hatte im ersten Post auch bewusst Nico erwähnt, in der Hoffnung, dass er sich zuschaltet. Von ihm wissen ja alle, wie gut er ACPI kann (nicht zuletzt weil ich mir auch damals schon einiges von ihm und KGP abgeguckt hab' :) )

    Servus Hecatomb


    du meinst wahrscheinlich die XHCI-Handoff Einstellung im BIOS? Kann ich im Verlauf des Tages auch mal unter Catalina ausprobieren :)


    Das Problem ist, obwohl die Meldung "AE_ALREADY_EXISTS" lautet, dass die Einträge sonst nirgendwo auftauchen. Ich hab' die Dinger ja frisch erstellt und nur noch das nötige Zeug gemacht. Eine Überprüfung mit IOreg (hätte ich vielleicht eher erwähnen sollen, duh') hat die Fehlermeldung bestätigt: es ist nach, wie vor nur das übliche RTC-Device vorhanden, statt des RTC0 und EC gar nicht.


    Ich geb' dir Recht, da könnte man mehr debuggen, aber in meinem Fall läuft ziemlich alles über SSDTs, daher hatte ich gehofft, dass ein erfahrener Anwender evtl. mal Korrekturlesen kann. Sobald ich nämlich anfange meine Verdachtskandidaten rauszuschmeißen, könnte mir das OS X wieder um die Ohren fliegen (wo wir nach so langer Zeit nun endlich wieder vereint sind :)). Einige wenige muss ich aber definitiv ausprobieren; ich hatte das Problem nämlich schon mit meinem X58 Board: Es waren die SSDTs mit property injection! Jedoch brauche ich diese im Fall der iGPU bspw. wirklich, dienen also nicht nur der Kosmetik. Entsprechend habe ich versucht bei jeder SSDT das geladene OS abzufragen, um diese entsprechend zu laden, oder auch nicht (Betonung auf "versucht" weil ich ja sonst nicht mit meinen Problemen hier gelandet wäre, wah'? :D)

    Hallöle liebe Forengemeinde,


    kurzes Vorwort: ich weiß ich melde mich nur, wenn ich was zum Maulen hab' :P


    Vorgeschichte::

    Nach langem Einstauben hab' ich mich vor zwei Tagen dazu entschlossen mein Z390 System mal wieder auf Vordermann zu bringen. Gesagt getan: erst hab' ich Windows von der Version 10 auf 11 angehoben und die Treiberupdates erledigt; OS X, jedoch, war dazu bestimmt mich zu plagen! Zunächst hatte ich meine Radeon VII implantiert und alles lief wunderbar. Dann hab' ich aber festgestellt, dass die GraKa nirgendwo angezeigt wird (hatte zu der Zeit mein Cinema Display am Thunderbolt Port hängen). Einmal reseat war des Rätsels Lösung! Dann wollte aber OS X nicht mehr booten...also entschied' ich mich kurzerhand Clover durch Opencore zu ersetzen. Weil ich zuvor schon mit OC experimentiert hatte (auch im Zusammenhang mit der Radeon VII) dachte ich, ich nehme einen vorhandenen Build und bügel dann später ein Update drüber. Denkste! Weil ich noch etwas faul und unmotiviert war, war meine nächste geniale Idee einen ähnlichen Build irgendwo im Netz zu ziehen und so zu probieren; wieder Fehlanzeige. Stinkend sauer, wie ich war, hab' ich also alles runtergeworfen, wirklich ALLES! Und angefangen in mühevollster Feinarbeit meinen Bootloader von 0 auf zu konfigurieren (lasst mich sagen, die SSDTs waren kein Spaß!) Glücklicherweise ist Opencore mittlerweile so weit vorangekommen, dass es vieles auch schon vorgefertigt zum Herunterladen gibt; also zumindest ein bisschen Erleichterung (damals zu Clover-Zeiten musste ich noch alles manuell machen). ACPI. Der Wermutstropfen. Nun bin ich so weit, dass ich mein OS X wieder booten kann und hab' auch direkt von 10.15.4 auf 10.15.7 geupdatet (weitere Updates will ich erst vollziehen, wenn ich sicher bin, dass alles fehlerfrei läuft).


    Problem(e):

    Ersteres erwähntes Problem ist, dass es noch SSDTs in meiner "Sammlung" gibt, die nicht vollständig eingespeist werden und natürlich, dass ich nicht zwangsweise ein ACPI-Crack bin. Namentlich sind diese:: SSDT-EC.aml und SSDT-RTC.aml. Der Verbose-Boot spuckt "AE_ALREADY_EXISTS" aus (oder so ähnlich, hab's nemme im Kopf) und ich hock' glaub' ich schon zu lange an dem Gerät, um den Fehler überhaupt noch sehen zu können.


    Letzteres Problem ist, dass sich Windoof über OC nicht booten lässt (quelle surprise) mit der Fehlermeldung, ihr ahnt es, ACPI_BIOS_ERROR. Ich hab' auch relativ penibel darauf geachtet die Methoden zu setzen, dass die SSDTs nur unter OS X geladen werden (Betonung auf relativ, sonst hätt's ja wohl funktioniert, duh'). Nun weiß ich, dass die deutsche hackintosh-Community auch schon fortschrittlich ist, was mich zu meinem Hilfegesuch bringt.


    apfelnico einiges vieles hab' ich mir unter anderem auch von dir abgeguckt und nicht zuletzt vom Klaus :)


    Bevor ich's vergess', die Systemdaten:


    Mobo: Gigabyte Z390 Aorus Xtreme

    CPU: i9-9900K

    RAM: 2x8GB G.Skill Trident Z Royal

    Festplatte(n): 2x Samsung NVMe 970 Pro

    WLAN: Apple BCM943602CDP (das Gerät zu finden war ein Aufwand und erst es lauffähig zu machen) auf einem China-Spezial-Adapter mit BT Anschluss am internen HS13 Header. Die interne Karte ist vollständig deaktiviert.

    GraKa(s): Sapphire Radeon VII und Intel UHD 630

    Optische Laufwerke: keine

    Custom WaKü (wahrscheinlich unwichtig?): nur die WaPu ist am Mobo PWM (und Netzteil natürlich) angeschlossen, Lüfter alle Noctua

    PSU (wahrscheinlich auch unwichtig?): Seasonic 850W Dingens mit 80+ Tit.

    BIOS ist auf dem aktuellsten Stand (F9)


    Mein Thunderbolt Controller ist geflasht und entsprechende SSDT liegt in der angehängten EFI bei. Ferner bin ich damals schon mit High Sierra auf diesem System eingestiegen und nach langem Suchen konnte ich die Firmware meiner 10G Aquantia downgraden; so hat High Sierra die Firmwareversion dann mit Apples eigenem Updater (beim Booten) wieder angehoben. Seither wird sie als Apple Aquantia AQC107 erkannt.


    BIOS-Einstellungen sind die üblichen, außer, dass ich VT-d auch aktiv hab', DisableIOMapper, aber deaktiviert und stattdessen eine DMAR.aml lade.

    So weit ich weiß (weiß nicht, ob von Bedeutung) ist auch Platform Power Management deaktiviert, sowie RC6 und PTT etc.

    CFG-Lock, SecureBoot, Fastboot alle disabled. OS-Auswahl Gedöhns auf Windows 8/10

    XHCI Handoff und dergleichen natürlich enabled. Rest auf Auto.

    Windows HDD ist auch GPT partitioniert und im UEFI-Mode installiert.


    Sollte mir noch mehr einfallen, trag' ich's nach :)


    Viele Grüße

    Dateien

    • EFI.zip

      (10,82 MB, 77 Mal heruntergeladen, zuletzt: )

    1000


    Bildquelle: Gigabyte.com


    Ethernet: 2 x RTL8111E chip; RTL8111.kext (von Mieze)

    Audio: Realtek ALC889 codec; AppleALC.kext, layout-id=1

    Inkompatibilität: Ich hab's zwar nicht getestet, aber DRM geht ziemlich sicher nicht (hab' mich aber auch bei aller Ehrlichkeit nicht damit außeinandergesetzt, oder gar verwendet), hatte des weiteren Probleme beim Update zu Big Sur (gehe jetzt Monterey an, hatte wiederum zu wenig Zeit, um mich damit außeinanderzusetzen)

    Getestete Hardware: i7-920, X5690, GTX 1070 (bis High Sierra), HD 5770, Vega 56, Vega 64, Radeon VII, Inateck USB 3.0 PCIe Card (weil die nativen Ports seit geraumer Zeit bei OS X ja no-go sind), Sonnet 10G Ethernet adapter, Gigabyte Titan Ridge (mit geflashter Firmware), Apple LED Cinema Display 27", Corsair Dominator 6x8GB, Festplattem sind Samsung SSD Pro x2 (Windows/Mac), Wi-Fi und Bt sind der BCM94360CD + Adapter, Laufwerke funktionieren, Firewire wird angezeigt (aber nie verwendet), Kartenleser wird laut Sysinfo nicht erkannt, läuft aber trotzdem

    SMBios: macPro 5,1 (bis High Sierra, oder Mojave), macPro 6,1 seitdem (der Updates wegen)


    Weil mein EFI-Ordner zu groß zu sein scheint, hab' ich's nur bei der DSDT und config belassen (ROM, MLB etc. entfernt)

    Dateien

    • Archive.zip

      (11,87 kB, 13 Mal heruntergeladen, zuletzt: )