Beiträge von kuckkuck

Zitat von 5T33Z0

kann man ja ssdtPRGen verwenden, um aus der erstellte SSDT mit Hilfe von ResourceConverter die CF-Freq Data auszulesen

Woher hast du das? ResourceConverter extrahiert nichts, sondern wandelt lediglich Dateiformate um. Dementsprechend würde es deine SSDT nehmen und als Ganzes umwandeln. Im CPUFriend.kext Source Code finde ich keine Indizien dafür, dass die Kext solche Daten verarbeiten kann.

In den Github Instructions heißt es:

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.

5T33Z0 Du kannst dir sicher sein, dass ich beim Schreiben kein Interesse daran hatte die Satzkonstruktion möglichst kompliziert zu gestalten. Dieser Thread ist doch für Fragen da, wenn es Verständnisprobleme gibt. Es steht dir natürlich offen und du bist herzlich von mir dazu eingeladen, entweder einen Guide zu den Inhalten zu verfassen, bei dem alles klar und eindeutig ohne Klärungsbedarf ist, oder entsprechende Verbesserungsvorschläge hier anzubringen, die ich dann gerne übernehme.

Zitat von bluebyte

kuckkuck es gibt noch Alternativen. Mac Pro 6,1 (Ivy Xenon). Mir geht es aber um die Plattform wo die RX580 mit VDA-Decoder unterstützt wird.

Aber genau darum geht es doch. Das SMBios in der config.plist bleibt komplett unverändert, nur CPUFriend erlaubt das injecten von CPU Parametern eines anderen SMBios, ohne das eigene zu ändern.

Zitat von bluebyte

Die für mich passende *.plist enthält keine Frequency-Vectors.

Das ist natürlich blöd. Konntest du bei per CPUFriend injecteter Mac-FC02E91DDD3FA6A4.plist einen Unterschied im Taktverhalten feststellen? CPUFriend injected nicht nur die Frequency-Vectors, sondern die ganze Plist mit allem drum und dran. Bei Benutzung des iMac13,2 SMBios konntest du ja Veränderungen feststellen...

Alternativ hast du natürlich immernoch die Möglichkeit die X86PlatformPlugin-Plist eines SMBios zu benutzen, dass eine ähnliche CPU wie deine besitzt und diese anzupassen.

bluebyte Dein Vorgehen ist prinzipiell (nach dem korrekten Einbauen der generierten Dateien) richtig. Da der iMac Pro eine CPU besitzt, die anders als deine verbaute CPU taktet, injectest du mit CPUFriend FrequencyVector-Daten, die zu deiner CPU passen. In deinem Fall hast du das Glück, dass ein iMac mit deiner CPU existiert, das ist natürlich nicht immer so.

Im Guide werden dann noch Schritte beschrieben, wie du die Frequency-Vector Daten weiter nach Belieben manuell anpassen kannst, um das Taktverhalten deiner CPU zu verändern. Vor allem in Fällen wo kein Apple Mac Modell existiert, dass die selbst verbaute CPU besitzt, sind diese Schritte wichtig.

5T33Z0 Everymac funktioniert natürlich auch. 4. wäre dann das händische Anpassen der FrequencyVector-Daten, um das taktverhalten weiter zu personalisieren oder optimieren. Nicht zu jeder Intel-CPU existiert ein passendes Mac SMBios mit identischer CPU. Vorallem die Anpassungs-Schritte bringen häufig erst das gewünschte Taktverhalten.

Der Guide hat nicht den Anspruch einfach zu sein, sondern den Anspruch vollständig und korrekt zu sein und technische Informationen an einem Ort zusammenzufassen, die so als Ganzes nicht ohne Weiteres im Internet auffindbar sind. CPUFriendFriends Mechanismen sind nicht vollständig und unterscheiden sich in Teilen zu den Inhalten, die im Guide behandelt werden.

Genau so ist es, den hilfreichsten Beitrag eines Threads kann nur der Fragesteller, oder Mitglieder des Teams, zB. Experten, markieren.

Wäre natürlich wünschenswert, wenn die Funktion ein wenig mehr benutzt werden würde

csr-active-config ist eine 4 byte Bitmaske. 00000000 ist ganz an, FFFFFFFF ist ganz aus. Damit bist du dir sicher, dass von der SIP absolut nichts übrig bleibt, wenn du das Gefühl hast, dass es daran liegt.

Ja, da sieht an sich alles "richtig" aus. Wenn du die SSDT-PLUG deaktivierst, hast du wahrscheinlich wieder das CPU Verhalten, dass du noch aus Clover Zeiten kennst. In dem Fall lädt dann das ACPI_SMC_PlatformPlugin. Wenn du einen Blick in den verlinkten Thread wirfst findest du aber:

Zitat von kuckkuck

Das X86PlatformPlugin ist das korrekte Plugin für aktuelle CPUs und Chipsets. Das Plugin sowie die bekannte Technologie XCPM (Xnu Power Management) ist tief in den Kernel Integriert und hat Einfluss auf viele Verschiedene Bereiche

Sollte dir das PowerManagement bei geladenem X86PlatformPlugin nicht passen, kannst du den verlinkten Guide befolgen, um das Plugin auf deine CPU anzupassen, bis du zufrieden bist.

