Beiträge von grt

    der ecenabler ist eine alternative zu dem ssdt/dsdt patch. wenn du den einsetzt, brauchts weder die ssdt noch die renames.

    einen battery....kext braucht es in beiden fällen, entweder smcbattery... beim virtualsmc, oder den acpibattery... bei fakesmc.

    für den acpi/ssdt-weg nimmt man sich die originale dsdt, guckt im ec (bei dir hiess der hec0 - sb.pci0.lpcb.hec0 oder so) welche von den feldern>8 überhaupt verwendet werden: auskommentieren, testweise kompilieren, gucken, was für errors angezeigt werden. notieren inkl. der methoden, die wg. unbekannt gemeckert haben.

    dann überträgt man die region mit den feldern und die methoden in eine ssdt, zerlegt die felder in 8bit schnipsel, und wendet bei den aufrufen die entsprechende zusammenfügmethode (die müssen auch mit in die ssdt rein) auf die schnipsel an anstelle des originalen feldes.

    und dann noch die originalmethoden aus der dsdt umbenennen.

    aber wie schon gesagt, wenn das mit dem ecenabler klappen könnte,.würde ich den nehmen. guck dir als erstes mal die doku von dem an.


    edit... uups... ist ja schon gelöst.. guten morgen ;-)

    guter vorsatz für heute: in zukunft erst genau und bis zum ende lesen, dann antworten...

    müssen für Batterie irgendwelche 16bit Felder in 8bit umgepatcht werden

    im EC-device - oder wie auch immer das dingens heisst. im matebook wars glaub ich HEC0 oder so. man muss die felder aus dem EC, die grösser als 8bit sind, und die in der dsdt gelesen/geschrieben werden, in 8bit-schnipsel zerlegen, und dann dort wo sie aufgerufen werden (das wären die änderungen in den methoden, und die daraus resultierenden renames) mittels B1B2-methode (oder B1B4, oder L1L2, oder der WECB/RECB) wieder zusammenfügen, so dass der wert im register wieder stimmt.

    aber wenns mit dem ECEnabler geht, dann wär der auf alle fälle die komfortablere lösung, und zu 100% vorzuziehen.

    eine quelle gab es mal bei den tomaten von rehabman, wo das prinzip des batterypatch für dsdt erklärt wurde.

    und die renames kommen daher, dass man inzwischen die finger von der dsdt lässt, und möglichst alles per ssdt erledigt an notwendigen patches. wenn man nun eine methode aus der dsdt irgendwie verändert in einer ssdt dem system serviert, dann wäre sie ja 2x vorhanden: die originale version in der dsdt, und die neue in der ssdt. destawegen wird dann die in der dsdt umbenannt, und alle anfragen und aufrufe landen bei der neuen methode gleichen namens in der ssdt.

    also ich kenn das so, dass der SMCBatterymanager.kext immer nötig ist, allerdings muss dem unter die arme gegriffen werden. das erfolgt entweder mit dem ECEnabler.kext, der kommt ohne weitere massnahmen klar, oder, wenn der eben nicht tut, dann muss ein acpi-patch zzgl. ein paar renames her. früher landete der in der dsdt, jetzt kann man den auch per ssdt erstellen.

    die thinkpads aus der generation haben noch eine whitelist, dass die ausser kraft gesetzt wurde, ist voraussetzung nr. 1 für den wlankartentausch.

    und soweit ich weiss, haben die thinkpads **30 auch noch den alten minipcie-anschluss für wlan&co, die neueren elitebooks hier im thread haben schon den ngff-anschluss. wird also nix..

    hattest du bei der SSDT-PLUG irgendwiewas angepasst? auch wenn in der neuen efi eine drin sein sollte, nimm lieber deine.

    ist die andere cpu auch eine aus der 10.gen? dann sollte das eigentlich nicht so viel ausmachen. und wenn du vom usbstick testest, bzw. deine aktuelle efi auf einem stick vorhältst, den du getestet hast, ob er brav bootet, dann kann dir doch nix weiter schlimmes passieren.

    Batterieanzeige geht ohne den Enabler.

    aber mit der SSDT-BAT, soweit ich das sehen konnte? im HWEC-device ist einiges an feldern >8bit, um die sich gekümmert werden müsste. allerdings kommt mir die anwendung der B1B2-methode in der ssdt schon sehr seltsam vor. ich hab das eigentlich anders in erinnerung, und die errors beim start, sowie die verzögerung sprechen meiner meinung nach auch dafür.

    wär mein vorschlag: alle renames mit "bat" im kommentar mal deaktivieren, ebenso die SSDT-BAT.aml, und statt dessen den EC-enabler.kext nutzen. du könntest auch im vorfeld mal gucken, wie sich der läptop verhält, wenn sowohl die patches, die ssdt und der smcbatterymanager.kext deaktiviert sind. dann gibts zwar keine akkuanzeige, aber evtl. einen normal schnellen start, was dann dafür spräche, dass mit der ssdt und/oder den patches was im argen liegt.

    zu einem korrekten batterypatch per ssdt gehören normalerweise auch etliche renames in der acpi/patch.. abteilung. guck da mal nach und deaktivier die auch. wenn die akkuanzeige ohne ssdt-bat und auch ohne ecenabler tut (hab ich doch richtig verstanden, dass dem so ist?) brauchts den ganzen kram nicht, und die renames wären eher kontraproduktiv.

    jein. den 7280 gibts sowohl mit 6. und 7. gen cpu, also obacht. ansonsten ja, die hardware ist sehr ähnlich, aber meist klappt das mit dem "einfachmalsoumstecken" dann doch nicht. hatte ich gerade mit genau der kombination, eine efi vom alten 5470 für den 7280 zu verwenden. ich kann mal gucken, wo letztendlich die unterschiede lagen, allerdings hab ich der einfachheit halber clover verwendet wg. der möglichkeit, beim start einzelne komponenten der efi an/abschalten zu können.

    würde sagen, dass sich das nach einem plan anhört.. und dells sind eigentlich weitgehend handzahm, ggf. stressen sie ein wenig unter linux/debian mit firmware, aber das wär weit entfernt von den bockigkeiten, die du beschreibst. da spricht alles für einen defekt irgendwo im inneren des läptops. dass erst gestartet wird, wenn man den akku abzieht etc.. wie du beschreibst, das hört sich schon sehr kränklich an. dass gnubbel und trackpad eine extraeinladung wollen ist dagegen normal, das ist selbst bei einer debianinstallation der fall.

    ich hab übrigens sowohl im neuen 7390 und auch in den beiden dienstläppchen 7280 (hardware identisch mit 5470) ersatzakkus von fremdherstellern drin, die keine probleme machen und gute laufzeiten sowie realistische angaben zu ladezustand/restlaufzeit unter linux/debian liefern. muss also nicht wirklich ein originalakku von dell sein.

    tut mir echt leid, ich hätte auch gerne geholfen, aber da das dellchen meist in der schublade herumlag, und nix zu tun hatte, bot es sich an, es als ersatz für einen im umfeld kaputtgegangenen läptop weiterzugeben.

    mein dellchen hab ich gerade vor 3 wochen weitergegeben, und auch das 5490 ist nicht mehr da. ich bin inzwischen auf ein 7390 umgestiegen. meine signatur sollte ich wohl mal aktualisieren...

    entscheidend ist, dass du den mbr mit den bootdateien mit auf eine cd/dvd bekommst.

    ich würde versuchen mit dd if=/dev/kompletter-usbstick of=/usbstick.img (oder iso oder so) ein image vom kompletten stick zu ziehen, und das dann auf eine cd/dvd brennen.

    oder mal nach ibootlegacy gucken, das war ein image von einer bootcd für häckis. gibt unterschiedliche versionen solcher cds, die alle auch einen externen installer z.b. auf einem usbstick starten können.

    andere möglichkeit wär eine festplatte (wenn man denn eine 2. einbauen kann) mit bootloader, installer könnte mit drauf, ginge aber auch vom stick. oder gleich extern installieren und dann die fertige platte einsetzen.

    1. guck dir mal die pfade in den einträgen an. daran kann man sehen, dass sich ein kext in einem anderen drin versteckt. den inhalt eines kexts kann man sich auch mit rechtsklikk -> paketinhalt anzeigen ankieken.

    2. hast du alle möglichen nicht aktivierten kexteinträge in der config gehabt, als ich gestern reingeguckt hab. die "false"-kexteinträge schmeiss raus. die verwirren nur.

    3. guckt doch erstmal, dass der rechner korrekt mit allen innereien macht, was er soll. danach dann gucken, ob und wie man den dualboot in gang kriegt. F12 wär im notfall ja immer noch die funktionierende, aber nicht so elegante version in der hinterhand.