OpenCore Bootloader

muster48
Ich meine keine "spezielle" SSDT. Gibt es sicher. Ich meine, die Methode "GPRW", die in der DSDT vorhanden ist, umzubenennen. Somit ist die nach wie vor vorhanden, nur zielen Aufrufe via "_PRW" Methode auf die GPRW nun ins leere. Eine _PRW-Methode muss nicht zwangsläufig GPRW aufrufen wollen, es geht auch ohne. Aber wenn es der Fall ist, dann würde dieses Konstrukt mit der Umbenennung unterbrochen. Und nun kommt ein nächster Schnitt. Man schreibt eine "eigene" GPRW Methode in eine SSDT. Diese wird dann sofort als _DIE_ GRPW von den ebnutzenden Routinen erkannt und genutzt. Nun kann man damit die Aufrufe wie man möchte manipulieren und das neue Ergebnis an die umbenannte, aber dennoch weiterhin aktive "EX-GPRW" in der DSDT schicken.

So funktioniert es in zwei Schritten: original GPRW in DSDT umbenennen, zum Beispiel XPRW oder GOGO oder NICO oder was auch immer (nicht vorher vorhanden ist), und eine SSDT in der GPRW definiert wird.

Für weitere Geräte können ja eigene _PRW definiert werden.

Das Problem an der Sache ist ja, dass oft _GPE (_Lxx Level triggered GPE) für mehrere Geräte gelten, nicht individuell je Gerät.

Das kann man alles auseinander popeln, ich habe wie gesagt den Holzhammer genommen und die _PRW direkt deaktiviert. Global alle. durch Umbenennung.

Weitere Idee:

