Cube i7 Book Tablet Skylake Core M3-6y30

  • Bin mir halt nicht sicher inwiefern dir meine DSL Dateien nützen. Aber ich kann dir ja mal sagen wie genau ich das mit dem decompilen gemacht habe. Weil mir war das am Anfang anhand der Guides auch nicht so 100%ig klar und ich hatte superviele Fehler bzw. das command line tool ist sogar abgeschmiert mit nem "segmentation fault". :(


    Erfolgreich war ich dann so:


    Alle gesammelten .aml files in einen Ordner.
    Von denen hab ich jetzt nur die DSDT.aml und die ssdt-irgendwas.aml genommen.
    Alle ssdts mit "x" davor sind dynamisch geladene - die hab ich weggehauen.
    Dann halt ne Text-Datei ref.txt mit dem Inhalt:

    Code
    1. External(MDBG, MethodObj, 1)External(_GPE.MMTB, MethodObj, 0)
    2. External(_SB_.PCI0.LPCB.H_EC.ECWT, MethodObj, 2)
    3. External(_SB_.PCI0.LPCB.H_EC.ECRD, MethodObj, 1)
    4. External(_SB_.PCI0.PEG0.PEGP.SGPO, MethodObj, 2)
    5. External(_SB.PCI0.GFX0.DD02._BCM, MethodObj, 1)
    6. External(_SB.PCI0.SAT0.SDSM, MethodObj, 4)
    7. External(_SB.PCI0.SAT1.SDSM, MethodObj, 4)External(_GPE.VHOV, MethodObj, 3)


    Und zu guter Letzt dann:

    Code
    1. iasl -da -dl -fe refs.txt *.aml

    .


    Hatte mit den entstandenen .dsl files dann keine Probleme gehabt.


    Achja und aufpassen, dass das iasl in /usr/bin dieselbe Version wie die in MacIASL integrierte ist.


    Aber wenn du das schon so gemacht hast bzw. das so bei dir nicht klappt, dann sag bescheid und ich lad meine .dsl files hoch =)

  • Danke, ich versuche es selbst - dann lerne ich noch was dabei ;)
    Ich hatte die x-Dateien mit dabei. Hast du irgendwelche aussortiert? Da wurde ja gesagt, dass doppelte nicht dabei sein sollen - das erkenne man daran, dass die Dateigröße übereinstimmt. Auch noch eine mögliche Fehlerquelle.



  • Ich hab die x-Dateien rausgenommen, weil man ja quasi nicht sicher sein kann, ob die immer geladen sind. So stands zumindest auch im Guide :) Aber war glaube ich auch kein großer Unterschied (hab beides mal gemacht). Und ja das mit den Dateigrößen hatte ich erst im Finder gecheckt und da die von vorn herein nicht mal "grob" dieselbe Größe hatten, hab ichs nicht weiter verfolgt.


    Irgendwie ist bei meinen config.plists ein Riesenkuddelmuddel entstanden, da Clover Configurator teilweise nur speichert was er will und nicht alles und auch nicht alle Daten ausliest und und und. Werd mir jetzt mal ne frische Config als Ausgangspunkt anlegen und mal schauen ob ich meinem komischen "Blackscreen" auf die Schliche komme :)

  • Also Glover Configurator speichert eigentlich richtig - er zeigt nur nicht alles an. Wenn nicht fängst du nochmal mit meiner alten an, die funktionierte glaube ich korrekt.
    Versuche jetzt die DSDTs und SSDTs.
    Ich glaube bei mir waren welche gleich groß, können aber auch die x gewesen sein.


    Update: Bei der 4 und der 5 zeigt er bei mir jeweils 2 KB an. kriege es nicht genauer....


    Update:
    Habe es mit dem Diassemblieren nochmal versucht. Bei SSDT-3 bricht er ab:




    Found 19 external control methods, reparsing with new information


    Pass 1 parse of [SSDT]


    Pass 2 parse of [SSDT]


    ACPI Error: Null object, but type not ACPI_TYPE_ANY (20161117/nsobject-176)



    In der Datei steht nur:
    Could not parse ACPI tables, AE_BAD_PARAMETER


    Es scheint also nicht identisch zu sein.



    2 Mal editiert, zuletzt von orbislacteus ()

  • Welche sind denn bei dir die X-SSDTs? Die aus Clover extrahierten .aml files gehen von SSDT-0 bis SSDT-15x bei mir, wobei 0-8 ohne x sind und dann eben 9x--15x.
    Hab jetzt grad nochmal die Zeile

    Code
    1. External(_SB.PCI0.SAT0.SDSM, MethodObj, 4)

    rausgenommen aus der refs.txt und jetzt nochmal doch ALLE SSDTs auch die mit x reinkopiert in den Ordner. Da ich zu beschäftigt war mit DSDT ist mir gar nicht aufgefallen, dass ich bisher gar nicht alle SSDTs decompiled bekommen habe. Jetzt wo ich das aber nochmal so wie beschrieben gemacht habe, hab ich tatsächlich SSDT-0 bis SSDT-15x.dsl.


    EDIT: Und ja keine Ahnung, bei mir hat Clover Configurator total oft zb SMBIOS Änderungen übernommen, aber gleichzeitig gemachte Änderungen an BOOT oder GUI zb nicht. Die musste ich dann von Hand eintragen. Ich nehm ab jetzt http://cloudclovereditor.altervista.org/cce/editor.php zum editieren, für Treiberinstallation ist ja CCV ja ganz nützlich =)


    EDIT2: AAAAAH! Ich hatte ausversehen DSDT.aml nicht mit im Ordner, deswegen hatte das mit dem decompilen von allen SSDTs funktioniert. Jetzt wo der wieder drin ist, bricht es bei mir auch mit demselben Fehler wieder ab :/

    Einmal editiert, zuletzt von strega ()

  • Okay, vielleicht sollten wir dieses Problem erstmal lösen und sicherstellen , dass wir sauber übersetzte DSLs haben.



  • Wäre schon schön, aber ich hab weiß nicht mal an welcher Stelle er sich aufhängt und dieses "Null object" findet.


    EDIT: Ok ich habs hinbekommen mit einem Trick:
    Wir wussten ja, dass alle SSDTs untereinander ohne Fehler decompilen. (also ohne DSDT)
    Also hab ich einzeln immer versucht eine SSDT nach der anderen in den Ordner reinzuschieben und dann immer wieder alle *.aml decompiled. Tatsächlich liegt der Fehler in SSDT-3.aml, die durch fehlende Referenzen (und dadurch falsche Argumentanzahl bei Methoden, etc.) so schwerwiegend falsch decompiled, dass iasl abbrechen muss.
    Also hab ich Folgendes gemacht:
    1. Alle SSDTs untereinander decompiled.
    2. Die entstandene SSDT-3.dsl hab ich versucht zu compilen. => VIELE FEHLER
    3. Dann hab ich die ref.txt um die Parameter erweitert, die er nicht kannte und die dadurch Fehler verursachen. Witziger Weise waren die fast alle in DDST definiert, deshalb konnte ich guten Gewissens die Parameteranzahl übernehmen. Dann wieder alle decompiled um eine neue SSDT-3.dsl zu erhalten, welche mehr Referenzen enthält.
    4. Wieder versucht SSDT-3.dsl zu compilen => KEINE FEHLER MEHR.
    5. Die "gefixte" SSDT-3.aml nun wieder zu den anderen Ausgangs .aml files gepackt und die DSDT, welche ja bisher außen vor war, mit in den Ordner.
    6. Alle *.aml decompiled => Durchgelaufen!


    Und ja letztendlich musste ich SSDT-3 jetzt "opfern", damit die anderen wenigstens halbwegs richtig sind, aber letztendlich fehlen immer irgendwelche Verweise, sodass das idiotisch ist zu versuchen ALLE SSDTs zu fixen. Wenn wir SSDT-3 später brauchen sollten, kann die zur Not auch von Hand gefixt werden (die meisten Verweise kommen ja aus der DSDT). Wenn wir die aber eh nicht patchen müssen, dann ist es auch völlig egal, dass wir sie nicht so korrekt wie die anderen decompiled haben.


    EDIT2: Achso ich hab mal die ref.txt angehangen, mit der sich SSDT-3 decompilen und dann wieder compilen lässt :D

    Dateien

    • refs2.txt

      (404 Byte, 68 Mal heruntergeladen, zuletzt: )

    3 Mal editiert, zuletzt von strega ()

  • Ok, ich sehe du hast schon richtig Ahnung davon. Ich denke das ist ein gangbarer Weg. Ich mache heute Abend weiter. Eventuell könnte man ja auch mal durch die SSDT 3 durchschauen, ob diese irgendwelche relevanten Infos enthält, an die wir ran müssen.



  • Ja leider gehts ja nicht wirklich anders :/ Und Ahnung hab ich davon eigentlich auch nicht, aber das hat mich ja noch nie davon abgehalten was zu machen ;D


    Achso beim letzten compilen solltest du nicht die refs2.txt, sondern die refs.txt benutzen, sonst kommt dieser "ALREADY DEFINED" Quatsch oder so.


    EDIT: Hab nochmal ne bessere refs.txt rangehangen (mit Daten aus der SSDT-3, denn anscheinend crossreferencen sich DSDT und SSDT-3), mit der bis auf eine Sache ALLES gefunden wird in der DSDT. Und die eine Sache die noch "unresolved" ist, ist egal, weil die nicht in der DSDT verwendet wird. Jetzt hab ich auf jeden Fall ein besseres Gefühl mit dieser DSDT "loszuziehen" haha.


    EDIT2: Ok, anscheinend stimmt irgendwas nicht mit der Brightness Control. Wenn ich ohne sonstige Modifikationen die IntellBacklight.kext installiere und dann in Clover "ADD PNLF" aktiviere, dann funktioniert die Helligkeitskontrolle beim ersten Boot. Da ist nen Slider und der auch funktioniert. Wenn ich dann aber, nachdem ich die Helligkeit geändert habe, neustarte, kriege ich zunächst nach dem Apple Logo und Ladebalken in dem Moment, wo er sonst dann auf den Loginbildschirm wechselt (und für 1s so ein kleiner Grafikfehler gezeigt wird) nen schwarzen Bildschirm. Es sieht so aus als würde die Helligkeit auf 0 gesetzt. Dann dauert das ca. 15s und ich seh den Loginbildschirm. Wenn ich dann versuche einzuloggen oder auch nen Moment warte, hängt sich irgendwas auf. Ich kann die Maus noch bewegen, aber der blöde drehende bunte Ball ist halt am Cursor und er logt sich nicht ein.


    Komischer Weise habe ich dieses "beim ersten Mal funktionierts" auch dann nochmal bekommen als ich statt auf Akku versucht habe mit Netzteil dran zu booten. Dann konnte ich wieder einmal die Helligkeit ändern und nach dem Neustart dann auch schwarzer Bildschirm etc.


    Und scheinbar macht es keinen Unterschied, ob ich meine "SSDT-PNLF.aml" nehme oder in Clover einfach nur "ADD PNLF" aktiviere - beides funktioniert genau 1 Mal...


    Kannst du mal ausprobieren, ob das bei dir auch so ist? Also IntelBacklight.kext + "ADD PNLF" in Clover, dann Helligkeit einstellen und nochmal neustarten?

    Dateien

    • refsDSDT.txt

      (347 Byte, 38 Mal heruntergeladen, zuletzt: )

    2 Mal editiert, zuletzt von strega ()

  • So, jetzt bin ich da. Ich probiere es aus. Dauert ein bisschen.


    OK, habe jetzt deine refsDSDT genommen - bricht er wieder bei 3 ab. Die ist auch kürzer als die erste....
    Oder soll ich irgendwie beide reis Dateien nehmen?



    2 Mal editiert, zuletzt von orbislacteus ()

  • Ne, um quasi die SSDT-3 zu bauen nimmst du die refs2.txt. Die letzte da ist nur dafür, dass wenn du die gefixte SSDT-3 hast, die resultierende DSDT besonders schick wird.

  • Mhmm, das heißt ich mache mit der SSDT nen einzelduruchlauf? und den Rest mit der anderen?


    Sorry, dass ich dumm frage, aber ich mache das zum ersten Mal.



  • Hehe ne alles gut =) Aaaaalso:


    1.Du nimmst ganz normal erstmal alle SSDTs in einen Ordner. DSDT lässt du draussen.
    2.Decompilest alle mit der refs2.txt.
    3. Du öffnest die SSDT-3.dsl und versuchst die zu compilen und speicherst die als "SSDT-3_new.aml" oder so . (Sollte ohne Fehler gehen)
    4. Dann nimmst du die SSDT-3_new.aml und die anderen SSDTs + DSDT.aml und decompilest die mit der refsDSDT.txt (Natürlich nicht die orginale SSDT-3.aml mit in den Ordner)


    EDIT: Audio geht jetzt bei mir dank AppleALC mit Audio Inject "3" und HDAS zu HDEF Patch in Clover: https://www.reddit.com/r/hacki…with_clover_applealckext/

  • OK, erster Durchlauf hat schonmal geklappt!, wenn ich es in MaciASL öffne kommen aber 20 Fehler. soweit ich das sehe alle mit Syntaxterror PARSOP_ZERO
    Ich habe MacIASL 1.4 mit demselben IASL, das ich auch installiert habe - also hatte ich wie beschrieben rübenkopiert - hoffe ich zumindest



  • Folks,
    ich empfehle immer den Einsatz von MaciASL 1.31 mit der speziellen IASL-Datei von Rehabman:
    MaciASL

    Gruß
    Al6042

    Keine Unterstützung per PN oder Pinnwand... Eure Anfragen gehören ins Forum, nicht in mein Postfach!

  • Das passiert eigentlich immer, wenn er bei ner Methode nicht weiß wieviele Argumente die hat und dann das Argument "Zero" auf die nächste Zeile verfrachtet, weil er denkt, dass es ein eigener Befehl ist. Musst mal schauen welche Methode da in der Nähe ist und direkt die Datei korrigieren oder den entsprechenden Verweis in refs2.txt ergänzen.


    Hast du auch die SSDTs mit "x" reingenommen?


    Alternativ kannst du mir auch mal alle deine .aml rüberschicken und ich schau mal =)

  • Nein, ich habe es ohne die x gemacht. sollten die mit rein? Ich blicke nicht mehr durch, be welcher Variante wir jetzt sind. Muss auch nochmal überprüfen, ob ich die korrekte Refs habe.


    Hier sind meine AMLs

    Dateien

    • DSDT_SSDT.zip

      (59,82 kB, 55 Mal heruntergeladen, zuletzt: )



  • Ja, ich hab die mit rein gemacht bei mir mit "x" :D Ja ich seh da auch nur noch durch, weil ich mir den Kram ja jetzt ausgedacht habe haha. Schick mir mal komplett alle deine .aml files, auch die mit "x". :D


    EDIT: Komisch, wenn ich mit der refs2.txt deine SSDT-0 bis SSDT-8 compile, dann ist die SSDT-3.dsl danach bei mir fehlerlos :O
    EDIT2: Meine iasl Version:

    Code
    1. Intel ACPI Component Architecture
    2. ASL+ Optimizing Compiler version 20161210-64(RM)
    3. Copyright (c) 2000 - 2016 Intel Corporation


    EDIT3: Hab mal deine SSDT-3 gefixt und hier rangehangen, dann sollte es klappen alles zusammen zu decompilen.

    Dateien

    Einmal editiert, zuletzt von strega ()

  • Ok, meine ist etwas älter ...
    Ich probiere es nochmal, vielleicht habe ich die falsche reis.txt genommen



    Intel ACPI Component Architecture


    ASL+ Optimizing Compiler version 20161117-64(RM)


    Copyright (c) 2000 - 2016 Intel Corporation


    Supports ACPI Specification Revision 6.1



    Update: Ok, habe jetzt auch null Errors - vermutlich war es doch die falsche Refs Datei.


    Update: Funktioniert nicht. Die SSDT-3new mit eingeschmissen und nochmal alles durchgejagt - kommt wieder der alte Fehler. Ich glaube diesmal habe ich alle richtig gemacht. ich kann es aber nochmal mit den x en versuchen ...



    2 Mal editiert, zuletzt von orbislacteus ()

  • Super! Dann kannst du endlich ausprobieren, was ich hier so fabriziert habe ;P