Thinkpad E130 OC Install & vieles mehr

Macos am usb Stick? XhciPortLimit true? UsbInjectAll wird auch ab und zu benötigt.

Versuch doch mal mit USB Inject All zu starten

Mach mal Xhci Port Limit aus

Statt der BAT0 BAT1 SSDTs könntest du auch den ECEnabler Kext ausprobieren.

- Was soll denn der FaceTime Kext bringen?

- Sind NullCPUPowerManagement, SleepEnabler Kexte nötig?

der parse execution fehler kommt vom versuch des rechners mit hilfe des smcbatterymanager die akkuwerte auszulesen. wenn ein läptop einen batterypatch zusätzlich zur kext braucht, und die entsprechende ssdt entweder nicht vorhanden, oder fehlerhaft oder nicht zum gerät passend ist, und/oder die zur ssdt noch nötigen renames unter acpi -> patch fehlen, oder nicht greifen, dann kommt beim boot dieser fehler. meist

klappt der boot dann doch, aber extrem verzögert.

die lösung ist simpel: smcbatterymanager.kext erstmal deaktivieren, und später mit der originalen dsdt gucken, was für ein batterypatch benötigt wird, bzw. einen vorhandenen auf fehler prüfen.

also.. die efi ist freundlich gesagt - nicht gerade optimal:

acpi

- woher kommt die dsdt, was wurde da bearbeitet? eingebunden ist sie nicht - nur geparkt zum reingucken? sollte möglichst nicht eingebunden werden, sondern die anpassungen, die nötig sind, sollten per ssdt erledigt werden.

- ssdt-bat0 könnte sinnvoll sein, wenn sie sich tatsächlich auf genau das gerät bezieht. allerdings passen die patches nicht dazu, und auch die pfade in der dsdt widersprechen den pfaden in dieser ssdt, ein device bat0 findet sich in der dsdt gar nicht? gelöscht?

- ssdt-bat1-disable? zumindest seltsam.

- ssdt-ec wird (wenn denn die dsdt halbwegs original ist) nicht benötigt, begründung findet sich im entsprechenden kapitel des dortania-guides

- ssdt-imei ist hauptsächlich bei ivy/sandy-mix angesagt, in der dsdt gibts zumindest kein imei/heci/mei device, daher ok (wenn die dsdt original ist, und vom E130 stammt)

- pnlf und xosi sind ok, wobei ich die xosi an erste stelle setzen würde.

acpi-patches:

- die EHC1 und 2 sind inzwischen unnötig, können weggelassen werden.

- die 3 Q?? sind wahrscheinlich für helligkeitstastenmapping gedacht, im zusammenhang mit einer ssdt. in den ssdts finde ich nix diesbezüglich.

- _dsm to xdsm ist auch eher unnötig, tut aber auch nicht weh.

- den bat0 to batc kenn ich von thinkpads mit 2 akkus, die per ssdt zu einem zusammengefasst und ausgelesen werden. erstens hat das E130 nur einen akku, und bei geräten die tatsächlich 2 akkus haben brauchts dann auch noch eine ssdt mit dem batc-device. hier aber nicht notwendig.

- bat1 to batc dito.

- azal und hdas to hdef sind erstens nicht mehr notwendig, und wenn hdef schon hdef heisst, unsinn.

- lpc to lpcb macht irgendwie gar keinen sinn, wenn lpcb schon lpcb heisst (in der dsdt heisst der lpcb. wurde dort auch noch mal von hand umbenannt?, oder ist das original so?). in der ssdt-bat0 wird der batterypatch auf ein device lpc.ec angewendet. entweder ist der rename unsinn, weil damit der batterypatch ausser gefecht gesetzt wird, oder die pfade in der ssdt-bat0 (bzw. die ganze ssdt) kommen von einem ganz anderen gerät, bei dem der pfad tatsächlich lpc.ec heisst

- sat0 to sata ist unnötig.

kexte

- lilu.kext gehört in der liste an die erste stelle, direkt danach sollte idealerweise virtualsmc gefolgt von seinen satelliten kommen.

- den smcbatterymanager.kext sollte man erst einbinden, wenn es einen sinnvollen batterypatch gibt (ssdt zzgl. passenden renames in patch)

- nullcpupowermanagement.kext ist eine "notfallkrücke" die selten benötigt wird, wenn es mit einer exotischen cpu probleme geben sollte -> panik beim boot. hier wär ein vorübergehendes disablen der ssdt-cpupm und der ssdt-cpu0ist während der installation sinnvoller, und später kann man sich eine ssdt-pm erstellen (s. dortania-guide)

- sleepenabler.kext würde ich weglassen, gehört in den bereich finetuning, wenn er überhaupt gebraucht wird. wär eine potentielle fehlerquelle weniger.

