OpenCore Sammelthread (Hilfe und Diskussion)

Jenser hast du die Serialnummer, MLB und UUID selbst generiert für deine Kiste, oder einfach von der Ursprungs EFI übernommen?
Versuche mal die rot markierten Daten zu löschen und dann zu booten (nicht die komplette Zeile, nur die Inhalte/Value, UUID, Serial ...). Ich denke, das sollte dein Problem beheben.

Leggalucci ich habe die Nummern vom Cloverconfigurater erstellen lassen.

habe Die Nummern rausgeworfen, leider mit dem selben Ergebnis:

***********************************************************************

this version of Mac OS X is not supported on this Platform

************************************************************************

Reason Mac-F4208cc8

sleeping for 30 seconds before exit

Hi Jenser ,

Das ist falsch, du solltest ein Komma statt des Punktes eintragen. Und einen "iMacPro19,2" gibt es gar nicht, du meinst bestimmt "iMac19,2"

Wieso ist das hier noch niemandem aufgefallen?

RealZac

...leider nein, hab mich gerade über meinen blöden Fehler gefreut.

Hat hier vll. jemand eine Idee?

Nachdem ich eine 5600XT eingebaut habe, kommend vom 580er, bleibt der Bildschirm schwarz- und dauert ne Ewigkeit bis der Hack da ist. Ich muss quasi mehrmals den Monitor Port wechseln, damit er aufwacht.

Einmal da läuft es, aber Boot ist ne Qual.

Zitat von 5T33Z0

Ich habe ihn nicht ohne Grund auf den Thread zum Vision D Board verwiesen. Abgesehem davon wird für Cometlake CPUs iMac20,1 bzw. 20,2 oder iMacPro1,1 empfohlen – je nach Hardware-Konfiguration.

Das hätte man Jenser aber auch gleich schreiben können.

Jupp. Klingt besser …

Vorteil der Device Properties wäre, das ich weitere Parameter übertragen kann, zum Beispiel:

Nur ein Beispiel. Teils sind diese Werte eh vorhanden – und wenn ja, dann werden die eh nicht überschrieben zu diesem Zeitpunkt – teils ist es nur "Kosmetik", um so im Systembericht unter PCI-Geräte aufzutauchen. Mitunter sind es spezifische Einträge, die macOS helfen, den richtigen Treiber mit den richtigen Optionen zu verwenden, oder eine bestimmte Reihenfolge (location 1) einzuhalten, oder Reihenfolge von USB-Controllern (USBBusNumber 0x02), oder zusätzliche Infos für Apples Systemtreiber, dass dieses Gerät trotz andere Adresse genauso funktioniert wie eine bestimmte bekannte (compatible pci144d,a804) und und und …

Um Geräte zum frühstmöglichen Zeitpunkt zu deklarieren ist die Variante ACPI, in dem Fall also eine zusätzliche SSDT vorzuziehen. Hier können deutlich mehr eigene Werte übergeben werden, auch Fake-Adressen sind so ohne Probleme möglich.

Edit:

mhaeuser

Ist "OpenHfsPlus.efi" der bisherigen "HfsPlus.efi" vorzuziehen? Letztere ist original Apple, und die freie Alternative ist schneckenlangsam. Was kann die neue eigenentwickelte(?)?

apfelnico

Woran machst Du denn da Qualitätsunterschiede fest? Bist Du Dir wirklich sicher?

Ich mach es via SSDT und dort sind auch so Sachen wie Name, Device-Type, Model eingetragen, allerdings ist dat nur Kosmetik für die Anzeige diverser Hardware-Abfrage/Anzeige-Software im späteren laufenden System.

Wichtig ist eher die Übergabe der ID, denke ich. Soweit ich den Code der AppleALC verstehe, interessiert die AppleALC sowas nicht, sondern arbeitet nur die hinterlegten Konfigurationen ab, sofern das Device erkannt wird.

Bei mir klingt Inject via bootargs genauso, kein Unterschied.

Ich will mich hierbei aber auch nicht weit aus dem Fenster lehnen. Ob es tatsächlich Unterschiede gibt, werden vermutlich nur die Entwickler sagen können.

Hast Du zu dieser Info weiterführende Informationen bzw. Links?

Zitat von apfelnico

Ist "OpenHfsPlus.efi" der bisherigen "HfsPlus.efi" vorzuziehen? Letztere ist original Apple, und die freie Alternative ist schneckenlangsam. Was kann die neue eigenentwickelte(?)?

Nicht wirklich. Der ist auch nicht selbstentwickelt, nur hat der im Gegensatz zu VBoxHFS eine benutzbare Lizenz. Er ist mehr mit VBox als mit Apples Treiber zu vergleichen - für die, die auf OSS bestehen.

Zitat von MacPeet

Bei mir klingt Inject via bootargs genauso, kein Unterschied.

Selbstverständlich, war ein Witz.

Ich mache auch vieles per SSDT, allerdings nur bei den Geräten, die keine _DSM Methode nutzen, denn ich blocke diese nicht. Es sollen nur zusätzliche Infos sein, ausschliesslich für "Darwin". Alle anderen Geräte (mit _DSM) beschreibe ich per Device Properties. So bleibt alles "sauber" für andere Systeme.

oh sorry, ich dachte leider, es wäre ernst gemeint