64653A33 als Data und de:3 als String sind äquivalent, das sollte keinen Unterschied machen. Eher mal probieren die Sprache zu wechseln, wie von MacPeet vorgeschlagen, wenn es da wirklich Probleme mit Sprachpaketen gibt.

Ja, sieht eigentlich ok aus. Hättest du noch einen IORegistryExplorer Dump als zip? Hast du denn unter Clover auch eine SSDT-Plug benutzt, oder in der config plugin-type=1 aktiviert gehabt?

Zur Überprüfung kannst du auch einmal kextstat | grep X86 im Terminal eingeben.

Detaillierte Informationen zu dem Thema gibt es hier: CPUFriend Guide, HWP & Speedstep: X86PlatformPlugin vs ACPI_SMC_PlatformPlugin

Zitat von serdeliuk

maybe you can explain a bit the modifications added to Clover.

Sorry for the huge delay, I was away for a while. The main modification is the patch released in the first post which you can look at using the disassembler of your choice. Since the Kernel&Kext-Patcher within Clover didn't work at the time and I couldn't get it to work without studying all the messy code, I deactivated it in kext_inject. Furthermore the addition of two nvram variables was needed which I did using Clovers SetNvramVariable function. Take a look at the Clover Source in order to understand how it works. You can use if (os_version >= AsciiOSVersionToUint64("XX.XX")) to only execute your code when e.g. Big Sur is loaded (see DataHubCpu.cpp for reference).

The nvram variables to force prelinked kernel don't work anymore. The Kernel&Kext-Patcher within Clover works but the patches have no effect since the prelinked kernel isn't loaded. Clover has switched to an OpenCore based Kext Injection which is exactly what I was talking about. As stated many times, my patches where just a workaround and not future proof in any way which is why there was no reason to release any code but only to explain what changes I made.

This should be enough information to reproduce exactly what I did if this is what you are looking for.

Sehr schön erklärt

Zitat von apfelnico

Die unteren beiden "Zero" haben sich mir auch noch nicht erschlossen.

Reserviert für weitere mögliche Spezifikationen in der Zukunft

Hier aus dem ACPI Spec die Return Package Values:

Auch von mir ein herzliches Willkommen im Team kaneske

Edit: Whoops, mein Fehler mit dem Verschieben

Ich bin mir sicher kaneske wird das besser machen als ich *gg*

Ich weiß nicht welche Fehler da beanstandet werden.

Beim durchschauen fallen mir 3 Kleinigkeiten auf:

1. Die Porttypen (USB2 / USB 3) sollten bereits beim Ein- und Ausstecken der USB Sticks deklariert werden. Im Nachhinein ist es sonst häufig schwer noch nachzuvollziehen, welchen HS und SS Ports zusammen gehören und gemeinsam den gleichen Identifikator benutzen sollten.

2. Die Renames sind keine USBInjectAll spezifischen Renames und können deshalb auch nach der Benutzung von USBInjectAll beibehalten werden. Vorausgesetzt das Gerät besitzt überhaupt die entsprechenden Namen im ACPI.

3. Es gibt eventuell schnellere Methoden ohne USBInjectAll und die Bootargs die USB Ports zu konfigurieren. Ich sehe das aber als keine Kritik, denn dein Guide ist sehr schön ausführlich und sollte dank der Benutzung von USBInjectAll auch auf praktisch allen Systemen genau so funktionieren.

Verstehe, dann funktioniert ja sogar alles wie es soll... Und somit gilt dann wahrscheinlich folgendes:

Zitat von kuckkuck

Das ist interessant. Da aber nur ein FrequencyVectors Eintrag vorhanden ist, ist ja klar welcher gewählt wird. Der Eintrag unter Frequencies mit der Maximalfrequenz ist nicht zum Festlegen der Maximalfrequenz vorhanden, sondern nur zum Matching mit dem korrekten Eintrag unter FrequencyVectors.

Zitat von traeu

Auch wenn ich keinen direkten Unterschied spüre, hat es dennoch geklappt, auch die iMacPro1,1-Plist als Basis zu nehmen.

Verstehe ich jetzt nicht, ich dachte, das Problem war, dass bei der Wahl des iMacPro als Basis das Frequencies Array nicht vorhanden war

Zitat von traeu

Unterscheidet sich das Ergebnis des Ressource Converter Scripts, je nachdem ob man direkt die zur CPU passende Plist nimmt oder man erst FreqVectorsEdit verwendet?

Ja, du kannst ja mal beide Wege durchlaufen und dann vergleichen, das Ergebnis ist ein anderes. Häufig deswegen weil FreqVectorsEdit die SMBios Plist nimmt und darauf aufbauend Veränderungen macht. Auch sind die FrequencyVectors in manchen Fällen ein bisschen anders. Wer es simpel haben will kann sich aber den Schritt über FreqVectorsEdit auch sparen und wird höchstwahrscheinlich nicht darunter leiden.

Du musst letztendlich mit CPUfriend eine plist injecten, die auf deinen Prozessor passt oder angepasst ist. Wenn Unklarheiten im Guide sind gib mir bescheid.

schmalen Wenn sich das Taktverhalten ins Negative geändert hat, was spricht dann dagegen den Guide mal durchzuarbeiten? Danach hast du Ruhe.