Dell 7350 DSDT.aml Problem

  • Hi Hackintosh Gemeinde.


    Benötige eure Hilfe für das kompilieren der DSDT.aml bei einem Dell Tablet.


    Kriege die Fehler nicht weg.

    Dateien

    • DSDT.aml

      (83 kB, 84 Mal heruntergeladen, zuletzt: )
  • bitte schön.

    compileerrors sind weg.

    Dateien

    • DSDT.aml

      (83,92 kB, 80 Mal heruntergeladen, zuletzt: )

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • Könntest du mir diese auch mal Kompilieren bitte?


    Kriege Audio nicht zum laufen.


    Dort ist eine B0D3 die muss ich ändern auf HDAU.


    Lieben Dank

  • büddeschöön.... errors futsch.


    und zum verständnis:

    Code
    1. Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
    2. {
    3. Return (GPRW)
    4. 0x09
    5. 0x04
    6. }

    alle errors bezogen sich auf integers (ganzzahlen) die nach einem return-statement auftauchen - return ... heisst aber quasi "hier ist die anweisung zuende...", so dass code, der noch innerhalb der klammern, also im anweisungsblock, aber nach einem return steht, gar nicht ausgeführt werden kann.

    wenn du die beiden zeilen 0x09 und 0x04 löschst oder auskommentierst, ist der error weg.

    den BOD3 hab ich auch gleich mal mit umbenannt zu HDAU

    Dateien

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • Lieben Dank sehr nett von dir.


    Mal schauen ob ich die Soundwiedergabe aktivieren kann.


    Es läuft wirklich alles außer Sound

  • grt Eigentlich relativ unwichtig, aber nur zu unser beider Verständnis, ich habe mir das ganze auch mal angeschaut und hätte es wie folgt gelöst:


    Das Problem tritt bei GPRW auf. GPRW ist in der SaSsdt selbst nicht definiert, sondern kommt aus der DSDT und sieht wie folgt aus:

    GPRW ist also eigentlich eine Methode, kein Integer Object. In der SaSsdt wird GPRW jedoch als External (GPRW, IntObj) definiert. Hieraus entsteht wahrscheinlich das Problem, denn der decompiler interpretiert folglich die Return (GPRW... falsch und decodiert sie somit falsch. Dadurch kommt der problematische Code zustande:

    Code
    1. Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
    2. {
    3. Return (GPRW)
    4. 0x09
    5. 0x04
    6. }


    Was ich jetzt machen würde, wäre External (GPRW, IntObj) zu External (GPRW, MethodObj) zu korrigieren. Damit hat der compiler dann erstmal kein Problem mehr mit Ganzzahlen nach dem Return, diese müssen jetzt nur noch richtig umformatiert werden. Somit korrigiere ich die GPRW Calls zu:

    Code
    1. Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
    2. {
    3. Return (GPRW (0x09, 0x04))
    4. }

    Die Methode GPRW erhält somit auch seine gewollten Werte beim Aufruf einer entsprechenden _PRW Methode.

    Jetzt habe ich gesehen, wie du das ganze gelöst hast, und frage mich, was die bessere Lösung ist :/ Was meinst du?

    Dateien

    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.

  • kuckkuck klar und eindeutig deine version. das löschen der werte nach dem return fixt zwar den error, aber ganz wohl war mir nicht dabei (ist halt die einfache lösung, die immer wieder empfohlen und angewendet wird...)

    aber die werte nach dem return kommen ja von irgendwoher, müssen also irgendwie auch einen sinn und zweck haben.

    und die gprw einfach nur per _PRW aufrufen und den returnwert weitergeben mag zwar funktionieren, ist aber auch irgendwie unlogisch (da würde ein einfacher aufruf der GPRW ja ausreichen, müsste nicht extra noch in einer anderen methode verpackt werden).

    mit deiner lösung macht das ganze wieder richtig sinn. werd ich mal in mein repertoire übernehmen. :danke:


    EDIT: hab den gedanken noch mal ein wenig durchlaufen lassen:

    das weglassen der werte nach dem return ist ja der standardumgang mit derartigen errors. evtl. fängt man sich da schon ganz am anfang der dsdt-bearbeitung probleme ein...

    folgendes... return ("irgendeine methode") ruft die methode auf, und verarbeitet ggf. ihren rückgabewert weiter. wenn die übergabeparameter fehlen (sind die dann auf "zero" gesetzt?), ist der rückgabewert wahrscheinlich verfälscht oder sinnlos, was ggf. auch im weiteren programmablauf zu fehlern und problemen, seltsamen ergebnissen führen könnte, wie z.b. nicht funktionierenden devices nach dem sleep..

    und es gibt fälle, wo der error nicht von "return (methode) integer, integer (feste werte)" produziert wird, sondern von zeilen wie "return (methode) arg0, arg1..." also flexiblen, sich ändernden übergabeparametern... - was ich noch ekliger bewerten würde..

    grmpfff.... da muss ich wohl mal einige dsdt's überarbeiten und testen, ob sich so seltsame verhaltensweisen eingeschlichen haben

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

    Einmal editiert, zuletzt von grt () aus folgendem Grund: nachtrag

  • Ich denke mal so tragisch wird's nicht sein, hat ja schon häufig funktioniert. Sinnvoll ist es aber sicherlich trotzdem das ganze möglichst original zu belassen. Die Fehler in den OEM DSDTs entstehen ja meistens durch unterschiedliche ACPI Versionen. Versucht zB eine ältere ACPI Version ein Table zu dekompilieren, dass mit einer neueren ACPI erstellt wurde, gibts Fehlinterpretationen.


    Ich denke mal bei den ArgX Problemstellen verhält sich das ganze so ähnlich wie bei den festen Werten, sprich ein (Return (GPRW)           ArgX), wird zu (Return (GPRW (ArgX))), solange das entsprechende GPRW eine Methode und kein Integer ist...


    Hier hat Thogg Niatiz mal was dazu geschrieben: DSDT Sammelthread (Hilfe und Diskussion)

    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.

  • habs eben gerade probiert:

    Return (XYZ)

      Arg0

      Arg1

    ...


    wird Return (XYZ (Arg0, Arg1, ...))

    genauso, wie du sagst,

    und oben wird aus XYZ, IntObj ein XYZ, MethodObj, und die compilerwelt ist wieder in ordnung.

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • Du solltest überprüfen, ob XYZ wirklich ein MethodObj ist und nicht vielleicht doch Int, sonst wäre das ganze wieder kontraproduktiv ;)

    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.

  • guck ich nach. denk ich aber schon, woher sollten sonst die verwaisten parameter herkommen...

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • Hatte das Problem bezüglich MDBG, wobei MDBG weder als Integer, noch als Methode im ganzen ACPI überhaupt existiert... Da müsste man dann schauen wo MDBG überhaupt herkommt. Die danebenliegenden M64B und M64L sind zumindest Integer :/

    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.

  • den MDBG hab ich auch, external MDBG, IntObj //unknown object .. und noch so einen kandidaten. schon seltsam, dass da nicht irgendwelche errors durch die gegend fliegen.

    hast du alle tabellen abgesucht?

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • Mit grep alle mal durchgesucht, konnte nichts finden... Vielleicht hab ich was vergessen.


    Ich denke man muss die ganzen Tabellen einfach nur einmal richtig dekompilieren, dann passts. Richtig heißt mit Terminal Befehl und unter Einbezug aller anderen vorhandenen ACPI Tabellen. Dann sollte auch irgendwo die Method (MDBG) erscheinen.

    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.

  • hab per terminal dekompiliert:

    iasl61 -da -dl DSDT.aml SSDT*.aml dabei werden aber nur dsdt und die ssdt's berücksichtigt... gehts besser, oder reicht das so aus? und wie fügen sich all die anderen aml's aus dem origin-ordner eigentlich ein?

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • Du kannst noch ein refs.txt hinzufügen, bei dem du auf weitere Referenzen aus weiteren Tables hinweist...


    Was meinst du mit wie die sich einfügen? Welchen Job die haben?

    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.

  • beim dekompilieren der dsdt/ssdts per terminal wird deren inhalt ja insgesamt berücksichtigt.

    dann müssten die unbekannten objekte aus den anderen tabellen kommen - und anscheinend werden die beim dekompilieren nicht berücksichtigt. vermute ich mal. sowas meinte ich.

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • Du kannst ja sagen, dass nicht nur SSDT*.aml, sondern alle Tables aus einem bestimmten Ordner berücksichtigt werden...


    Aber ich bezweifle, dass aus den weiteren Tables noch wichtige Referenzen kommen, die sind größtenteils eigenständig oder noch nicht mal ACPI Tabellen im klassischen Sinne... ;)

    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.

  • reingucken werd ich auf jeden fall mal. evtl. findet sich ja ein unbekanntes objekt wieder, und man weiss, ob method- integer- oder was auch immer objekt.

    ersthilfe vor ort für altes zeugs (-> laptops) 8)

    berliner häckinTosh.stammTisch am 3.monatsmittwoch im maxFish/kunsthaus ACUD

    der stammtisch in berlin ist WIEDER DA!! nächster termin voraussichtlich: mittwoch 15.9.21, 19.00 uhr

  • Ich danke euch allen.


    Kriege kein einzigen mucks aus den Boxen.


    Es ist zwar ein HDEF Device in der DSDT.aml aber in macOS erscheint kein HDEF Gerät.


    Es ist kein HDEF in der IORegistry zu erkennen.


    Habe alles ausprobiert aber an diesem Dell 7350 beisse ich mir die Zähne aus.


    Sowohl mit AppleALC.kext auch mit VodooHDA kein Chance