Beiträge von mumsford

Tag Zusammen,

mit neuer SSD und reichlich vergangener Zeit war mir mal wieder danach, den alten Lenovo zu entstauben.

Die letzte Installation lief noch per Clover und es war Catalina. Nun sitze ich an OpenCore und dem Versuch, Monterey zu nutzen.

Grundsätzlich stehe ich auf dem Schlauch. Die ACPI Errors unter OpenCore 0.9.4 sind identisch zu denen von Clover in 2019, aber weiter als:
[PCI configuration begins ] kommt der Gute nicht.

Vorab ein Auszug der Fehlermeldungen:

ACPI Error: no handler for Region [ERAM] ...
ACPI Error: Region EmbeddedControl (ID=3) has no handler ...

No local Variables are initialized for method [_STA]
No Arguments are initialized for method [_STA] ... etc. etc.

ACPI Error: Method parse/execution failed [\_SB.PCI0_GFX0._DSM] ..... AE_NOT_FOUND

Danach schmierts ab.

Unter clover lief das ganze noch per rename: GFX0 to IGPU worum sich nun ja Whatevergreen kümmern sollte, sowie _DSM to _XDSM und EC0 to EC (letzteres sollte durch die SSDT-EC aus dem Dortania Guide für laptops aber auch unproblematisch sein)

USB wurde unter Windows gemappt.

Lange Rede kurzer Sinn, anbei nochmal die EFI, vielleicht sieht jemand den Wald vor lauter Bäumen außer mir. Oder es wird Zeit, den Lenovo mal in Rente zu schicken!

Zitat von kaneske

Bei mir ist eher macPro7,1 die bessere Wahl bzgl. CPU Performance

Bei mir ist eher macPro7,1 die bessere Wahl bzgl. CPU Performance

Ich probiere auch nochmal den 7,1 - langsam muss ich mich aber auch mit den iServices befassen und mich daher auf ein System festlegen. Mit der Performance bin ich grad ganz zufrieden.

Zitat von kaneske

was darauf deutet, dass die DataProvider.kext nicht richtig ist oder inkonsistent ist. Hatte meine auch ur-plötzlich.

Ich habe per CPUFrindFriend die DataProvider.kext erstellt. 2x mit selbem Ergebnis.
Ist es normal, dass das Skript nur 1. nach dem LFM fragt und 2. ob ich bestimmte Power Saving Modes aktivieren möchte?

Zitat von kaneske

Auf was bezieht sich das??

Nunja, folgendes Szenario:

Ich boote per OpenCore in Ventura und fahre jetzt den PC herunter oder starte neu (spielt keine Rolle). Nun übergehe ich OpenCore indem ich über das BIOS die Windows SSD als Bootmedium nehme und starte ohne jegliche OpenCore Beteiligung -> Tastatur / Maus funktionieren erst nachdem Aus- und wieder Einstöpseln.

Führe ich obere Prozedur aus Windows heraus durch (Aus Windows heraus neustarten, Windows SSD als bootmedium etc. -> wie zu erwarten keine Probleme)

Windows muss also trotzdem, obwohl OpenCore beim Bootvorgang nicht beteiligt ist, informationen bekommen welche dazu führen, dass die Tastatur nicht funktioniert.

UTBMap.kext ohne USBToolBox.kext ist ein Versuch wert, löst aber glaube ich nicht mein geschildertes Problem. Es sei denn mir kann jemand erklären wie der genannte Kext Einfluss auf den Bootvorgang von Windows nehmen kann, wenn OpenCore daran absolut keine Beteiligung hat. Der einzige Anhaltspunkt wäre in meinen Augen eine Variable im NVRAM, oder?

>> Update: Das Tastaturproblem ist seit längerem "gelöst" bzw. hat mit OpenCore oder der Config nix zu tun.
Tastaturen von SteelSeries scheinen in dieser Hinsicht problematisch. Ich habe mittlerweile wieder Razer im Einsatz und hier funktionierts.

Jep, ziemlich wild! Top, sehr schön das du dein Windows noch retten konntest... ständige Neuinstallationen machen auch absolut keinen Spaß.

Werde beides nachher nochmal machen, wenn ich mit meinen Ersteinstellungen soweit durch bin. Irgendwie hab ich ja Hoffnung, dass es plötzlich klappt.

Ventura muss wohl beim Herunterfahren / Neustarten irgendwo Informationen setzen. Wenn ich den Neustart aus Windows heraus durchführe, passiert das ganze natürlich nicht. Wenn es ausschließlich beim Starten aus OpenCore heraus passieren würde, hätte ich wenigstens einen Anhaltspunkt

