Geräte Eigenschaften (Device Properties) ohne DSDT Patch ändern.

    • Hilfreich

    Nichts währt ewig
    Die Vega lief OOB von Anfang an. Sie brauchte keine Hilfs-Karte, Sound funktionierte und sogar Sleep ging ohne Patches.
    Die Performance war allerdings schlechter als erwartet und die OpenGL Implementierung lies eine Menge Raum für Verbesserungen.
    Seit der ersten 10.13.2 Beta waren Leistung und OpenGL Unterstützung zufrieden stellend, aber der Sleep Modus ging nicht mehr.
    Jetzt mit der 10.13.3 Beta 1 geht der Sleep Modus wieder, wenn auch nur mit bestimmten Framebuffern.
    Dies ist der Anlass eine alternative Methode zum Verändern von Geräteeigenschaften zu beschreiben.


    Häh ?
    Die Hardware des Hacks besteht aus vielen Geräten (Devices) CPU, PCIe Karten, USB Ports, Kartenleser usw. Manche Geräte haben wieder Untergeräte.
    Alle Geräte, die das System kennt werden in der IORegistry zusammengefasst. Jedes Gerät hat Eigenschaften (Properties), manche tauchen bei verschiedenen Geräten auf und manche sind gerätespezifisch.


    Aaah
    Welcher und wieviele Framebuffer verwendet werden wird anhand solcher Geräteeigenschaften bestimmt. Diese spezielle Eigenschaft findet man natürlich nur bei Graphikgeräten.


    Ja, wo kommst du denn her ?
    Einige Geräteeigenschaften setzt der Geräte Treiber andere stammen aus der DSDT oder werden per Software gesetzt.
    Clover z.B. kann für einige Geräte bestimmte Eigenschaften und für manche Geräte beliebige Eigenschaften setzen.
    Man kann Eigenschaften auch über die DSDT oder eine SSDT setzen - vorausgesetzt das Gerät taucht dort auf.
    Die Eigenschaften setzt man in der _DSM Methode des Gerätes.
    Für die Grafikkarte sähe das so aus:



    Hier werden 4 Ausgänge festgelegt, die jeweils den ATY, Kamarang Framebuffer verwenden.
    Zusätzlich werden Slotname, Modelbezeichnung und Soundausgaabe festgelegt.


    Immer die selbe dröge Tabelle
    Ich ändere ungerne die DSDT.
    Uns liegen die DSDT Quellen nicht vor, sondern wir verwenden ein Tool (MaciASL), dass aus dem vorliegenden Code die Quellen erzeugt.
    Das funktioniert nicht perfekt und man verschwendet erst einmal einige Zeit damit die Umwandlungsfehler zu beseitigen.
    Oft werden einfach Patches angewandt ob man sie braucht oder nicht und die Patches überschreiben oft was existiert ohne Teile, die man vielleicht braucht zu erhalten. Kürzlich kam ich zu einem System bei dem USB nicht funktionierte und es stellte sich heraus, dass die DSDT zwei verschiedene USB Chipsets unterstützt und die Auswahl des richtigen Chipsatzes aud der DSDT entfernt worden war.


    Ohne vernünftige Dokumentation fängt man beim Wechsel des MoBos von vorne an - nachdem man erstmal die ganzen Patches zusammengesucht hat.
    Es gibt aber auch Gründe die DSDT Patch Methode anderen vorzuziehen und wer glücklich damit ist soll auch dabei bleiben.


    Alternative Liste
    Die hier vorgestellte Alternative ist ein Kext, dass die Properties aus einer Liste kopiert und einträgt.
    [Edit]
    Es sei nicht verschwiegen, dass es Fälle gibt in denen die Methode im Gegensatz zum Patchen der DSDT nicht funktioniert. Ein Beispiel sind FakeIDs[/Edit]


    Man editiert die Info.plist des Kext und kopiert es in den EFI/CLOVER/kexts/Other Ordner der EFI Partition.


    Zum Editieren der Info.plist sollte man XCode verwenden, es macht das Leben einfacher.


    Nicht schon wieder Kexte
    Aufbau und prinzipielle Funktionsweise eines Kextes sind in Kext as Kext Can beschrieben.


    Das Kext heißt PropertyInjector.kext. Es enthält eigenen Programmcode.
    Wenn man dessen Info.plist in XCode öffnet sieht man:



    Bis auf IOKitPersonalities braucht uns das Alles nicht zu kümmern.
    Im Folgenden wird deshalb nur noch der Ausschnitt mit den IOKitPersonalities gezeigt.


    Man legt für jedes Gerät für das man Properties ändern oder hinzufügen will eine Personality an.


    Ich will die Framebuffer meiner Vega ändern also nenne ich die Personality ... Vega, jeder andere Name hätte es auch getan, aber ich will ja ohne viel nachzudenken wissen worum es geht.



    Jede Personality muss wissen welches Programmstück ausgeführt werden soll deshalb bekommt sie Einträge für IOClass und CFBundleIdentifier.



    Die Werte müssen die dort angegebenen sein.


    Als nächstes müssen wir das Gerät identifizieren, dessen Properties ergänzt oder geändert werden sollen.


    Nichts ist unmöglich
    Es gibt eine Reihe von Parametern die man dazu verwenden kann und hier liegt ein Vorteil dieser Methode Properties zu editieren, man kann sie nicht nur auf Geräte, die in der DSDT vorkommen anwenden, sondern alle Geräte, die in der IORegistry auftauchen, wie z.B. USB Geräte.
    Die Optionen zur Gerätewahl wären einen eigenen Artikel Wert - ein andermal.
    Wir beschränken uns jetzt hier auf die Auswahl eines bestimmten PCIe Gerätes.



    In diesem Fall wollen die Werte für ein PCI Gerät ändern, deshalb die IOProviderClass IOPCIDevice.
    IOPCIPrimaryMatch sagt uns mittels Device und Vendor Id welches PCI Gerät gepatched werden soll..


    Es gibt verschiedene Möglichkeiten diese herauszufinden.
    Im Systembericht unter Grafik/Displays zum Beispiel



    GeräteId 0x6863 und Hersteller 0x1002 zusammengefasst zu einem Wert 0x68631002.


    Eigenes Schaffen
    Jetzt fehlen nur noch die Properties.
    Die Properties werden in ein Dictionary mit Namen Properties geschrieben.



    Dass die Properties @0,name bis @3,name heißen haben wir oben festgestellt. Der Framebuffer heißt ATY,Iriri und ist vom Typ String.


    Neustart und fertig.


    Alles roger ?
    Mal sehen. Startet man den IORegistryExplorer und sucht nach Vega sieht man vor der Änderung 6 Framebuffer vom Typ ATY,AMD,RadeonFramebuffer:



    Und nach der Änderung 4 vom Typ ATY,Iriri:



    Das soll es schon gewesen sein ?
    Weiter oben sieht man, dass die Karte als AMD RX xx erscheint.
    Auch das kann man mit einem Property ändern.



    Dann erscheint die Grafikkarte als



    War's das jetzt ?
    Mmmmh, fast.
    Im Systembericht erscheint unter PCI nur eine Fehlermeldung.
    Möchte man, dass Geräte erscheinen benötigen sie einen AAPL,slot-name, name und model Eintrag. Je nach Gerät ist der eine oder andere schon definiert.
    Wichtig ist, dass diese Einträge vom Typ Data sind.
    Hier ist das Kext mit dem Framebuffer Patch, den Vega Frontier Patch und den "PCI Patches" für LAN, WLAN und Vega.
    Da LAN und WLAN andere PCI Geräte sind benötigen sie eigene Einträge unter IOKitPersonalities.



    Das sieht dann im Systembericht so aus:



    Is gut jetzt, lass es
    Ok, das war's.


    Falls Fragen bitte nur zur Methode, nicht welches Property wozu dient oder welches Property welches Feature beim Laptop xyz frei schaltet.
    Solche Fragen gehören in den jeweiligen Problem Thread.


    P.S.
    Das Beispiel Kext
    PropertyInjector.zip
    Für eigene Projekte die IOKitPersonalities löschen, ändern oder ergänzen.

    2 Mal editiert, zuletzt von Brumbaer ()

  • Richtig krasser Kram, vielen Dank für diese (deine) Methode, du verstehst es wirklich die Leute zu beeindrucken. :D



    Edit: Das funzt sogar mit einem AMD System! :thumbup:



    Edit: Grafikkarte hinzugefügt.



    Edit: Audio hinzugefügt.

  • Wirklich eine super coole Sache!


    Die Eingangsproblematik verstehe ich sehr gut, weshalb ich ebenfalls auf keine vorgefertigten DSDT Patches zurückgreife.


    Immer die selbe dröge Tabelle
    Ich ändere ungerne die DSDT.
    Uns liegen die DSDT Quellen nicht vor, sondern wir verwenden ein Tool (MaciASL), dass aus dem vorliegenden Code die Quellen erzeugt.
    Das funktioniert nicht perfekt und man verschwendet erst einmal einige Zeit damit die Umwandlungsfehler zu beseitigen.
    Oft werden einfach Patches angewandt ob man sie braucht oder nicht und die Patches überschreiben oft was existiert ohne Teile, die man vielleicht braucht zu erhalten.


    Also wenn DSDT edit, dann mit der DSDT, extrahiert aus dem BIOS und korrekt dekompiliert (zB mit der häufig benutzten refs.txt Methode) und dann von Hand, ohne Patches. Die Patches sind wirklich häufig sehr grob. Da mich das selber gestört hat, benutze ich an meinem System ausschließlich Renames und danach SSDTs, um unter anderem _DSM Properties hinzuzufügen. Also genau wie die Kext — oder auch nicht?!?
    Mich würde interessieren, wie die Kext die Properties injected und zu welchem Zeitpunkt sie das tut. Ist das im Prinzip das gleiche wie _DSM SSDTs aber in grün? Oder unterscheidet sich die Funktionsweise vom injecten durch zusätzliche ACPI Tabellen? Wird hier direkt in das ACPI eingefügt oder in den Kernel oder wie soll man sich das vorstellen?
    Falls das ganze auf ACPI Ebene passiert, wie sieht es mit anderem als Properties aus? Könnte man auch FakeDevices (EC, ALS0, PNLF, MCHC und diese Klassiker) einfügen oder auch _INI Methoden über die Kext injecten?


    Generell ein sehr spannendes Thema und vielen Dank für diese tolle Idee und Ausführung!

    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.

    Einmal editiert, zuletzt von kuckkuck ()

  • Pffff ich verstehe nur Bahnhof! Trotzdem sehr interessant zu lesen was es für möglichkeiten gibt!

  • Sehr interessant und super geschrieben. Werde das mal testen.

  • Krasse Sache. Kann man damit auch die IDs von rebrandeten WLan-Karten umbiegen?


    Bzw. heisst das generell, das man im Grunde die DSDT gar nicht mehr dumpen und patchen muss sondern nur diesen Kext verwenden braucht?

    Einmal editiert, zuletzt von Sascha_77 ()

  • Krasse Sache. Kann man damit auch die IDs von rebrandeten WLan-Karten umbiegen?
    Bzw. heisst das generell, das man im Grunde die DSDT gar nicht mehr dumpen und patchen muss sondern nur diesen Kext verwenden braucht?


    Hab keine Ahnung von rebrandeten Karten, aber, falls es wirklich nur um die Eigenschaft "device-id" im DT geht, dann wird das sehr wahrscheinlich gehen.
    Und nein, die DSDT sollte man immer noch patchen, weil nicht jeder Patch nur Eigenschaften hinzufügt.
    Wer lieber keine Kexts nutzen will, kann das ganze auch auf UEFI-Ebene mit dem DevicePathPropertyDatabase-Protokoll lösen

  • Genau, es geht sich nur um die ID's bzw. SubID's. Dann werd ich das mal testen. Braucht statt 3 dann nur noch 1 Kext.

  • Ich bezweifle, dass eine FakeID funktioniert, außer vielleicht in besonderen Fällen.


    Die Routine wird angestossen, wenn das Gerät initialisiert wurde. das geschieht zusammen mit anderen Untergeräten und Treibern. Es ist anzunehmen, dass die Auswahl der potentiellen Geräte/Treiber schon erfolgt ist.


    Es könnte allerdings funktionieren wenn zwischen dem Gerät und dem "Ziel des Fakes" ein paar Stufen liegen.


    So funktioniert z.B. das "Faken" der Plugin Id um X86Platform zu laden, da zu dem Zeitpunkt zu dem Entschieden wird ob es oder die SMC Platform geladen wird, die Plug In Id schon gesetzt wird.


    Es stellt sich auch die Frage ob die für den Matching Prozess der "Kinder" verwendete ID tatsächlich die Werte aus den Properties sind oder ob dazu Werte verwendet werden und die Properties nur deren "Ansicht" sind.


    Lange Rede kurzer Sinn, ich denke man müsste eine aufwändigere Methode realisieren um FakeIDs erzeugen zu können.

  • Feine Sache, besten Dank dafür!


  • Ich glaub der Typ hat bei sich die absolut perfekten Vorzeigehackis stehen :P

  • Wie ist das bei zwei Vega's ?
    Sobald AAPL,slot-name 16_1 gesetzt ist, denkt die zweite Karte ebenfalls das sie in 16_1 steckt.

    Einmal editiert, zuletzt von DSM2 ()

  • [edit]Sorry, das bild war falsch[/edit]


    Es gibt mehrere Ansätze, einer ist sich im IORegistryExplorer ein Property zu suchen, in dem sich die beiden Karten unterscheiden und dies zur Selection heranzuziehen.


    Hier ist pcidebug zu sehen.
    Du modifizierst den IOKitPersonality Eintrag so dass dieses Property auch zur Identifikation herangezogen wird.
    Das machst du mit IOPropertyMatch und dem zugehörigen Untereintrag mit dem Namen des Properties (pcidebug). Darauf achten, dass Name, Type und Wert des Untereintrags auch stimmen.



    Dann kopierst du die komplette Personality und änderst der Wert von pcidebug auf den Wert der zweiten Karte.



    Möglicherweise kann man das eleganter über die Slots selbst lösen, habe aber gerade leine Zeit das zu testen.

    Einmal editiert, zuletzt von Brumbaer ()

  • Also entweder ich mache etwas falsch oder aber es will einfach nicht.
    Tippe eher auf das erste...
    Könntest du dir das vielleicht mal anschauen @Brumbaer ?


    Hab folgende Werte für pcidebug genutzt


    GPU:1



    GPU:2



    Problem ist das sobald die zweite Karte eingetragen ist, beide Karten auf 16_3 stecken.

    Dateien

    Einmal editiert, zuletzt von DSM2 ()

  • @DSM2
    Guten Morgen,
    ich hatte gestern Nacht noch das Bild geändert. Das IOPropertyMatch gehört nicht in die Properties, sondern eine Ebene höher.


    Ich habe es in deinem Kext angepasst.


    Es wird trotzdem nicht funktionieren, da du die pcidebug Werte von GFXB verwendest, die Patches sich aber auf die jeweils zwei Einträge tiefer liegenden GFX0 und GFX1 beziehen. Deren pcidebug Werte sind andere. Da ich sie von hier aus nicht sehen kann, habe ich sie auch nicht angepasst.


    PropertyInjector.zip

  • Guten Morgen und danke dir!
    Ok, dann werde ich gleich mal auf die Suche nach den korrekten werten gehen.


    EDIT: Also irgendwie finde ich keine anderen pcidebug werte ausser die ich vorher eingetippt hab.


    Komisch ist auch das wenn IOPropertyMatch nicht in Properties drin ist die Karten als AMD RX xxx laufen obwohl im Kext ja anders benannt.

    Dateien

    • Mac Pro.zip

      (4,34 MB, 160 Mal heruntergeladen, zuletzt: )

    2 Mal editiert, zuletzt von DSM2 ()

  • Hier:



    Wichtig ist, dass du den Wert vom richtigen Device nimmst.

  • Hey,
    erstmal muss ich wirklich den Hut vor dir ziehen. Kenne mich mit solchen Dingen mal gar nicht aus. Wie du in meinem Profil sehen kannst, besitze ich auch eine Vega. Jedoch eine 56er.
    Zur Zeit benutze ich 10.13.1 (ohne Sicherheitsupdate), da mit diesem mein Hacki nicht mehr schlafen wollte.
    Meine Frage ist nun:

    Zitat

    Framebuffer heißt ATY,Iriri

    Hat die 56er den gleichen, oder wie bekomme ich das raus. Würde mich heute Abend gerne einmal daran versuchen. Des Weiteren benutze ich eine angepasste DSDT von einem anderen Forumsmitglied. Kann ich diese weiternutzen, oder muss diese entfernt werden?


    Danke schon einmal für eine Antwort


    Grüße aus Augsburg

    System:
    Handmade
    Maindboard GB Z370 Aorus Gaming 7 Bios Latest (SMBios iMac19.1)
    CPU Coffee Lake i8700k
    Graka Powercolor Vega 56 (Watercool)
    Wasserkühlung Alphacool Eisbär 240
    Monitor Dell U3417W

    10gbit Nic Asus XC 100 C

    2 x 8 GB DDR 4 2400
    1 x NVME Big Sur
    1 x 1TB GB Datenplatte
    1 x 3 TB WD Green (TimeMachine Platte)
    Bootloader Open Core 0.67


    Unraid 6.9.1 Server im Keller

    Fujitsu Board D-3644-B mit C246 Chipsatz

    Xeon 2126g

    2x 16 GB nonBuf DDR4 ECC Ram Samsung

    1x Intel X550 10gbit NIc (Supermicro Karte)

    1x e1000 Intel NIc 1gbit Onboard

    3x 10 TB IronWolf (Array)

    2x 1 TB NVME (Cache)

    1x 250 GB SSD VM Xpenology für Surveillance Station

    1x 250 GB SSD VM Win10 Pro (Arbeitsrechner für Frau per RDP)

    2 Mal editiert, zuletzt von Cheesy ()

  • Der PropertyInjector wird nach der DSDT aktiviert und "arbeitet" mit dem was ihm die DSDT "hinterlässt". Also DSDT und PropertyInjector zusammen sind kein Problem.


    In diesem Thread bitte nur Fragen zur Methode, nicht zu Properties und deren Auswirkung.