Herausforderung mit Catalina und Open Core auf H61 non-UEFI BIOS board

Nachdem ich nun seit geraumer Zeit erfolgreich mit Open Core auf meinem Hauptsystem (1) und den beiden MacPros (3,4) gefahren bin, wollte ich nun noch das verbliebende System (2 in der Signatur) zunächst auf Catalina bringen, später dann vielleicht auf BigSur, wobei dass dann eine Änderung des SMBIOS erfordern würde.

Als Zwischenschritt lief das System mit Clover 5107 und 10.15.7 recht gut, allerdings hatte ich beim Neustart mit den CMOS reset zu kämpfen, was mich dann dazu bewogen hat, zwischen den Jahren die Umstellung auf Open Core in Angriff zu nehmen.

Ich hatte allerdings etwas mit der Installation des BootSektors zu kämpfen, den ich benötige, um OC auf dem alten H61 Board mit non-UEFI Bios booten zu können. Am Ende habe ich die SSD mit meinen anderen Hackintosh (System 1) gesteckt, SIP disabled, macOS und OC installiert und dann die SSD in System 2 eingebaut. So weit, so gut, OC Boot Picker erscheint und Catalina booted auch recht flott auf System 2.

Nun zum Kern des Problems:

Leider friert das System wenige Minuten nach dem Start ein, Maus und Tastatur sind tot. Das passiert unabhängig davon, ob man sich anmeldet oder nicht. Es ist mir zwar gelungen, die Console nach der Anmeldung und vor dem Freeze zu öffnen, es erscheint aber keine hilfreiche Fehlermeldung. Mehr konnte ich in der verfügbaren Zeit bis zum Freeze nicht testen.

Bei der Suche nach möglichen Ursachen sind mir folgende Zeilen im verbose log auf dem Bildschirm nach Anwahl des Laufwerkes im OC boot picker aufgefallen.

Ich habe die SSDT-EC mit Hilfe von SSDTTime auf Basis der extrahierten DSDT (in Anhang) erstellt.

Die DSDT ist ziemlich chaotisch strukturiert, aber soweit ich das verstehe, gibt es kein existierenden device vom Type PNP0C09 und der Pfad für das Fake-EC sollte nach der Anleitung von Dortania auch passen.

Aufgrund der ACPI Fehlermeldung vermute ich, dass das Einfrieren durch den fehlenden Fake-EC Eintrag verursacht wird.

Da ich da nicht weiterkam, hatte ich auch schon die Ergänzung von USBInjectAll und CpuTscSync ohne Erfolg probiert. Da meine Symptome aber nicht zu 100% auf die Beschreibung im Dortania Troubleshooting Guide passen, muss wohl unter "Akt der Verzweiflung abgehakt werden.

Hat irgendjemand 'ne Idee, wie ich dem Problem auf die Schliche komme ? ich stehen im Moment echt auf dem Schlauch.

hallo apfel-baum, OSX-Einsteiger,

danke für die schnelle Antwort. Hatte allerdings BootInstall_X64.tool schon für die Installation von openduet auf der Boot-SSD verwendet.

Ohne das (openduet) findet das BIOS von System 2 gar nichts auf der SSD.

Das funktioniert ab Catalina nur noch mit ausgeschaltetem SIP und das hab ich nur auf dem laufenden System 1 hinbekommen, daher der beschriebene Umweg.

Wenn man -v als boot-arg weglässt, sieht der Boot-Vorgang auch ganz normal aus, und bis zum Einfrieren kann ich das System auch normal nutzen, ich kann "Über diese Mac" aufrufen, Aktivitätsmonitor funktioniert auch und ich konnte die Konsole starten. Leider beträgt die Zeit bis zum Einfrieren nur 1-2 Minuten.

Wenn ich das System 1 (UEFI) von dieser SSD boote, funktioniert alles ohne Einfrieren - gleicher Prozessor, nur der Z68 Chipsatz anstelle des H61.