PassMark Software - Display Baseline ID# 5029216

Edit: PassMark Software - Display Baseline ID# 1711136

Zumindest die macOS / Windows Ergebnisse decken sich ganz gut.

USBToolBox hab ich ganz zu beginn entsprechend laufen lassen und eingebunden. Und das Mapping sollte ja nach einem Neustart in Windows, ohne das OpenCore involviert ist, eh irrelevant sein oder sehe ich das falsch?

Benchmark lasse ich nun auch mal unter Windows laufen - mit und ohne OpenCore beim Start.

Da bin ich wieder! hackmac004 Bios hab ich nochmal geprüft, das passt soweit.

Der Fehler ist nun auch weg, nachdem Ventura nun endlich auch die EFI erstellt hat und diese Partition mit OpenCore als Bootloader erkannt wird.

Wie du vorgeschlagen hast, habe ich auf das SMBIOS vom iMacPro1,1 gewechselt und der Geekbench sieht schon besser aus: https://browser.geekbench.com/v5/cpu/19678394

An die Richtwerte von KungfuMarek komme ich aber noch nicht ran.

Ebenfalls habe ich die CPUFriend.kext mit zugehörigem Skript eingebunden, was allerdings keine Besserung im Geekbench brachte (eher eine kleine Verschlechterung)

Das USB-Problem besteht weiterhin. Nach dem Neustart muss ich die Tastatur aus- und wieder einstecken. Die Maus, sowie etwaige externe Festplatten laufen so. Selbiges Problem besteht dann auch unter Windows. Und das auch, wenn ich OpenCore umgehe und direkt aus dem BIOS heraus den Windows Boot Manager ertüchtige.

Den Installer Stick hats übrigens gegrillt. Nachdem ich per Windows die Recovery neu auf den Stick ziehen wollte, hat sichs beim Kopiervorgang abgeschossen -_-.

Erste Installation lief noch mit Windows Installation. Das hat zumindest gepasst. Aber jetzt kommts: Ventura scheint sich anders zu verhalten. Ich habe lediglich die macOS SSD und den Stick drin.

Das recovery image auf dem stick hat sich jetzt verabschiedet (DMG altered, OC startet es nicht mehr)

Und mein BIOS meckert, siehe Screenshot. Ich klemm jetzt also die Windows Platte wieder dran, ziehe mir ein neues Image und probiere es nochmal.

Vielen Dank für deine schnelle Antwort. Na dann installiere ich den Spaß nochmal neu und mache mich dann ans aufräumen!

Nur um sicher zu gehen: Ich habe für die SSD als Formatierung APFS und dann GUID-Partitionstabelle gewählt. Das hab ich in der Vergangenheit immer so gemacht. Passt das?

Ebenfalls muss ich auch noch an die USB Ports. Nach einen Neustart aus macOS muss ich nämlich die Tastatur und Maus aus und wieder einstecken um das Ganze wieder zur Funktion zu überreden. Ker, und ich dachte es wird im Vergleich zu x79 einfacher

Jup, die ist richtig wild, da hast du Recht KungfuMarek !

Klar, ich hoffe ich komme schon morgen dazu, dann gibts den Geekbench 5 Score hier im Thread.

Wird Zeit, da jetzt richtig aufzuräumen. Zu bedenken ist zudem, dass Ventura grad auf einer Externen USB 3.0 Platte installiert ist, da die Post mal wieder auf sich warten lässt. Gut, den Feiertagen geschuldet sei es so . Hauptsache ist, dass der Boot-Stick erstmal funktioniert.

Update:

https://browser.geekbench.com/v5/cpu/19672222

https://browser.geekbench.com/v5/compute/6172917

Problem:

Ventura hat mir bei der Installation keine eigene EFI auf der SSD erzeugt und nutzt die EFI Partition meiner Windows Installation. Ich habe den EFI-Folder des Bootsticks nun in den EFI-Folder der Windows-Startpartition integriert. Problem: Mein BIOS findet nur den Windows Bootmanager.

Ich möchte eigentlich eine separate EFI Partition auf dem macOS Startvolume, nur wie komme ich nun dazu? Bei all meinen vergangenen Installationen, von High Sierra bis Big Sur, hat mir der Installer grundsätzlich eine EFI Partition auf der macOS SSD erstellt.. Käse! Jemand eine Idee? Ansonsten lasse ich den Installer nochmal laufen und klemme alle anderen Drives ab, dann sollte er ja keine andere Chance haben.

