CPUFriend Guide, HWP & Speedstep: X86PlatformPlugin vs ACPI_SMC_PlatformPlugin

    Danke für die Info. Gut zu wissen, dass es nicht nur mir so geht. Sieht aus nach eine Fall für CMD+Backspace :D

    5T33Z0 ja... Allerdings habe ich ja einen i9-9900K hatte ich im Post nicht erwähnt

    Mac Mini M2 Pro (2023) 16 GB RAM. 512 GB Sonoma 14.2

    real iMac 13.1    Ventura 13.01 (late 2012)

    real MacBook Pro 14.2 Sonoma 14.2   13" 2018



    kuckkuck


    Habe jetzt mit dem Script von Inspector42 nochmals die plist für den iMacPro1,1 erstellt.

    Nur einige Einträge sind an anderer Stelle, aber im Grunde wurden nur die FrequencyVectors entsprechend des CPU SMBIOS geändert (siehe Anhang). Na gut, dass muss ja jetzt nicht immer so sein und könnte eben nur in diesem Bsp. so aussehen.


    Mir ging es auch eher darum, welche Daten/Einträge ./ResourceConverter.sh. für die Erstellung des Kextes (cf-frequency-data) nutzt.



    Hätte dieses Skript nur die FrequencyVektoren verarbeitet, wäre es eben nicht nötig gewesen vorher das verwendete Profil mit dem gewollten Profil zu patchen.

    Habe dann hierzu etwas in der Anleitung von CPUFriend gefunden:

    Zitat

    file should be a complete plist from Recources inside ACPI_SMC_PlatformPlugin or X86PlatformPlugin with certain modifications (Otherwise why is CPUFriend even required?) instead of something like a raw FrequencyVectors entry.

    Anscheinend enthält cf-frequecy-data Daten der kompletten PLIST und nicht nur Frequency Vektoren. Somit ist das der Grund, warum wir zuerst unser verwendetes Board-id Profil mit dem CPU Board-id Profil patchen müssen.


    Ich hätte aber noch einen Punkt, der mich interessieren würde. Habe mal die 4 CPU`s vom iMac19,1 und dessen FrequencyVectors Einträge miteinander verglichen.

    Außer 3 bytes sind die Daten identisch. Weißt du, was diese Unterschiede effektiv bewirken?


    Grün=dezimal




    Zu guter Letzt noch ein Tipp für deine Anleitung.


    Eventuell könntest du noch ./ResourceConverter.sh -k "Mac-... .plist" für die Erstellung des CPUFriendDataProvider.kext hinzufügen.

    Zitat von LetsGo

    Mir ging es auch eher darum, welche Daten/Einträge ./ResourceConverter.sh. für die Erstellung des Kextes (cf-frequency-data) nutzt.

    Alles, und damit meine ich Byte für Byte. Wenn man sich das Script ansieht, sieht man die Nutzung von xxd.

    Das erklärt übrigens auch, warum manche Leute meinen ihre SSDT-CPU.aml durch das Script jagen zu können, um die entstandenen cf-frequency-data per CPUFriend zu injecten und kein Warning bekommen, dass CPUFriend so nicht funktioniert.


    Der Aufbau der FrequencyVectors ist nicht vollständig entschlüsselt. Du kannst für Anhaltspunkte zu den Unterschieden dir mal den Inhalt von FrequencyVectors.sh ansehen oder FrequencyVectors.bt als 010 Template über die FrequencyVectors jagen.

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    Sehr schön, das war ja schon immer ein bisschen Gefrickel. Dadurch dass der OC-Patch-Eintrag die Patch-Base symbolbasiert findet, hält der Patch ja vielleicht auch ein bisschen länger.

    Ich habe deinen Thread mal im Eingangspost verlinkt.

    Du kommst bei deinem Problem nach dem unendlichsten Versuch nicht weiter? Dann schreib mir eine Nachricht für eine TeamViewer Sitzung. Nur wenn es gar nicht mehr weiter geht!
    Alle anderen Fragen und Anliegen gehören ins Forum.

    5T33Z0 leider vier Monate zu spät. Die Erleuchtung kam dir schon am 28. Oktober 2020 [floet]


    CPUFriend Guide, HWP & Speedstep: X86PlatformPlugin vs ACPI_SMC_PlatformPlugin

    Spoiler anzeigen

    kuckkuck Ich habe mich mal endlich an das Thema herangewagt und dabei etwas interessantes festgestellt. Innerhalb des Threads sagtest Du, man habe keinen Vorteil davon einfach nur den CPUFriend.kext und/oder den DataProvider vom Host SMBios, bei abweichendem Prozessor, zu nutzen. Das man so nicht alles patcht. Klar, verstanden.


    Nun bin ich echt an der Thematik verzweifelt, weil er die iMacPro1,1 Plist einfach mit mit der iMac15,1 patchen wollte. Zumindest sah man in Mergly keine Unterschiede.


    Nun habe ich ein alte High Sierra Installation und habe dann angefangen genauer zu schauen.


    Feststellung 1: Mac-42FD25EABCABB274 und Mac-7BA5B2D9E42DDD94 sind in den FrequenzVektoren absolut identisch, schon zu HS Zeiten. Es gibt nämlich keine!



    Somit kann er auch keine Änderungen übernehmen. Überhaupt hat iMacPro und auch "(fast) alle" Haswell Systeme keine Frequenz Vektoren, wenn ich das Ergebnis vom Script richtig interpretiere.



    und



    Feststellung 2: Bei älteren Systemen ohne Vektoren hat das alles keinen Einfluß egal, welche cf-frequencies man injected. Da ist halt nur die Base und der Bias definiert. Besser, als nix.


    Jetzt zu der einen Ausnahme: Mac-35C5E08120C7EEAF.plist


    Der einzige Haswell mit Vektoren.



    Also, habe ich einfach die Vektoren unter 1 in die, Mac-7BA5B2D9E42DDD94. plist eingebaut, editiert und dann einen kext daraus erstellt. Und jetzt ist zum ersten Mal etwas anders.


    Fand ich interessant, gibt sicher noch den einen oder anderen Kumpel hier, der einen Haswell betreibt. Mein i7-4790k läuft sehr gut.


    Kombiniert mit der SSDTPrgen.dsl finde ich keinen Vorteil, nein mein System wird eher instabil. Button können z.B. sporadisch nicht gedrückt werden.


    Warum ich das mal loswerden muss - zuviel Zeit investiert, um es nicht mal nach draussen zu rufen.


    WER noch eine andere Idee hat, bitte gerne Erfahrungen mit mir teilen.


    Viele Grüße