Beiträge von grt

Zitat von griven

das T61 die IRQ Fixes braucht

brauchts, bzw. hatte ich zumindest immer mit an bord.

du musst die partition erstmal mounten. aber das müsstest du doch schon gemacht haben, als du macos installiert hast?

mounten ginge per terminal (befehl hab ich nicht en detail im kopf), mit dem kextupdater, anymacos, espmounter pro, hackintool... sowie ocat und cloverconfigurator.

wenn die macplatte während der windowsinstallation angestöpselt war, dann kann es sehr wohl sein, dass windows dort seine bootdateien abgelegt hat. die efipartition des macplatte ist fat32 formatiert, und hat das boot/esp flag.. guck da mal rein, ob dort jetzt ein ordner "microsoft" liegt

dann könnte man die WRAM in ruhe lassen, und müsste dafür den "zuspieler" der die infos/werte beinhaltet, in die ssdt stecken und original umbenennen. seh ich das richtig?

dann nimm doch die wram-methode, kopier sie in eine ssdt, bearbeite die werte, und benenne die originalmethode in der dsdt per rename-patch um. sollte so eigentlich klappen.

ja. 10.14.x oder 10.15x oder so. ist richtig, und daraus kann man auch die "namen" der versionen ermitteln. z.b. mit einer suchmaschine deiner wahl...

nimm anymacos.app. damit kannst du auch ältere versionen von den appleservern laden und danach davon einen installationsstick erstellen.

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...

Zitat von MacPeet

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.

Zitat von canyonwalker

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...

warum nimmt er nicht saschas anymacos? und sicher, dass das ein late 2012 ist und leopard? irgendwie passt das nicht zusammen..