- facetime.kext sagt mir gar nix.

- usbinjectall.kext ist sinnvoll wenn anfangs probleme mit usb auftreten, daher aktiv lassen. portlimitpatch bei läptops ist aber seltenst nötig, weil läptops normalerweise noch nicht mal annähernd an die 15-port-grenze stossen.

smbios

hier kommt das macbook 10.1 zum einsatz, was sehr weit von der hardware des E130 entfernt ist: E130 ist ein ivybridge-gerät, das macbook 10.1 ein kabylake. 4 generationen unterschied. ideal ist das auf keinen fall.

da ivybridge-macbooks von bigsur offiziell nicht mehr unterstützt werden, kann man zwar kein "richtig" passendes smbios auswählen, aber etwas näher dran ginge schon: macbookpro 11.1, macbookair 6.1 oder macbook 8.1 (nicht pro!) wären passender (die beiden ersten sind aus der 4. generation, das letzte aus der 5.), wobei ich zum macbookpro 11.1 tendieren würde.

dann versuch doch erstmal mit einer minimalen konfiguration durch die installation zu kommen.

was ich oben noch nicht erwähnt hab, ist, dass diese älteren geräte für funktionierendes audio einen irq-fix brauchen, auch per ssdt zu erledigen, ohne den audio in dieser generation gar nix macht.

will heissen, all die fraglichen punkte kannst du fürs erste weglassen, und dich später kümmern.

also:

- ssdt-xosi kann bleiben, die brauchts u.a. für einen evtl. geplanten dualboot, irgendwelche konflikte sind von der nicht zu erwarten. der _osi to xosi rename bleibt auch drin, beides in der jeweiligen liste an erste stelle.

- ssdt-pnlf ist für die helligkeitsregelung zuständig, wenn denn die pfade (..PCI0.GFX0) richtig sind, passt das schon, wenns nicht passt, ginge nur die helligkeitsregelung nicht, ärger ist sonst von der auch nicht zu erwarten.

weitere ssdts und renames/patches lass fürs erste weg

dann noch die beiden "bösewicht-ssdts" deaktivieren

wenn du windows noch drauf hast, zieh mal die originalen acpi-tabellen, dann kann man sinnvoll gucken, was wirklich nötig ist, was nicht, und muss nicht spekulieren.

bei den kexten speck auch mal ab, insbesondere nullcpu... und der smcbatterymanager erstmal, bzw. gar nicht. smc-satelliten können auch vorerst draussenbleiben.

usbinjectall scheint nötig zu sein, netzwerk auch, voodoops2 ist ziemlich neu, evtl. brauchts bei dem eine ältere version. wenn die eingabe erstmal nicht tut, entweder direkt tauschen, oder mit usbeingabe weitermachen.

applealc kann bleiben, wird aber noch nix bewirken, whatevergreen sollte drin sein.

sinetek ist für den cardreader, kann sein, dass der greift, kann auch nicht sein. aus meiner sicht finetuning für hinterher.

eine vernünftige reihenfolge ist lilu als allererstes, dann virtualsmc (die satelliten später direkt hinterher) dann whatevergreen und applealc. danach netzwerk und eingabe

wenn die installation gelaufen ist, danach das finetuningzeugs

die originale dsdt muss nicht eingebunden werden, die ist ja in dem zustand sowieso vorhanden. notwendige änderungen machen wir per ssdt, das ist dann eine ergänzung zur originalen dsdt. wenn teile der originalen dsdt abgeändert werden müssen, schalten wir die per patch - rename - ab, so dass sie nicht mehr genutzt werden können, und hängen die abgeänderte version per ssdt sozusagen dran.

aber du könntest die dsdt mal hochladen.

was ist denn nach dem bild passiert? einfach ein neustart oder ein hänger?

da geht der kontakt zum stick verloren. was ist das für ein stick usb2/3, wie gross? wieviele usbs hat das geräterchen? probier mal einen anderen anschluss.

ansonsten ist die efi sauber, hab nix zu meckern - und die dsdt inspizier ich gleich mal

apropos bios... die einstellungen sind ok?

das portlimit greift bei 3 externen anschlüssen und 2 internen definitiv nicht. selbst wenn alle 3 externe doppelt zählen, weil usb3 sinds mit den internen 8. da ist mächtig luft nach oben.

aber aktivier usb3 mal im bios.

kaffee von stuttgart nach berlin? der ist kalt, wenn er hier ankommt

im dashboard vom forum gibts einen spendenbutton, mit dem du das forum unterstützen kannst, wenn du magst:

und ich bin gespannt, was schon geht, wenn die installation durch ist.