Jenser Dann den Thread dazu in diesem Forum verwenden und das Problem da schildern:
![](https://www.hackintosh-forum.de/images/avatars/1f/9779-1f81c6dbab7b2438edcbd6ce77d329c0e3c86f31.png)
OpenCore Sammelthread (Hilfe und Diskussion)
- derHackfan
- Unerledigt
-
-
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?
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.
-
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.
-
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.
-
Gibt es einen qualitativen Unterschied darin, ob ich ALC1150 über bootargs/alcid=3 oder über DeviceProperties aktiviere?
-
Jupp. Klingt besser …
-
Klingt besser
Was? Das oder Jenes?
-
-
weitere Parameter
Ich kann jetzt nur vermuten, dass der Weg differenzierter ist, da noch nie selber erprobt.
Wo & in welcher Form käme mir das zugute? Ich suche immer einen praktischen Bezug, habe da aber bei Dortania, wo ich vorher Infos dazu gesucht habe, nichts Spezifisches herauslesen können.
-
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:
Ist "OpenHfsPlus.efi" der bisherigen "HfsPlus.efi" vorzuziehen? Letztere ist original Apple, und die freie Alternative ist schneckenlangsam. Was kann die neue eigenentwickelte(?)?
-
Danke für die Erläuterungen - ich kann allenfalls ahnen, was Alles machbar ist.
Um Geräte zum frühstmöglichen Zeitpunkt zu deklarieren, ...
Da hätte ich zwar aus der früheren Gewohnheit die bootargs an vorderster Front vermutet, aber ACPI steht wahrscheinlich nicht ohne Grund an erster Stelle. Bislang habe ich um SSDT & Co. einen Bogen gemacht (nutze bislang keine), aber mal schauen, ob es sich lohnt, das für die SK zu ändern.
-
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?
-
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.
-
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
-
es wäre ernst gemeint
Unter Esoterikern (und davon gibt es in der HiFi-Szene reichlich) ist sowas ganz sicher ernst gemeint!
Ich hatte mich auch nicht auf Klangqualität, sondern auf Eindeutigkeit in der Zuordnung bezogen.