Besten Dank für die Hilfe! Die Installation ist durch - weiteres Feintuning folgt morgen. Ich schaue mir insbesondere nochmal deine SSDT-EC.aml an. Jetzt unter macOS funktioniert das mit den SSDTs eh am besten. Vor allem möchte ich wissen, was die aktuelle config bezweckt.

Treiber, iServices etc. sind der nächste Step =)

Guten Rutsch!

Komme mit deinem Update leider nur bis zur selben stelle.

Update:

Ich habe just Asus spezifische Z690 SSDTs bezüglich der zwei oben zu erkennenden ACPI errors entdeckt und in die EFI eingepflegt. Ich poste nochmal, wenn das Setup durchgelaufen ist

CFGLock ist erledigt, dank CFGLock.efi. ControlMsrE2 gibt nun "unlocked" aus.

Hier nochmal die EFI

So, BIOS Update auf 2204 und nur noch 14 USB Ports in der Map. Es gibt in meinem BIOS keine Einstellungen bezüglich des CFG locks. Und nun habe ich 2 ACPI errors.

Kann ich per

Kernel/Quirks/AppleXcpmCfgLock true

das ganze umgehen?

Passt. Ich schaue mir deine EFI mal genauer an und teste auch mal FakeSMC.kext.

Aber ich bin dennoch etwas verwirrt, ich habe doch OpenRuntime.efi sowie HfsPlus.efi unter Drivers?

Ich überarbeite mal alles und melde mich gleich zurück

Besten Dank schon mal für eure schnellen Antworten!

Mein Bios ist v1720 - my bad, das ist ziemlich alt. Ich werde direkt auf 2204 aktualisieren.

Die UTBMap.kext würde ich gerne auf weniger als 15 Einträge verringern, besonders die USB-C Ports benötige ich prinzipiell nicht. Hier muss ich wohl nochmal durch die Guides blättern, sodass ich mir nicht alle Ports zerpflücke.. Ich gebe euch ein Update, nach erfolgten Änderungen

Gibts Tips worauf ich beim USB Mapping besonders achten sollte? USB 2.0 und 3.0, je nach Gerät, sollte schon beides funktionieren.

Ach und PS: Das interne Wi-Fi kann ich deaktivieren, da ich eine nativ unterstützte Broadcom Wifi Karte nutze, auch unter Windows.

Hallo Zusammen!

Mein X79 Board wurde ausgetauscht gegen ein aktuelles Z690.

Seit einigen Stunden versuche ich nun Ventura dazu zu überreden auf dem Hack zu starten.

Ich habe den Comet Lake Guide auf Dortania, sowie Alder Lake spezifische Infos bei der Erstellung meiner config.plist berücksichtigt.

Ich komme jedoch nicht bis zum Installer bzw. der Recovery.

Wie es scheint, schalten sich im Startvorgang alle USB-Ports ab. Ich habe bereits per USBToolBox die UTBMap.kext erstellt und eingebunden, was jedoch keine Änderung brachte.

Bios Einstellungen hab ich entsprechend des Guides und wie in der Vergangenheit üblich vorgenommen.

Ich hab meinen EFI Ordner mal angehangen.

Ohne USBToolBox.kext & UTBMap.kext bleibt der Starvorgang kurz nach "DSMOS has arrived" stehen.

Mit beiden Kexts ist die letzte Meldung:

USBToolBox: XHCI: waitformatchingservices failed or timeout.

Hat jemand eine Idee, wo ich hier am besten ansetze?

Besten Dank!

Ich hab ein paar Updates bzw. weitere Infos zu meinem Problem.

1. Für den E5-1680 v2 gibts keine Daten im ssdtPRGen script... Trotz Einfügen in der User Defined.cfg mit folgenden Eckdaten:

"E5-1680V v2,140,1100,3000,4400,8,16,4,100"

(140W zieht sich der Gute, dank des OCs auf 4,4GHZ. Mag das OC schuld an der Misere sein?)

lässt sich das Script blöderweise nicht ausführen. Und das ist, denke ich, der Grund für die Meldungen beim booten und den sporadischen KPs.

Mal läuft das System ein paar Stunden, mal nur ein paar Minuten. Irgendwo muss der Bock ja sitzen. Hat jemand Tips für mich, bzgl. des Power Managements vom 1680v2?

Hallo Zusammen,

es ist mal wieder soweit und ich habe ein ruhiges Wochenende mal macOS Monterey gewidmet.

Clean Install ohne jegliche Altlasten von Grund auf alles neu eingerichtet.

Das System startet mittlerweile relativ zuverlässig, bis auf einige Kuriositäten.