Ich muss zugeben, dass dieser PC damals nur als Minimal-Lösung mit i3-2125 ohne dedizierte Graphikkarte an den Start gegangen ist. Im Laufe der Zeit hat es dann Upgrades aus übergebliebenen Komponenten erhalten und nun hat mich der Ehrgeiz gepackt, auch dieses System auf einen halbwegs aktuellen Stand zu bringen (sprich idealerweise BigSur).

Irgendwie hatte ich schon geahnt, dass Open Core auf dem Hybrid-BIOS nicht so flutschen wird, aber ich bin ja gefühlt schon auf der Zielgeraden.

Habe gerade noch ein bisschen rumprobiert und bis zum Freeze funktioniert auch Safari, Apple Maps und Photos ohne murren.

Auch im System Report sieht alles so aus wie es soll, auch wenn ich das nur in mehreren Etappen anschauen konnte.

Das System friert auch nicht beim Aufruf irgendeiner Funktion ein, sondern scheint sich eher in der Zeiten ohne Benutzeraktion zu verabschieden - als würde die Nutzeraktion irgendeinen Hintergrundprozess ausbremsen, der dann irgendwann genug CPU-Zeit vom System zugewiesen bekommt, um loszulegen und dann voll auf die Nase zu fallen.

Jetzt ist aber Schluß für dieses Jahr, auch wenn die Silvesterparty diese Jahr im kleinen Rahmen stattfindet, braucht es noch ein wenig Vorbereitung.

Ich wüsche Euch allen einen guten Rutsch und ein erfolgreiches Jahr 2022.

Nach einiger intensiver Recherche und Ausprobieren habe ich nun zumindest ein lauffähiges System 10.15.7 mit OpenCore zu Stande gebracht.

Die Kern-Herausforderung sind die ziemlich vermurksten ACPI-Tabellen des Hybrid-BIOS.

1. Die DSDT enthält den Teil (C-States) vom Power Management, der eigentlich in Cpu0Ist stehen sollte.
2. Die P-States sind dafür in einer separaten SSDT definiert, allerdings mit der Table-IDPPM RCM
3. Der DSDT fehlt die Methode DTGP, ohne die das Injizieren von device properties nicht sauber funktioniert

Also läuft die Kiste im Moment mit Kernel>Emulate>DummyPowerManagement und alcid=1 als boot-arg, weil die layout-id als device property nicht von AppleALC gefunden wird. WhateverGreen beschwert sich über die falsche device ID des IMEI, die offenbar auch nicht injiziert wird obwohl sie in der config.plist steht.

Die Fehlermeldung vom ersten Eintrag war übrigens auf meine eigene Schusseligkeit zurückzuführen, da ich SSDTTime aus Versehen mit eine bereits gepatchten DSDT gefüttert hatte. Das Einfrieren des Systems ist auf das CPU Power Management zurückzuführen, da die System internen Tabellen auf Grund der anderen Table-IDs nicht gelöscht wurden. Offenbar passiert da in Clover einiges zusätzlich hinter den Kulissen, denn da funktioniert das PowerManagement mit derselben SSDT aus ssdtPRgen. Es heißt also weiter recherchieren.

Als kleines extra Ärgernis kann man im OpenCore BootPicker keinen Default-Eintrag definieren. Mit UEFI>Quirks>RequestBootVarRouting wird immer der ersten Eintrag mit dem Stern versehen, egal was man im macOS als Startvolumes anwählt. Ohne ist nichts als Default definiert und egal welchen Eintrag man mit crtl-enter anwählt, beim nächsten start ist der Cursor wieder auf dem ersten Eintrag der auf die EFI Partition der Festplatte and ersten SATA Anschluß zeigt.

Weiß jemand, wie man in Open Core die Methode DTGP über eine SSDT einfügt ? Die SSDT im Anhang scheint das nicht zu bewerkstelligen, oder die dysfunktionale Injektion der device properties hat andere Gründe.

bluebyte Super Hinweis, in der Tat funktioniert NVRAM nicht nativ.

Allerdings bekomme ich die Emulation nicht ans Laufen.

Eintrag für LogoutHook ist vorhanden, Ausführungsrechte für die Skripte sind ebenfalls vorhanden.

Open Core config.plist habe ich angepasst.

