OpenCore Sammelthread (Hilfe und Diskussion)
- derHackfan
- Unerledigt
-
-
Ich versuche mein T430 (10.14.6) von Clover 5020 auf OCv061 umzustellen, Kexte und OC alles nightly und aktuell.
Leider komme ich nicht weit, Bootvorgang bleibt bei VirtualSMC hängen. Ich vermute die Probleme bei ACPI. Kann jemand mal ich die EFI schauen und mir Licht ins Dunkle bringen?
EDIT: Ich ziehe die EFI erstmal zurück.
EDIT: Ich hatte Ungereimtheiten min sanity-EFI Checker gefunden, die ich nicht ausräumen kann.
Die in der config.plist aktivierten Kexte werden im EFI Checker nicht richtig gezeigt.
Beim booten bekommen ich Fehlermeldungen, die m.E. micht der EFI nicht übereinstimmen können. Derzeit Bootet 10.014.6 überhaupt nicht, kehr einfach ohne Bildschirmmeldung ins OC Menü zurück.
hier noch einmal die letzte Fassung der EFI
-
-
Sollte sicher eine wiederherstellbare Kopie vom ursprünglichen 'Add' sein. Dann aber bitte nicht einfach oldAdd sondern
#oldAdd, dann wird's von OC nicht gelesen.
-
die "oldAdd" war die alte Add vom T430 v057 von griven
die sollte OCX eigentlich icht lesen, habe diese jetzt gelöscht.
Die ACPI/Block hatte ich von Delete auf Block umbenannt, weil Sanity/EFI-Checker wegen einer Missing Block gemeckert hatte. Aber auch mit "Delete" geht z.Zt. an dem T430 nix. Denn 10.14.6./Recovery kann ich booten. Wenn ich aber Mojave booten will, scheitert das ohne jegliche Meldung und das Menü vom BootPicker(external) wird wieder aufgerufen.
hier mal der Sanity-Check mit letzten Aktualisierungen.
EDIT: Der Link hat irgendie nicht richtig geklappt.
Bis heute Mittgag hatte ich nur c060 zur Verfügung, jetzt zeigt mir der Checker die v061
-
-
-
die sollte OCX eigentlich icht lesen, habe diese jetzt gelöscht.
Das wird nur nicht gelesen, wenn dort eine Raute ( # ) davor ist, wie in der Sample.plist die Warnings.
Die ACPI/Block hatte ich von Delete auf Block umbenannt, weil Sanity/EFI-Checker wegen einer Missing Block gemeckert hatte.
Klar meckert der Checker, wenn du damit 060 configcheck eingestellt hast und du die config.plist einer 059 oder älter zum checken hochlädst oder vice versa.
-
karacho die EFI war schon auf v061 abgestimmt, jedenfalls annähernd. die letzte Fassung auf jeden fall. Der Saint-Checker hatte allerdings nicht die v061 angeboten, sondern lediglich v060. Der Unterschied mag nicht so groß sein. Jedenfalls sollte unbedingt ACPI mit Block gefüttert werden, obwohl Delete schon drin war.
Der Rest der Probleme saß dann vorm Bildschirm
Was hälst Du von der Config.plist?
Warum bootet OC nicht, nicht mal eine Zeile zu sehen trotz -v ??
Edit. Problem erstmal gelöst. Filevault war deaktiviert. Bei besserem Englisch hätte ich das eher erkannt. Genügt nicht grüne Häckchen zu haben im Sanity- Checker.
Allerdings Freezt der Bildschirm wie verrückt. Komplett tot. Mit Powerknoopft lässt sich ausschalten aufrufen und mit Entertaste fährt das Teil runter.EDIT es wird
EDIT:2: Was nicht funktioniert ist Audio. Alle bekannten Layout-ID's ausprobiert 28, 33, 127
Mit Clover funktioniert 33 Leider scheint der Eintrag nicht zu greifen.
Muss ich die Devicepropertie des Audiointerface unter UEFI/Audio eintragen? Schreib vom IPhone und habe die Doku nicht griffbereit.
-
Muss ich die Devicepropertie des Audiointerface unter UEFI/Audio eintragen?
Nein. Das wird bei DeviceProperties->Add eingetragen, so wie du es schon drin hast. Die layout-id 21000000 sieht auch gut aus. Lösche mal alcid=33 und -lilubetaall. Mit einer aktuellen Lilu.kext brauchst du -lilubetaall nicht, und die layout-id hast du schon in den DeviceProperties. Wenn mit layout-id 21000000 kein Audio, dann mal mit der 7F000000 (127) oder der 1C000000 (28) probieren.
-
komischer Weise muss man manchmal auch alc-layout-id eintragen damit es funktioniert...
-
-
-
-
-
Hello, tell me, did someone install opencore for lynnfield processors, p55 motherboards? Specifically, I'm wondering if anyone knows how to make opencore 0.6.0 (1) work for asus p7p55d pro + Xeon x3470 + rx5700xt. This worked for opencore 0.5.8 for sure and still works for any clover version.
-
locojens geht beides, lass dich nicht beirren
Eben entweder bootarg (überschreibt alles, geht wohl rechte mäßig vor) oder DevicePropertie.
Eben probiert verhält sich genau so.
Habe ich genauso eingerichtet, ohne boot-arg, dafür mit alc-layout-id. Hier der passende Lesestoff: https://github.com/acidanthera…ALC/wiki/Supported-codecs
Dass man inzwischen auch "layout-id" verwenden kann, habe ich irgendwie verpasst, probiere ich aber nachher gleich mal aus.
-
Ich meinte natürlich das Release der AppleALC ab 1.5.0 und da steht auch was dazu im Release-Text.
Ich hatte oben auch geschrieben: "eigentlich nicht mehr", wollte mich da auch nicht zu weit aus dem Fenster legen oder jemanden verunsichern, sorry.
Ich verwende keine DeviceProperties. Der Inject ist hier in einer SSDT gesetzt und dort geht es absolut nicht mehr seit 1.5.0.
Vorher hatte ich dort immer layout-id=07000000 gesetzt, da ja alle Codecs auf 7 umgepatcht werden von der AppleALC und alc-layout-id=0F000000 für 15 drin.
Seit 1.5.0 lief dies nicht mehr via SSDT und ich habe jetzt nur noch layout-id=0F000000 für 15 drin, was so vor 1.5.0 nicht funktionierte.
Im IORegistryExplorer kann man aber auch dort dann wieder sehen, dass AppleALC alles umpatcht. Dort steht dann wieder layout-id=07000000 und alc-layout-id=0F000000.
Es ist ja durchaus möglich, dass es via DeviceProperties noch erhalten blieb und noch immer so geht.
Vermutlich war dieser Patch aus dem Release-Text nur für Inject via DSDT/SSDT gedacht.
Ich denke aber, dass hier layout-id inzwischen genauso geht und die AppleALC es ohnehin nun erkennt, auch wenn man es via DeviceProperties setzt.
Wie ozw00d schon schrieb, hat der Bootflag alcid=xx immer Vorrang vor DeviceProperties oder Inject via DSDT/SSDT.
Die verlinkte Seite wird von den Jungs leider nicht so ganz aktuell gehalten. Alle neuen Codec-ID's der letzten Release's sind dort leider noch nicht drin. Stand ist wohl Juni.
Besser man schaut in den SourceCode im Resources-Ordner.
Heute nun kam das neue Release 1.5.2 der AppleALC raus, nachdem die neuen Pull requests bereits vor Tagen aufgenommen wurden.
Früher war dies immer zeitnah und gleichzeitig passiert, aber die Entwickler haben genug zu tun, somit kann es auch mal länger dauern.
Ich bin mal gespannt, nach so vielen Controller-Patches für die neuen Rechner der Intel 400er Serie, ob hier nun was geht, ohne FakeID.
Mich betrifft es ja nicht, aber einige hier warten ja auf eine Lösung diesbezüglich.
-
-
Ich habe jetzt von einer Nightly 0.61 vom 21.8.2020 auf die Release 0.61 upgedated, klappte auch auf Anhieb
Eine Frage hätte ich es ist der Punkt DisableLinkeditJettison dazugekommen welcher im Sample auf YES eingestellt ist, das habe auch so übernommen.
In der Differences steht auch noch folgendes:
"This option lets Lilu.kext and possibly some others function in macOS Big Sur with best performance without keepsyms=1 boot argument."
Kann ich das so verstehen das keepsyms=1 nicht mehr benötigt wird ?