USB Ports funktionieren nur bedingt. Der ASM1042 taucht unter IOReg und PEX0-PEX7 auf, Hackintool zeigt ihn auch. Onboard USB 3.0 ist aber außer Funktion und

USBMapTool erkennt unter macOS den ASMedia auch nicht. Das hab ich allerdings erwartet.

Die USB 2.0 Ports verhalten sich auch merkwürdig. Bis Catalina genügte in der Vergangenheit das Umbenennen von EUSB auf EH01 und USBE auf EH02. Unter Monterey

funktioniert dann allerdings nur 1 USB Port, weshalb ich mich für das Mapping entschieden habe. Dies scheint allerdings auch zu Problemen zu führen, die sich wie folgt äußern:

Maus und Tastatur sind wie Dongle Wireless verbunden. Schließe ich diese zusätzlich zum Laden an einen freien USB Port, gehts relativ zügig -> KP (Power Management)

Das passiert tatsächlich sowohl mit aktiviertem PM als auch ohne (Drop CpuPm; Drop Cpu0Ist)

Über eine PCIe Karte mit 4 USB 3.0 Ports wollte ich das Problem des ASMedia Controllers umschiffen. Ist irgendein Fresco Logic und funktioniert auch oberflächlich,

zerschießt bei angeschlossenen Geräten jedoch die WiFi Fähigkeit des hacks, was mich zum nächsten Problem führt:

BCM943602CS Bluetooth wird zwar erkannt, Adresse ist aber; NULL und aktiviert ists auch nicht. Aber das liegt wohl offensichtlich an Monterey.

Was mich aktuell am meisten ärgert, sind unvorhersehbare KPs, welche darin resultieren, dass der PC danach automatisch in Windows bootet.
(Bootoptionen sind so eingestellt, dass von der Windows SSD eigentlich gar nicht gebooted werden dürfte, nundenn...) Sobald der Hack einmal in Windows gebootet hast,

startet Monterey nicht mehr, es sei denn ich setze per OC den NVRAM zurück. Dann bekomme ich jedoch keinen Bericht mehr angezeigt, weshalb macOS ursprünglich abgestürzt ist.

Bin mit meinem Latein definitiv derzeit am Ende und freue mich über jede Idee, das Ganze zu optimieren. Meine EFI hab ich mal angehangen =)

Big Sur rennt nun endlich auf meinem alten X79 System. Jedoch komme ich um die folgende Fehlermeldung bei der Anmeldung von iCloud nicht herum:

Kommunikation mit dem Server nicht möglich.

Musik funktioniert, und der App Store ebenfalls.

Hallo zusammen,

ich versuche nun schon seit längerem Big Sur auf meinem alten x79 System zum laufen zu bringen. in diesem Zuge habe ich mich

auch dazu entschieden, von clover auf opencore umzusteigen. Leider stellt sich das ganze als etwas schwieriger als gedacht dar.

Ich komme, egal was ich tue, nicht weiter als bis zu diesem Kernel Panic, wenn ich versuche in den Big Sur Installer zu booten.

Da es mir zu mühsam würde, ständig zwischen Clover mit anderem SMBIOS und opencore zu wechseln, startete ich Catalina mal mit der selben config aus opencore. Siehe da, das System fährt hoch, freezed allerdings nach einem Moment mit folgendem panic:

Alles in allem funktioniert 10.15.6 auf dem System also nach wie vor nur über Clover & Big Sur will micht nicht ansatzweise in den Installer lassen.

Leider gehen mir die Ideen aus, weshalb ich hier um Rat bitte.

Ich habe mal die funktionierende Catalina EFI für Clover angehangen, sowie die nicht funktionierende opencore EFI, mit der am Ende am besten Catalina sowie Big Sur laufen sollten. Ich bedanke mich schon mal vorab!

EDIT: Einen halben Tag später kann ich das Catalina problem begrenzen auf die Tatsache, dass es ohne NullCPUPowerManagement.kext nicht will. Trotz SSDT gehts nicht ohne. Power Management funktioniert damit dann allerdings.

BigSur lädt beim Boot den kext auch, allerdings scheint es hier woanders zu hängen. Ich verzweifle langsam daran & komme nicht weiter.

apfelnico

Hat soweit geklappt, danke! Der Pfad war _SB_.PCI0.SBRG

RTC0 war bereits vorhanden, so heißt das neue Device nun schlicht RTC. Scheint zu funktionieren, der RTC error ist weg. Hängt nur leider an selbiger Stelle.

Mit npci=0x2000 komme ich über die PCI Configuration, direkt zum kernel panic.

Langsam bringt mich Big Sur zum verzweifeln!