Trotzdem wird keine nvram.plist auf der Boot-EFI Partition bei Logout erzeugt. Ich konnte aber auch die von LogoutHook.command erzeugten Meldungen im System-Log nicht ausfindig machen und bin daher etwas ratlos.

Die anderen Probleme habe ich jetzt dadurch umschifft, dass ich anstelle der diversen SSDTs für Open Core einfach die mit F5 extrahierte, von Clover on-the-fly gepatchte DSDT nutze. Die enthält nämlich außer des EC devices schon alles Notwendige.

Jetzt funktioniert auch das Injizieren der device properties.

In Verbindung mit dem Löschen der richtigen CpuPM Tabelle flutscht jetzt auch das CPU Power Management.

Update:

Nachdem ich die EFI Partition der ebenfalls eingebauten Festplatte gelöscht habe und damit nur noch eine Boot-Partition (auf der SSD) im System vorhanden ist, wird plötzlich auch die Datei nvram.plist erzeugt und die scheint auch vom open core nach dem Neustart sauber geladen zu werden. Ich sollte ebenfalls noch erwähnen, dass ich das Home-Verzeichniss des primären Accounts noch aus Zeiten teurer SSDs auf die Festplatte umgelenkt hatte. Das hatte ich bei der Aktion wieder rückgängig gemacht. Basierend auf der nun folgenden Problembeschreibung ist es wahrscheinlich, dass das Home-Verzeichnis auf der ausgebremsten Festplatte die eigentliche Ursache war.

Im Zuge der Ursachenforschung hat sich aber nun noch ein anderes, mehr fundamentales Problem gezeigt: Die interne 2GB Festplatte am zweiten SATA Port ist furchtbar langsam, so dass selbst das Abspielen einer Audio-Datei nicht möglich ist. Dabei scheint die Datenübertragung immer für ein paar Sekunden einzuschlafen, um dann wieder mit normaler Geschwindigkeit für einen kurzen Boost zu funktionieren. Unterm Strich bleibt aber eine sehr, sehr magere Netto-Übertragungsrate übrig, die beim Kopieren von Dateien auch häufiger den Beachball in Erscheinung bringt. Dagegen wirken externe USB2 Platten wie mit Lichtgeschwindigkeit.

Folgende potentielle Ursachen habe ich bereits ausgeschlossen:

1. Defektes SATA-Kabel: Ich habe zwei andere ausprobiert, die nachweislich in einem anderen Rechner funktioniert haben - selbes Symptom
2. Defekter SATA Stecker auf dem Mainboard: Festplatte ist auf allen 4 SATA Ports gleich langsam, die System SSD funktioniert dagegen auf allen Ports mit voller Geschwindigkeit
3. Defekter SATA-Controller im H61 Chipset: Chipset ist Revision 5, welches den ursprünglichen Fehler bei den Ports 2-5 beim Serie 6 Chipsatz von intel nicht mehr haben sollte. Außerdem funktioniert die SSD an allen Ports ohne Probleme und die Festplatte ich auch den an nicht betroffenen Ports 0 und 1 langsam.
4. Defekte Festplatte: Egal welche andere Festplatte / SSD ich versuche, als Zweitlaufwerk in den PC einzubauen: Das BIOS erkennt sie alle ausnahhmslos, aber macOS meldet, dass das "eingelegte Laufwerk" nicht gelesen werden kann. Jeglicher Formatierungsversuch endet mit dem Fehler "Auf den letzten Block des Gerätes konnte nicht geschrieben werden: (-69760)". Alle getesteten Laufwerke lassen sich aber sowohl an meinem MacBookPro (Catalina) über USB-SATA Adapter als auch ein meinem anderen Hackintosh (BigSur) am internen SATA Port einwandfrei formatieren und mit normaler Geschwindigkeit nutzen.
5. Interrupt-Konflikte: Ich habe im IO-Registry-Explorer alle IOInterruptSpecifier aller Geräte durchgeschaut und keine Überlappung zwischen dem IDE/SATA Controller und anderen Geräten entdeckt. Das war nach der Verwendung der bereinigten DSDT eigentlich auch so zu erwarten.