Sicher kann man auch explizit nur die _PRW von XHCI und ETH0 (oder wie auch immer konkret diese Geräte heißen (USB-PCH und Ethernet-PCH) umbenennen. Einfach die DSDT in einen Hex-Editor werfen und bei beiden Devices die _PRW finden und bissel drumrum nehmen, so dass es individuell wird. Dann könnte man diesen gewonnenen String per Bootloader suchen lassen und ersetzen durch einen, in dem das "_" durch "X" ersetzt wird.

...hallo apfelnico bei mir bleibt der Monitor "schwarz", nachdem ich den Rechner wieder aufwecke. Das liegt ja wohl an den angeschlossenen Thunderbolt Geräten.

Hättest du für dieses Problem eine Lösung? Habe meine GC-Titan Ridge jetzt mit der gepatchten DESIGNARE-Z390-NVM33-Elias64Fr.bin getestet. Das Problem besteht leider weiterhin.

Beste Grüße

maschinenwart

Hast Du Dich nur verschrieben oder hast Du wirklich deine GC TitanRidge Card mit der von Dir genannten Firmware "DESIGNARE-Z390-NVM33-Elias64Fr.bin" geflasht?

Eine "onboard"-Firmware in einer PCIe-Karte - und das funktioniert?

Mork vom Ork nee, ist tatsächlich so. Im tony-Forum wird das als eine gut funktionierende Kombination empfohlen. Ich kann zwar keinen Unterschied zur NVM23 feststellen, wollte die Karte aber vorerst nicht wieder zurückflashen.

Ich habe sogar mein Belkin Thunderbolt™ 3 Express-HD-Dock damit zum Laufen gebracht. Allerdings musste ich nach dem Rechnerstart immer das TB-Kabel einmal abziehen und wieder anschließen, sonst wurde es nicht erkannt. Audio, Ethernet, USB und TB funktionieren dann auch. Nur den Displayport habe ich nicht aktivieren können...

An das Belkin Dock habe ich dann über den Apple TB3-TB2 Adapter mein UAD Apollo angeschlossen und selbst das funktionierte! ABER wenn ich das Apollo ausgeschaltet habe, dann fror der Rechner ein.

Ohne das Belkin Dock gibt es keinerlei Probleme. Ich kann das Apollo ausschalten, umstöpseln, wieder einschalten, schütteln oder rühren macht dem Rechner nichts aus.

Ich habe heute auch noch einige Fragen.

Wo und wie finde ich im graphischen OC-Bootloader eigentlich die Optionen, wie ich es unter Clover gewohnt war?

Problem ist folgendes:

Auf meinem Lenovo T450s braucht die DW1820A für Mojave und Catalina noch unterschiedliche Kexts, welche ich mit einer zweiten config.plist ja realisieren könnte.

Vermutlich habe ich hier wieder was überlesen oder dat gibt's noch nicht.

Im Clover gibts im /kexts-Ordner ja die verschiedenen Unterordner. Im OC wäre dat via 2 config's auch möglich, mittels yes und no bei den Kext-Einträgen.

Ferner, zweite Frage, hat schon jemand einen Legacy-Rechner hinbekommen?

Ich versuche gerade einen alten Rechner mit OC, welcher mit Clover super geht.

Bootstick Legacy mit boot0/boot1 bootet, aber nach apfs-Driver, den ich noch sehe kommt Dunkelbild.

Für die alten Kisten ist ja wohl die FullSample gebräuchlich, wie ich gelesen habe.

Leider finde ich nix in Richtung "Inject Nvidia", was ich für diesen Rechner im Clover ja an habe für die GT330M.

Diese zweite Geschichte ist aber nicht so wichtig, wollte nur mal sehen, ob mit den unsupported SMBIOS und non-Metal's auch noch was geht mit OC.

MacPeet

Hab es jetzt nicht vor mir, nur mobil unterwegs. Aber geht da nix mit min und max Kernel?

apfelnico

Dankeschön. Jetzt habe ich den Sinn dieser min/max-Geschichte auch verstanden.

Es ist nun gelöst und es arbeitet auch wie es soll.

Der BrcmFirmwareData.kext liegt für Mojave und Catalina in unterschiedlicher Version vor und wird auch so gebraucht.

Zwei Kexts mit gleichem Namen geht ja nicht. Habe die Version für Mojave dann in BrcmFirmwareData2.kext umbenannt.

In dem Fall ging es, da keine Abhängigkeit untereinander besteht.

Bei Kexten mit Abhängigkeit muss man die Namensänderung sicher noch in den info.plist's der Kexts anpassen.

Die Lösung für die Thinkpad-Reihe sieht dann so aus:

nochmals Dank, Problem 1 ist damit vom Tisch

Zitat von MacPeet

Der BrcmFirmwareData.kext liegt für Mojave und Catalina in unterschiedlicher Version vor und wird auch so gebraucht.

Das lese ich zum ersten Mal, seit wann denn das? Bisher ist mir nur das bekannt:

Zitat von acidanthera

• BrcmPatchRAM.kext: for 10.10 or earlier.

• BrcmPatchRAM2.kext: for 10.11 or later.

• BrcmPatchRAM3.kext: for 10.15.

Harper Lewis

Ist hier wie folgt getestet:

Für Catalina habe ich die neusten Kexts BrcmBluetoothInjector.kext, BrcmFirmwareData.kext (ich verwende hier Version 2.5.1) und BrcmPatchRAM3.kext, dann geht hier WLAN und BT.

Für Mojave gab es damals BrcmFirmwareData.kext (2.2.10) und BrcmPatchRAM2.kext, dann geht hier WLAN und BT.

Wenn ich hier BrcmFirmwareData.kext 2.5.1 nehme und die BrcmPatchRAM2.kext, dann bekomme ich zwar WLAN, aber kein BT.

Der neuere BrcmBluetoothInjector.kext bringt für Mojave nix.

Ich denke, dass der BrcmFirmwareData.kext 2.5.1 speziell für Catalina noch Änderungen bekommen hat.

Hast Du andere Erkenntnisse dazu?

In meinem Laptop läuft Bluetooth mit BrcmPatchRAM2.kext unter Mojave, mit BrcmPatchRAM3.kext unter Catalina. BrcmBluetoothInjector.kext und BrcmFirmwareData.kext sind in den selben Versionen für Mojave und Catalina eingebunden. Ich habe die DW1560 im Einsatz.

Ok, danke, werde ich nochmal in Ruhe testen. Ich habe die schwierige Variante DW1820A.

Habe jetzt mal versucht mit OC 0.5.9 auf meinem Z97 den BootChime einzustellen. Ich habe AudioOut von 0-8 durch. Bei keinem höre ich irgendetwas. Vllt. kann jemand mal einen Blick auf meinen Config werfen weil ich evtl. was übersehen habe? OC Log hänge ich ebenfalls mit an.

Bin nach dem hier vorgegangen:

https://dortania.github.io/Ope…top-Guide/extras/gui.html

Sascha_77 gib doch mal. in dem Feld VolumeAmplifier glaube die Zahl 143 ein

Uefi>Audio>

Hallo zusammen,

sollte ich eigentlich regelmässig updaten ?

Ich Frage weil bei mir alles bestens funktioniert und ich mir unnötigen Aufwand möglichst ersparen möchte.

LG Marc.

Sascha_77

MinimumVolume darf nicht gleich oder höher sein, wie SystemVolume im NVRAM, ansonsten wird kein Audio abgespielt (siehe OC-PDF).

Wert 70 ist 46 Hex, insofern gleich. Lass da erst einmal die 20.

Ich habe die Werte so gelassen, wie in der Sample.plist, also AudioCodec und AudioOut auf Failsafe=0.

OC findet es allein, wie ich verstanden habe, im Normalfall. Man kann es auch angeben, muss aber dann richtig sein.

Wichtig ist, dass des AudioDevice passt, in Deinem Fall PciRoot(0x0)/Pci(0x1B,0x0).

So wie ich dat Anleitung-PDF von OC verstehe:

Deine 2 bei AudioCodec würde auf PCI 0x3 gehen (HDMI), oder? In dem Fall müsste das AudioDevice ja PciRoot(0x0)/Pci(0x3,0x0) sein.

Für Onboard-Audio Pfad 1B müsste es dann die 3 sein oder?

Bei AudioOut im Prinzip genauso.

Ich verstehe die Anleitung zumindest so. Wenn ich hier falsch liege, dann berichtigt mich bitte!

Wichtig könnte noch ein NVRAM-Reset sein, nach OC-Einstellungsänderungen.

Um Lautstärkeerhöhung würde ich mich erst kümmern, wenn es überhaupt mal mit dem Boot-Sound im OC klappt.

MacPeet ich hatte die gleichen Entstellungen wie bei Sascha, allerdings ist mein PCIRoot ein anderer, nachdem ich im Feld VolumeAmplifier den Wert 143 eieingetragen hatte funktionierte der Sound!

Du hast auf Deinem Bild aber MinimumVolume auf 20, wie in der Sample und AudioOut auf 3, was laut Anleitung-PDF auf OnboardAudio geht.

Hierbei ist es richtig, wie ich dat sehe.

Der Wert VolumeAmplifier 143 ist für die Lautstärkeanhebung sicher richtig. Ich werde es nachher selbst noch versuchen.

Und ja, Du hast einen der neueren Rechner, der das Onbord-Audio nicht auf 1B hat, sondern auf 1F, 0x3, was ja von AppleALC her schon bekannt ist.

In dem Fall ist das Device 1F in der Anleitung von OC genauso zu behandeln, wie bei den älteren Rechnern mit 1B und Onboard-Audio steht in der Anleitung bei allen genannten Punkten immer an Position 3, was für die Werte auch richtig sein sollte, sofern man sie überhaupt setzen muss. Den PCI-Pfad muss man auf jeden Fall setzen.

Bei ihm dürfte die 1B aber richtig sein, da er es in den DeviceProperties für den Betrieb mit AppleALC auch so drin hat.

Edit:

schmalen

Ich habe nochmal getestet.

Mit diesen Einstellungen hatte ich Boot-Sound im OC (graphische Oberfläche), allerdings zu leise, da 46 Hex = 70 % Sound.

Nun habe ich alles so gelassen, nur die nvram-Geschichte geändert:

63 Hex ist 99%, 64 Hex wäre 100%

Nach diesen Einstellungen und Neustart passiert erst einmal gar nix im OC-Bootloader, Lautstärke ist noch immer auf 70 % (46 Hex).

An dieser Stelle nicht ins System booten, sondern NvramReset wählen im OC.

Der Rechner startet neu und nun full Power beim Bootsound, also die eingestellten 99%, 1 Prozent auf 64 wäre hier noch möglich.

So jetzt hats auch bei mir geklappt mit folgenden Einstellungen:

Hi,

danke Sascha_77 , jetzt geht es auch hier.