Powercolor R9-290X soweit so gut, aber...

  • Ich muss leider zugeben bei den AMD Karten bin ich reichlich unbeleckt...


    Bisher hatte ich eine R9-270X die sich mit dem inject des Futomaki Framebuffers über die DSDT oder eben Clover zufrieden gegeben hat. Woltle man noch HDMI Audio hat man die entsprechenden DSDT Fixes eingebaut und gut wars. Nun habe ich günstig eine Powercolor R9-290X geschossen und damit ist es leider nicht so einfach sprich mein Denkansatz nimm mal einfach den Inject von der 270X und änder den Framebuffer auf Baladi ist leider grandios gescheitert...

    Wie auch immer mein Status Quo ist das ich mit einem Framebuffer Patch für den AMD8000Controler.kext soweit bin, dass ich die Karte nutzen kann ohne das ich WhatEverGreen benötigen würde :D


    Der Patch sieht wie folgt aus (Hex) Find:

    Code
    1. 000400000403000000010300000000001204030300000000000400000403000000010100000000001102010100000000000400000403000000010200000000002103020200000000000400000403000000010400000000002205040400000000000400000403000000010500000000001000050500000000000400000403000000010600000000002001060600000000

    Replace:

    Code
    1. 000400000403000000010100000000001204020100000000000800000402000000010200000000002205030300000000040000000402000000010300000000001102010400000000040000000402000000010400000000001000060600000000000400000403000000010500000000001000050500000000000400000403000000010600000000002001060600000000

    und weil es mich gestört hat Clover den Inject zu überlassen habe ich in der DSDT neben der init Methode noch folgende DSM Methode gesetzt:

    Soweit, so fein nur gibt es ein paar Probleme, die noch zu lösen wären. Zum einen funktioniert HDMI Audio nicht (ist nicht so wichtig) zum anderen kann ich weder in die Recovery booten noch in einen Installer beides endet bei mir darin das beide Bildschirme nichts anzeigen obwohl sie aktiv sind (Backlight ist an). Habt Ihr eine Idee was mir noch fehlt?!?


    @Mork vom Ork vielleicht eine Idee?!?

  • Könntest du eventuell kurz sagen, wie der Patch zustande kam?


    Funktioniert alles, wenn du mit Clover einfach den Framebuffer Baladi für die Karte in der passenden Sektion setzt?


    Wie viele Eingänge hat die Karte? Bist du dir sicher, dass du mit dem letzten Eintrag "@3,name" auch alle hast?


    Zu HDMI Audio:
    Könntest du mir eventuell einen IOREG Dump zukommen lassen? Ansonsten kontrollier erstmal, ob nach dem Device GFX0 das passende Device HDAU bei @0,1 kommt und beide in den Properties "hda-gfx 'onboard-1"' besitzen. IGPU und das sich auf der gleichen ACPI (Path-) Ebene befindliche HDAU Device müssten dann jeweils den Eintrag "onboard-2" besitzen.

    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.

  • Hier mal der Dump vom IOREG: bert.zip


    Und nö wenn man in Clover nur Baladi als Framebuffer setzt zusammen mit Inject ATI und RadeonDeInit, natürlich ohne DSDT/SSDTS, guckt man in zwei zwar aktive (Backlight ist an) aber leere Monitore. Den Framebuffer Patch habe ich mir anhand diverser Anleitungen aus diversen Quellen selbst zusammengebaut und zumindest beim installierten System geht es so ja auch...

  • Ich schaue mir den IOReg später mal an. Der Patch des AMD8000Controler.kext lässt sich ja an sich nicht direkt über die DSDT durchführen, jedoch hab ich mir nicht genau angeschaut was der Patch macht, könntest du das kurz sagen? Handelt es sich lediglich um einen Connector Patch?

    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.

  • Ist lediglich ein Connector Patch. Der Baladi Framebuffer ist definiert mit 6 mal DP was meiner Karte ja nicht gerecht wird. Daher habe ich die erste vier so gepached das sie zu meiner Karte passen (DP,HDMI,DVI,DVI) die beiden übrigen habe ich gelassen wie sie waren.

  • Ein Connector Patch über das bloße ACPI könnte möglich sein, dazu gab es hier einen Thread: DSDT Connector-Patch
    Auf der zweiten Seite hatte ich nochmal einen Versuch gestartet... Dein bisheriger DSDT Patch setzt bisher jedoch lediglich den Framebuffer und kann somit nicht deinen K2Patch ersetzen. Deswegen wahrscheinlich das Problem.


    ConnectorPatch geht auf jeden Fall auch mit Whatevergreen, wenn die passenden Daten per SSDT/DSDT an Whatevergreen gefüttert werden.


    Hast du schonmal nachgeschaut was das AMD Framebuffer Utility dir für einen ConnectorPatch und Framebuffer vorschlagen würde? Du könntest auch einen FB mit weniger Ports wählen, eventuell findet sich sogar ein FB der besser auf deine Ports passt und somit zuverlässiger funktioniert und keinen ConnectorPatch braucht...

    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.

  • Das Tool benutzt Baladi als Original und schlägt die selben patches vor die ich auch manuell aus dem ROM Dump mit radeon_bios_decode und redsock_bios_decoder ermittelt habe.
    Wie gesagt im laufenden System ist das alles auch gar kein Problem die Patches laufen soweit und ich bekomme an allen Anschlüssen auch ein Bild auch Dual Monitor ist kein Problem. Ich habe aktuell einen Screen am DP und einen an DVI und es tut wie es soll. Was mich halt stutzig macht ist das ich weder in den Installer (USB Stick) noch in die Recovery booten kann denn in beiden Fällen wird die Grafik initialisiert aber die Screens zeigen nichts an (Hintergrundbeleuchtung ist aktiv) das Ganze geht dann auch nicht wenn ich alternativ WhatEverGreen benutze sprich auf einem Stick bei dem Clover ohne Patch werkelt tut auch WhatEverGreen nichts was das Verhalten ändern würde.

  • und weil es mich gestört hat Clover den Inject zu überlassen habe ich in der DSDT neben der init Methode noch folgende DSM Methode gesetzt:


    Ok dann hab ich dich evtl. missverstanden... Hast du den Connector Patch in Clover und zusätzlich den DSM Eintrag oder ist das Ziel den Connector Patch über den DSM Eintrag zu setzen?


    Zum einen funktioniert HDMI Audio nicht


    Mal überprüft? Post 2


    Whatevergreen sollte ja auch in der Recovery laden. Dementsprechend könntest du mal versuchen die Connectors über WEG patchen zu lassen. Dafür musst du den"connectors", Buffer () Eintrag in der DSM Methode hinzufügen, denn Whatevergreen ließt diesen aus. Ein Sample dafür findest du hier: https://github.com/vit9696/Wha…/master/Manual/Sample.dsl
    (ab // Only use this if you need special connectors that are incompatible with the automatic connector detection "connectors",)


    Edit: In diesem Zuge wäre auch das DSM Property

    Code
    1. // You may only specify this with connectors property when the amount of connectors differs from autodetected
    2. "connector-count",
    3. Buffer ()
    4. {
    5. 0x04, 0x00, 0x00, 0x00
    6. },


    für dich interessant.

    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.

  • Okay wenn ich die Connectors in die DSDT haue und dann WhatEverGreen dazu nehme kann ich sowohl in den Installer als auch in die Recovery booten das ist schon mal ein Teilerfolg :D Der weitere Weg geht dann dahin das Ganze ohne WhatEverGreen zu realisieren. Ich schau mir nachher mal das Thema an wie man das übers ACPI lösen kann. Für den Moment ist das aber schon mal eine Lösung mit der man leben kann.

  • Das ist doch schonmal gut zu hören :thumbup:


    Für ACPI und connector-type habe ich hier einen Ansatz beschrieben: Post 25


    Ich bin jedoch immernoch nicht dazu gekommen zu testen, ob das ganze jetzt wirklich funktioniert, oder sich die connector-type _DSM Properties nicht überschreiben lassen. Ein weiterer interessanter Versuch wäre, wie @derHackfan bereits erwähnt hat, den PropertyInjector für das injecten der connector-types zu nutzen, da dieser anders als Clover ACPI Injection vorgeht...

    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.

  • Ich habe jetzt mal mit dem PropertyInjector von @Brumbaer experimentiert und was soll ich sagen es lassen sich die Ports tatsächlich auf die Weise injecten aber nur solange man dem generischen RadeonFramebuffer verwendet. Das ganze schaut dann so aus:

    Der Rechner bootet auf die Weise sowohl das installierte System als auch die Recovery oder den USB Stick. Irgendwie ist es ja eigentlich auch logisch das das ganze nur mit dem generischen RadeonFramebuffer funktioniert denn die Baladi Personality kennt von sich aus ja nur einen Connector Typen nämlich DP und davon gleich 6. Wenn man das property nun also überschreibt mag das zwar gehen aber der gewählte Framebuffer kennt den Connector gar nicht.

  • Sehr schön! Hast dus auch mal über eine SSDT/DSDT probiert? :)

    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.

  • Werde ich gleich nach dem Essen machen ^^

  • Na dann... Ich melde mich jetzt ab, guten Rutsch euch allen :thumbup: :feuerwerk:

    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.

  • Wie zu erwarten funktioniert es auch wenn man es aus der DSM Methode heraus macht :D

  • Mahlzeit,


    wird denn bei dir auch der Gerätename aus der SSDT übernommen, @griven? Daran scheitert es bei mir irgendwie immer, dafür passen jetzt die Ausgänge.


  • Nope das funktioniert bei dem generischen Radeon Framebuffer nicht ist aber eigentlich ja auch nur kosmetischer Natur. Ob da jetzt HD8XXX steht oder R9-290X ist mir persönlich relativ egal :D

  • Habs jetzt endlich auch mal aus Interesse ausprobiert. Bei mir funktioniert die connector Geschichte noch nicht so blendend...


    Als SSDT habe ich unter anderem folgende _DSM Properties eingebunden:


    IOReg zufolge scheint der Framebuffer aber darauf nicht zu reagieren. Die Connector-types entsprechen nicht denen aus meiner SSDT. Die SSDT wird jedoch geladen und zB hda-gfx auch korrekt gesetzt.

    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.