Es scheint fast, als könnte ich am PCH nur ein SATA Gerät betreiben, wobei es schon merkwürdig ist, dass das Boot-Drive immer funktioniert und nur das "Zweitlaufwerk" ausgebremst wird, egal ob HDD oder SSD und egal ob als ExFat, HFS journaled oder APFS formatiert.

Im Moment tendiere ich dazu, einfach eine PCI SATA Karte nachzurüsten und hoffentlich damit das Problem zu umgehen.

Vielleicht hat ja jemand noch ´ne gute andere Idee, an die ich nicht gedacht habe.

Final update:

Nachdem ich günstig an ein H77 Board gekommen bin, habe ich den harten Schnitt vollzogen und das System umgebaut. Mit dem UEFI-BIOS erledigen sich viele Komplikationen und gegenüber einer PCIe-SATA Karte war die Investition auch nicht wesentlich höher, wenn man mal den Aufwand für den Umbau außen vor läßt.

Nun funktioniert fast alles wie erwartet, nur Ton bekomme ich nicht aus dem ALC887 gezaubert.

Das ASUS-P8H77-V LE hat eine Konfiguration, die zu keinem vordefinierten Layout in AppleALC zu passen scheint. Einen IRQ Konflikt kann ich nach Erzeugung und Installation einer passenden SSDT inkl. der Patch-Einträge in der config.plist von OC ausschießen.

Wenn es mir wieder in den Fingern juckt, werde ich mal versuchen, die notwendigen Ergänzungen für ein eigenes Audio-Layout in AppleALC einzubringen, den notwendigen codec-dump habe ich bereits mit einem Linux-Live-System extrahiert und mit PinConfigurator angeschaut.

Nun muss ich nur noch herausfinden, wie ich die layout.xml and platform.xml Dateien anpassen muss.

MacPeet: Ich versuche mich gerade an Deiner Anleitung auf root86.com, allerdings scheint ja der PinConfigurator inzwischen auch die Bereinigung der Verbs zu ermöglichen. Irgendwie fehlt mir im Moment noch der Überblick und die Zeit, das mal in Ruhe anzugehen.

Eigentlich dachte ich alle ID‘s bereits durchprobiert zu haben, allerdings hatte ich das über die device properties gemacht.

MacPeet: Da werde ich dann nochmal genauer hinschauen müssen, wenn auch auf meinem Board die üblichen Knoten im Einsatz sind stimme ich Deiner Einschätzung zu, dass dann eine existierende ID funktionieren sollte.

Wahrscheinlich habe ich mal wieder irgendein Detail übersehen.

Update: Nach viel Rumexperimentieren bin ich zu dem Schluß gekommen, dass die HD-Audio Hardware ne Macke hat. Die Hardware wird zwar im Linux als device geführt, weshalb ich auch einen validen Codec-Dump erzeugen konnte. Allerdings wird sie von den Linux-Treibern nicht erkannt und funktioniert daher auch unter Linux nicht.

Ein Vergleich des selbst erstellen Layouts mit vorhandenen Einträge im AppleALC.kext hat weiterhin gezeigt, dass zumindest der Line-Out identische Parameter mit vorhandenen Layouts hat und somit Mirone´s Layout-ID 5 hätte funktionieren müssen.

Also habe ich die Brechstange ausgepackt und bei eBay für 40€ einen Monitor mit eingebauten Lautsprechern ersteigert, dann gibt es Audio halt über HDMI.

Gott sei Dank brauche ich kein HIFI und günstige USB Soundsticks waren gerade auch nicht für weniger Geld im Angebot.
Monitor wird nächste Woche erwartet, dann liefere ich noch ein finales Update.

Der Monitor ist inzwischen installiert und Audio über HDMI funktioniert wie erwartet.

ich hatte noch die Gelegenheit, Windows auf einer separaten Festplatte zu installieren und auch Windows erkennt den ALC887 nicht. Also ist nun relativ sicher, dass es ein Hardware Problem ist.

Damit kann ich das Kapitel nun schließen.

Nochmals vielen Dank an alle, die mich mit Ratschlägen bei der Fehlersuche unterstützt haben.