"Du hast ja Alles" - hmmm vielleicht, wenn ich einen Laptop habe.

  • Ziel dieses Threads ist es den Vorgang einen Laptop zu hackintoshisieren zu beschreiben.
    Jeden Tag ein paar Zeilen.
    Heute die Einleitung, wieso, weshalb, warum.
    Morgen die ersten Schritte und ab übermorgen, Problemlösungen.
    Das Ziel ist keine Installationsanleitung zu liefern, eher zu unterhalten und dabei ein paar Herangehensweisen zu beschreiben.
    Die ersten beiden Folgen werden wenig technisch sein, das wird sich später etwas ändern.


    Wieso. weshalb,warum ?
    "Du hast aber auch alles" pflegt Carola zu sagen, meist anklagend, meist im Zusammenhang mit Computern.
    Allerdings stimmt das nicht, na ja nicht so richtig.
    Ich habe zum Beispiel keinen Hackintosh-Laptop.


    Mein ständiger Begleiter ist ein iPadPro, es begleitet mich fast überall hin. Es kann so ziemlich alles, was ich unterwegs von einem Rechner erwarte, aber hin und wieder wäre es gut Mac Software unterwegs verwenden zu können, z.B. beim Hackintosh Stammtisch.
    Aber Laptop und iPadPro mit sich rumzuschleppen ist etwas übertrieben, wie Hosenträger und Gürtel und wie das endet kann man in "Spiel mir das Lied vom Tod" sehen. Ich habe immer mal nach einem Surface Pro geschielt, aber die waren mir unter Berücksichtigung des Risikos, dass die Hackintoshisierung nur teilweise klappt, zu teuer.


    Ich habe immer gesagt, "wenn noch einmal einen Laptop, dann wieder einen 17 Zöller, denn Bildschirmplatz ist durch nichts zu ersetzen".
    @DSM2 berichtete über einen Dell - 17 Zoll. Und dann noch Touch, das passt ja wie -, wie - , das passt ja gar nicht.
    Das iPadPro ist hart an der Größen-Grenze, um es immer mit mir herumzuschleppen. Als iPadPro Ersatz, kommt ein 17 Zöller somit nicht in Frage.
    Also was gebe ich auf mein dummes Geschwätz von vorhin und suche nach einer 15" Variante. Es gibt sie tatsächlich, aber egal welchen Test man liest, immer sticht der zu dunkle Bildschirm negativ heraus. Und ein dunkler Schirm bei einem "ständigen Begleiter" ist wie Windows - nicht vertretbar.
    Also gut bzw. schlecht, und nach einem anderen Modell gesucht.
    Und irgendwann zwischen der Entscheidung nach einem Two in One zu suchen und dem Verwerfen des Dell hat sich der Gedanke eingeschlichen, dass 13 Zoll eigentlich genug sein sollten, denn das iPadPro hat ja in etwa diese Größe .
    Von 17" auf 13" in nicht ganz 2 Stunden; mal beim Guinessbuch nachschauen ob das Rekord verdächtig ist.


    Es heißt immer Lenovo sei die erste Wahl für Laptops, super kompatibel und ganz einfach. Google weißt mich auf das Lenovo Miix 520 hin. Ein 13 Zoll - Two In One mit nicht dunklem Display und "tadaaah" 8250u oder 8550u. Das klingt gut, aber der Preis von 1100€ ist an der Schmerzgrenze, wenn man nicht weiß in wie weit sich das Gerät hackintoshisieren lässt.


    Für das Geld bekommt man:

    • 8250u,
    • UHD620 IGPU,
    • 8GB Ram,
    • 256GB NVMe,
    • 12,2" IPS, 1920x1200,
    • BT und WiFi,
    • Touchscreen,
    • Stift,
    • Fingerabdruck-Lesegerät,
    • 2 Kameras,
    • LTE Modem.

    Bis zu BT mach ich mir keine Sorgen. Die BT und WiFi Karte kann man vermutlich tauschen, aber bei den anderen Dingen muss man sich auf Scheitern gefasst machen. Aber Touch hätte ich schon sehr gerne.


    Berlin hat nicht alles, auf jeden Fall keinen Miix 520. Also gut, Internet bemühen. Lenovo bietet das Gerät auf seiner Webseite in Platin an. Aber ich habe es im Web in Grau gesehen und finde ein Grau passt besser zu mir.
    Also gegoogelt und siehe da, es sieht so aus als wäre die Farbe Vertriebskanal abhängig. Platin im Lenovo Webshop und Grau bei den Händlern. Und siehe da, es gibt Händler, die haben so viele von den Grauen, dass sie sie verkaufen und der eine oder andere hat sogar einen auf Lager.
    Gesehen, bestellt und regelmäßig die emails gecheckt , ob es denn schon eine Versandbenachrichtigung gibt. Denn ich habe bestenfalls fast alles, Geduld z.B. habe ich keine.
    Am nächsten Tag die Erlösung, email da, aber keine Trackingnummer; da aus dem Außenlager versandt. Warum das Außenlager die Nummer nicht mitteilen kann, verstehe ich nicht. Was soll's, ich versteh so vieles nicht.
    Nächster Tag kein Paket und schon weiß man wo der Nick Brumbaer herkommt. Die Paketdienste liefern bei uns meist vor 13 Uhr. Am darauffolgenden Tag habe ich einen Termin um zwölf. Bis elf ist kein Paket da, muß gleich weg, noch kurz zum Briefkasten, die Briefpost reinholen. Mißmutig brummelnd nach draußen schlurfen, auf die Paketdienste, die nie kommen, wenn man auf sie wartet, und auf die Händler, die keine Trackingnummern verschicken können, schimpfen. Und während ich die Post aus dem Briefkasten nehme und mich über die Ungerechtigkeit der Welt auslassen will, fährt ein Paketbote vor. Na geht doch, wenn man so ruhig, geduldig und gelassen wartet wie ich, wird das belohnt. Es ist ein Paket für Carola.
    Der Paketbote kommt ungefähr 10 Minuten nachdem ich das Haus verlassen habe und hat das Paket gleich wieder mitgenommen. Der Paketdienst hinterlegt nicht zustellbare Pakete an einer Tankstelle in der Nähe. Ab 17:00 kann es abgeholt werden, nur noch zwei Stunden.



    Da isser ja.
    Ein Lenovo, kann ja nicht so schwer werden.
    Schau mer mal.

  • Bin sehr neugierig, habe es gleich mal abonniert.

    MfG, docplag



  • Ich find deine kleinen Tagebucheinträge echt schön.
    ... freue mich sehr auf eine Fortsetzung. :P

  • Den Miix aufgestellt, Tastatur und Netzteil angeschlossen und Windows gestartet. Die Installation ging flott und die Windows Update Orgie fiel dank des relativ neuen Systems weitestgehend aus. Kurz mal in den Gerätemanager geschaut, welche USB Ports belegt sind und welche PCI Geräte verwendet werden.
    Die Geräte des Intel Chipsatzes werden von 13.2 nur teilweise unterstützt, BT auch, aber WiFi nicht. Noch halbherzig nach anderen Geräten geschaut und nach einem BIOS Update gesucht, denn das geht bestimmt nur über Windows. Es gibt tatsächlich eins und - Glückes Geschick - es lässt sich installieren.
    Alles gut soweit.


    Das hat alles Methode
    Die in Foren beschriebenen Wege in den macos Himmel basieren auf einem Installerstick. Ich verwende einen geringfügig anderen Weg.
    Ich verwende einen USB Stick mit EFI Partition und einem fertig installierten macos.


    Ziel des Hackintoshierens ist ein Rechner, der wie eine Ente watschelt, wie eine Ente quakt, aber doch kein Mac ist.
    An einem Mac muss muss man am macos nichts schrauben, damit es läuft. So soll es auch bei einem Hackintosh sein.
    Deshalb sollten alle Anpassungen in der EFI erfolgen. Wenn alle Anpassungen in der EFI erfolgen, kann man das macos auf jedem System mit einer passenden EFI verwenden.
    Wenn unsere EFI mit dem macos auf dem Stick läuft haben wir unser Ziel erreicht.
    Das macos wurde an meinem Haupthackintosh auf dem Stick installiert und wird bei der Installation jedes neuen Hacks wiederverwendet.
    Neben dem System befindet sich noch ein Ordner mit fürs Hackintoshieren nützlichen Programmen und ein paar Benchmarks auf dem Stick.
    Das hat den Vorteil, dass ich nach der Installation eines Systems, alles zur Hand habe, was ich fürs Finetuning brauche.
    Und nebenbei fällt noch ein Notfall System ab, solange die EFI eines Hacks noch ein Booten zulässt.


    An Apple a day, keeps the doctor away
    Eva bringt Männer dazu Obst zu essen und EFI bringt Systeme zum booten. Da diese EFI vornehmlich als Startpunkt für neue Systeme dienen soll, kommt sie ziemlich nackt daher, wie Eva mit dem Apfel.
    Alle Patches und Häkchen, die man nicht sicher braucht werden gelöscht. Nur FakeSMC, Unsolid, IntelMausiEthernet - Mäuse wird man halt nicht los - und ein noch anzupassendes USB Kext kommen in den Kext Ordner. Von den EFI Treibern wird im Clover Installer als einzige Option eine der AptioFix Variationen gewählt. Im Moment versuche ich es immer zuerst mit AptioMemoryFix.


    Ganz nach oben
    Aber damit bekommt man nicht jedes System zum Laufen, also kommen die gebräuchlichsten Kexte und EFI Treiber in das oberste Verzeichnis der EFI Partition. Warum dorthin ? Ich brauche sie nur in Verbindung mit der EFI Partition , deshalb auf diese Partition. Und wenn die Treiber und Kexte auf dem selben Laufwerk, wie die Ziel-Ordner sind, kann ich sie hin und her kopieren ohne jedesmal etwas löschen zu müssen. Spart ein paar Clicks.


    Sobald der Stick bootet und man den Finder zu sehen bekommt, wird eine Kopie des EFI Ordners angelegt und ein Auszug der IORegistry gespeichert, die interne Festplatte formatiert und schließlich macos auf der internen installiert. Und dann geht es ans Finetuning.

    Egal ob man einen Installer oder ein macos zum Laufen bekommen will, es hilft wenn man einen schnellen USB-Stick einsetzt. Ich verwende einen 64 GB SanDisk Extreme, der ist für einen Stick recht schnell.


    Da stehen Eva und EFI und locken mit ihren Äpfeln. Auweia, das sollte ich anders formulieren.


    Obstsalat
    Wie bekommt man nun den Apple-Miix zustande ? Indem man EFI ihrer Nacktheit beraubt.
    Die CPU ist trotz der 8 vorne eine aus der Familie derer von Kaby Lake. Es sollten keine weiteren Anpassungen notwendig sein.
    Die PCIId des USB Chipsatzes ist 0x9d2f8086. Die kennt 10.13.2 nicht, also im USB Kext, den Treiber für das Vorgängermodell geladen. Der Blick in den Gerätemanager unter Windows hatte gezeigt, dass die USB Buchse HS01 und SS01 verwendet und es noch 14 weitere USB Kanäle gibt (insgesamt 10 HS und 6 SS).
    Die Einträge im USB Kext angepassen. Ein Eintrag mehr als das 15 Port-Limit erlaubt, also verzichte ich auf SS05. An HS05 befinden sich Touchpad und Tastatur, da SS und HS mit dem selben Index gerne an den selben Anschluss gehen und HS05 schon benutzt wird, wird SS05 vermutlich nicht benutzt. Wie man das macht ist hier beschrieben.
    Die IGPU des 8250u hat die PCIId 0x59178086 und die wird von macos nicht unterstützt. "Kein Problem", machen wir einen Kext Eintrag, der den Treiber lädt, haben wir gerade mit dem USB Controller gemacht. Die Methode funktioniert zwar beim 8700K, aber nicht bei der 8250u. Wie jetzt ?


    Buntes Treiben, hinter verschlossenen Türen
    "Glaube mir, ich stehe auf der Gästeliste, lass mich rein".
    Treiber für PCI Geräte werden meist an Hand ihrer PCIId ausgewählt. Nicht passende PCIId, kein Treiber. Weiß man, dass ein Treiber mit dem Gerät funktioniert obwohl der Treiber die PCIId nicht kennt, kann man den Treiber über einen Kexteintrag wie bei der USB Geschichte gezeigt, laden. Genau genommen fügt man die PCIId der Liste, der unterstützen Geräte, bei.
    "Ein Blick auf die Gästeliste und ich nenne dir einen passenden Namen".
    Was aber, wenn der Treiber die PCIId abfragt und anhand ihrer verschiedene Operationen vornimmt ? Dann klappt das ganze nicht mehr.
    An der Stelle springt Clover ein. Clover bietet unter Devices die Option eine Fake Id zu setzen. Das Gerät bekommt nun eine neue PCIId und der Treiber, der nach der Id fragt, denkt es ist ein passendes Gerät.
    "Ich kann beweisen, dass ich der bin, ich habe einen Ausweis (gefälscht, muss ja keiner wissen)".
    Clover verändert einen Eintrag in der Registry. Der Wert in der Registry stammt ursprünglich aus einem Register des PCI Gerätes. Manche Treiber fragen nun nicht die Registry nach der PCIId, sondern verwenden eine Funktion des PCI Gerätetreibers, die die Register liest, um die PCIId direkt vom Gerät zu holen. Da funktioniert die FakeId nicht. Da hilft nur das PCIFakeId Kext. Es patched die Funktion des Gerätetreibers, die Register liest und gibt bei Abfrage der Id Register die gewünschten Werte zurück.
    "Ein DNS, wäre mir das Reinkommen nicht Wert"
    Nun könnte ein Kext die Register ohne Hilfe des PCI Treibers lesen, aber das ist so aufwändig, dass es keiner macht, so wie auch niemand einen DNS Test am Empfang verlangt.
    Um die IGPU zum Laufen zu bringen wird man vermutlich einen falschen Namen und den dazugehörigen Ausweis brauchen. Also Fake Id in Clover und FakePCIId mit passendem Injector Kext.


    Die IGPU unterstützt verschiedene Ausgänge. Deren Konfiguration beschreibt der ig-platform.id Eintrag in der config.plist.


    Unsolid, damit die SSD nicht APFS formatiert wird, haben wir schon.


    Die Maus hat ihre Schuldigkeit getan, die Maus kann gehen, denn wir haben keinen Ethernet Anschluss. Außerdem hat Eva Angst vor Mäusen. Also raus mit IntelMausi.


    Das soll erst mal genügen. Alles andere kommt mit dem Finetuning.


    Wenn alles richtig konfiguriert ist, sollten wir von Eva einen ganzen und von EFI einen angebissenen Apfel bekommen können.


    Endlich geht's los
    TackTacktakTackTack... kennt ihr das ? Nicht die Trommeln aus Jumanjii, die machen Bumm, Bumm, Bumm. Ein Specht - ist es auch nicht.
    Das ist das Geräusch, das die F2 Taste macht, wenn man einen Lenovo Laptop auffordert das BIOS zu öffnen.
    Aber ich frage mich, ob ich etwas falsch gemacht habe. Denn das was ich zu sehen bekomme ist kein BIOS, das ist vielleicht ein B, bei großzügiger Auslegung ein BI, aber niemals ein BIOS.
    Wenn es nicht viel einzustellen gibt, kann man auch nicht viel einstellen. Secure Boot aus, Fast Boot vorsichtshalber aus.


    Und los geht's.
    "Huston, wir haben einen Boot". Aaaaaaaapfel, Waaaaaaaartebalken, Crash.
    Ok, ziemlich weit hinten vermutlich Grafikkartentreiber.
    Also -v gesetzt. Aber es bringt keine Erleuchtung, der Crash kommt irgendwie kurz nach Initialisierung der IGPU.
    In Ruhe nochmals die Debug Meldungen beim Starten gelesen und siehe da LPSS wird nicht geladen oder gefunden, was auch immer.
    Na und, deshalb crashed man nicht. Der Chipsatz ist auch nicht neuer als der in meinem großen Rechner und der zeigt den Fehler nicht. Ein kurzer Check zeigt, dass auf dem Stick noch ein frühes 10.3.2 ist - früh wie in Beta. Den großen mit dem System auf dem Stick gebootet und ein System Update laufen lassen. Zurück an den MiiX und Neustart. LPSS Fehler weg, aber immer noch ein Crash. Vielleicht ein USB 3.0 Problem. Also einen USB 2.0 Hub zwischen Rechner und Hub und Crash.
    Macht nichts, einfach eine falsche PCIId setzen und der Rechner lädt den Intel-Treiber nicht und der Rechner bootet. Keine Beschleunigung, aber immerhin Finder. Soweit die Theorie. Denkste System crashed, wie immer schwarzer Bildschirm, Neustart.
    Crash bei falscher ID schließt eigentlich ein Problem mit dem Intel Treiber aus, denn der wird bei falscher PCIId nicht geladen.
    Neueres Clover, Crash, anderes AptioFix, Crash, IGPU wieder als IGPU konfiguriert, crash.
    Unter Windows, war der für die Grafik reservierte Speicherplatz 128MB, aber vielleicht setzt ja erst Windows den Wert hoch, also IntelGraphicsDVMTFixup.kext rein. Neustart, Crash.
    IntelGraphicsFixup.kext rein, Neustart, Crash.
    Neustart, geht.
    Im Finder EFI Ordner kopiert, Registry Auszug erstellt. Schnell AppleALC in den Kext Ordner, erste unterstützte Id in der config.plist gesetzt.
    Neustart, Crash.
    AppleALC wieder raus, Neustart, Crash.
    Gesicherten EFI Ordner zurückgespielt, Neustart, Crash.
    Wie bitte ? Aber, aber ... es ging doch, Crash.
    Alle möglichen Häkchen gesetzt, gelöscht, Crash. Patches, rein, raus und im Ringelrein, Crash. Prozessor gegoogelt, Fehler gegoogelt, nichts.
    Rechner ausgeschaltet, erst still in der Ecke gesessen, dann Kopf gegen die Wand gehauen, was gäbe ich jetzt für ein paar tröstende Worte von Eva oder EFI, aber ihre Äpfel können sie behalten ich bin allergisch gegen Äpfel.
    Rechner einschalten, bootet.
    Stutz, Neustart, Crash. Was war anders ? Ich habe an Eva und EFI gedacht, also an Eva und EFI denken, Neustart, Crash. Ich habe Äpfel verflucht, also Äpfel verfluchen, Neustart, Crash. Ich habe den Rechner ausgeschaltet, also den Rechner ausschalten, Neustart und bootet.
    Ich kann es mir nicht erklären. Wie die Jungfrau zum Kinde, kommt der Rechner über das Ausschalten zum Finder.
    EFI Ordner von dem ganzen Testkram bereinigen, ausschalten, Neustart, bootet.
    Ok , System auf der internen Platte installieren. Eigentlich wollte ich die Windows NVMe nicht formatieren, falls ich sie noch mal brauche, also eine andere einbauen. Ich habe ja alles, also auch noch eine SM960 512 GB.
    Ich habe ja alles, auch eine gehörige Portion Pessimismus, also schließe ich die Augen und überlege ob ich zu Lösungsmittel, um die Klebestellen zu öffnen, oder gleich zur Flex greifen soll. Auf der Suche nach der geeigneten Stelle für die Flex fallen mir 6 kleine Schrauben unter dem Aufsteller auf.
    Wirklich klein und für einen Imbus Schraubendreher gedacht, den vermutlich Ameisen für ihre Uhren verwenden.
    Aber ich habe ja alles, auch ein Werkzeug Set von IFixit and da ist auch ein Bit für diese Schrauben dabei. 48 Drehungen später öffnet sich ein Spalt im Gehäuse. Zum IFixit Set gehört auch eine stumpfe Klinge um beim Gehäuse-Öffnen, Schnapper zurückzudrücken und das Gehäuse lässt sich damit ganz leicht öffnen.
    Die Kabel zum Bildschirm sind gerade lang genug, so dass man an das Innenleben kommt ohne erst Kabel zu lösen. Und zum ersten Mal, zum allerersten Mal sind Fluch und Lenovo-Entwickler nicht gleichbedeutend.

    Die NVMe liegt direkt unter der Prozessor Heatpipe. Ich bin mir nicht sicher, ob das eine gute Idee ist. Aber egal, löst man eine Kreuzschlitzschraube lässt sich die Heatpipe soweit anheben, dass man die NVMe tauschen kann. Gesagt getan.
    Und etwas weiter oben kann man die WiFi Karte sehen. Da das Gehäuse schon offen ist, könnte ich die ja bei der Gelegenheit tauschen. Ich hab ja alles, also habe ich auch noch eine DW1830 rum liegen. Super, passt nur nicht, sie ist links 2 mm zu breit, Pech. Aber ich hab ja alles, also auch noch eine DW1560 und die passt. Antennen ab, Karte raus, Antennen dran, DW1560 rein. Gehäuse zu und Rechner eingeschaltet und nichts .... Gar nichts. Nicht einmal das hässliche Lenovo Logo erscheint, selbst die Hintergrundbeleuchtung bleibt dunkel. "Rechner, ich weiß wo deine Schrauben sind". Also Schrauben raus, Schnapper entschnappen und gleich das Kabel wieder einstecken. Aber da ist kein Kabel, das man stecken müsste. Zeit für ein paar ausgesuchte Schimpfworte. Als erstes die DW1560 herausnehmen , denn da kommt man besser ran als an die NVMe. Bildschirm zur Seite halten, damit es keinen Kurzschluss gibt, einschalten und ich werde sofort mit dem Anblick eines Lenovo Logos gequält. Ich habe nie vermutet Masochist zu sein, aber diese Qual erfüllt mich mit Freude. DW1560 wieder rein und nichts geht mehr.
    Ich habe noch mehrere Apple WiFi Karten mit M.2 Adapter, aber die sind dreimal so groß und passen nicht. Also alte Karte rein , Rechner zu und eine neue 1560 bestellt, vorsichtshalber eine von/für Lenovo.
    Vom Stick gebootet, Installer gestartet, erster Neustart ... zweiter Neustart und ... Crash. Ausschalten, einschalten und ein bisschen weiter , aber fertig wird er nicht. Verzweiflung macht sich breit. Ich ersetze den Stick durch eine SSD in einem USB Adapter, nur aus praktischen Gründen. Es ist einfacher das Kabel am Adapter umzustecken, als für jede Änderung den Stick vom Mixx an den großen und zurück zu bringen. Und es schont die Anschlüsse an Rechnern und Stick
    Ich habe nicht erwartet, dass das was ändert und so ist es auch. Und die Änderungs-, Test- Orgie wiederholt sich. Auch schon verworfene Konfigurationen werden wieder ausprobiert, mal von USB, mal von der internen Platte gebootet, nur ist alles noch langsamer, weil ich statt neu zu starten jedes Mal ein- und ausschalte.
    Und aus heiterem Himmel - ich nehme an er ist heiter, es ist gegen 3:00 Uhr morgens und ziemlich dunkel, Eva und EFI schlafen bestimmt schon - bootet der Rechner, von USB und als er, als hätte ich es noch nicht gemerkt, mir mitteilt, dass das System auf Grund eines Fehlers neugestartet wurde, bin ich bereit die Legalisierung des Waffenbesitzes zu unterstützen und eine Youtube Anleitung wie man aus einem Two in One ein Three in One - Laptop, Tablet und 45er Kugel - macht vorzubereiten.
    Aber nach wenigen Minuten verschwindet der rote Schleier vor meinen Augen und ich kann den reflexartigen Drang unterdrücken die Meldung wegzuclicken. Stattdessen schaue ich mir den Bericht an.



    Und da ist er, der Silberstreif am Horizont - oder doch die Morgendämmerung.
    Mal sehen ob ich EFI einen guten Morgen bereiten kann.

  • Aller Anfang ist schwer
    Der heutige Exkurs führt uns in die unheimlichen Gefilde der Maschinensprache.
    Was hier beschrieben wird ist es eher komplex und bedarf eines soliden Grundwissens. Ich weiß nicht so recht ob ich Evas Begleiter rufen und bei ihnen beginnen soll, oder nur das Ergebnis präsentieren, weil es eh keinen interessiert und zu wenig Infos ein Nachverfolgen des Vorgehens sowieso unmöglich macht.
    Ich lasse Adam in Ruhe und gehe einen Mittelweg. Wem's zu viel wird einfach aufhören, nächstes Mal wird es wieder weniger "speziell". Aber vielleicht regt es den einen oder anderen an mal etwas tiefer in die Materie ein zu steigen.


    Nach dieser obskuren Einleitung sei gesagt, dass ich nicht weiß ob das Problem mit einem der tausend gebetsmühlenartig angewendeten Standard Rehab DSDT Patches nicht aufgetreten wäre. Das spielt auch keine Rolle, da ich sie bewußt nicht angewandt habe, konnten sie auch nichts verhindern.


    Panic auf der Titanic
    Dank AptioMemoryFix, funktioniert das NVRam und macos liefert den, in meiner letzten Post gezeigten, Fehlerbericht.


    Kerneltrap sagt einem, wo das Problem aufgetreten ist. Das ist oft nicht sehr aussagekräftig. Und ohne Anhaltspunkte sagt einem der Wert auch nicht viel.
    Interessanter ist da der Backtrace.


    Aus Computersicht werden immer nur Unterprogramme ausgeführt. Ob App, Programm, Funktion, Methode, Subroutine oder was auch immer für die CPU ist es ein Unterprogramm, das ausgeführt wird und dann dorthin zurückkehrt von wo es aufgerufen wurde.


    Babuschka
    Jedes Unterprogramm hat eine Aufgabe zu erfüllen. Ist die Aufgabe komplex oder hat man andere Unterprogramme, die Teile der Aufgabe lösen können, so bekommt ein solches eine Teilaufgabe zugewiesen und wird aufgerufen. Und es selbst ruft vermutlich wieder Unterprogramme auf. Unterprogramme, können sich sogar selbst aufrufen. Wie in einer virtuellen Babuschka hat man Unterprogramme in Unterprogrammen in Unterprogrammen. Dabei entsteht eine Hierarchie. Ein aufgerufenes Unterprogramm ist tiefer als das aufrufende Unterprogramm. Grob kann man sagen je tiefer, desto Detailarbeit. Es gilt zu beachten, dass ein Unterprogramm im Sinne von Quellcode an sich keine Position in der Hierarchie hat, sondern erst der Aufruf die Position festlegt. Unterprogramme können so je nach Programm weiter oben oder weiter unten oder sogar mehrmals in der Hierarchie vorkommen.


    Errötend folgt er ihren Spuren
    Jede Zeile im Backtrace zeigt uns in der ersten Spalte, die Adresse des Stackframes und in der zweiten Spalte die Rücksprungadresse eines Unterprogramms.
    Die Rücksprungadresse in der ersten Zeile zeigt wohin das gerade ausgeführte Unterprogramm zurückspringen wird, wenn es fertig ist. Die nächste Zeile zeigt uns wohin das Unterprogramm, das dieses Unterprogramm aufgerufen hat, springen wird, wenn es fertig ist usw.. Je tiefer ein Unterprogramm in der Hierarchie steht, desto weiter vorne steht es im Backtrace.
    Wir können also sehen, dass der Computer zum Zeitpunkt des Absturzes ein Unterprogramm ausgeführt hat, das danach zur Adressen 0xffffff8002e505f6 zurückkehren würde.
    Boah, Boah, Boa Constrictor, 0xffffff8002e505f6 meine Güte, da bin ich aber ... sprachlos.


    Das beste kommt zum Schluß
    Zugegebenermaßen klingt 0xffffff8002e505f6 nicht hilfreich.
    Aber am Ende des Tunnels ist Licht - keine Angst, wir gehen nicht drauf zu, wir schauen es uns nur an.
    "Kernel Extensions in backtrace:" sagt uns in welchen Kexten die Rücksprungadressen liegen und somit welche Kexte die Unterprogramme aufgerufen haben, die am Ende zum Crash führten.
    Die dependency Zeilen sagen uns in welchen Kexten das Kext, das in deren Abhängigkeit steht, Unterprogramme aufruft, aber nicht in welchen Kexten, die Kexte wieder Unterprogramme aufrufen. Aber es ist an dieser Stelle irrelevant.
    Wenn wir die dependency Zeilen streichen, bleiben 3 Zeilen übrig. Am Anfang steht die Kennung des Kextes und am Ende welchen Speicherbereich das Kext belegt. Rücksprungadressen, die in diesem Speicherbereich liegen, zeigen also auf die Stelle an der das Kext ein Unterprogramm aufgerufen hat.
    Hier habe ich die Rücksprungadressen, die sich einem der Kexte zuordnen lassen farblich markiert.



    Backtrace (CPU 2), Frame : Return Address
    0xffffff91201531a0 : 0xffffff8002e505f6
    0xffffff91201531f0 : 0xffffff8002f7d604
    0xffffff9120153230 : 0xffffff8002f6f0f9
    0xffffff91201532b0 : 0xffffff8002e02120
    0xffffff91201532d0 : 0xffffff8002e5002c
    0xffffff9120153400 : 0xffffff8002e4fdac
    0xffffff9120153460 : 0xffffff8002f6f2e9
    0xffffff91201535e0 : 0xffffff8002e02120
    0xffffff9120153600 : 0xffffff7f85621d08
    0xffffff9120153720 : 0xffffff7f85639388
    0xffffff9120153760 : 0xffffff7f856390f0
    0xffffff91201537b0 : 0xffffff7f85639037
    0xffffff9120153810 : 0xffffff7f856367e5
    0xffffff9120153850 : 0xffffff7f8563ba0c
    0xffffff9120153880 : 0xffffff7f85640088
    0xffffff91201538d0 : 0xffffff7f85661134
    0xffffff9120153950 : 0xffffff7f856624d9
    0xffffff9120153990 : 0xffffff7f856631c2
    0xffffff91201539e0 : 0xffffff7f8565a68c
    0xffffff9120153a20 : 0xffffff7f8565eded
    0xffffff9120153a80 : 0xffffff7f85617283

    0xffffff9120153b10 : 0xffffff7f83b97e99
    0xffffff9120153b60 : 0xffffff7f83b9734c
    0xffffff9120153b80 : 0xffffff7f83b974ca

    0xffffff9120153bb0 : 0xffffff7f84516c80
    0xffffff9120153bf0 : 0xffffff7f84517352
    0xffffff9120153c70 : 0xffffff7f8450f158

    0xffffff9120153cc0 : 0xffffff8003464cff
    0xffffff9120153d10 : 0xffffff80034c0ee7
    0xffffff9120153d70 : 0xffffff8002f292f2
    0xffffff9120153dc0 : 0xffffff8002e55c30
    0xffffff9120153e10 : 0xffffff8002e32cbd
    0xffffff9120153e60 : 0xffffff8002e45b7b
    0xffffff9120153ef0 : 0xffffff8002f5952d
    0xffffff9120153fa0 : 0xffffff8002e02926
    Kernel Extensions in backtrace:
    com.apple.iokit.IOACPIFamily(1.4)[8794C760-FDD9-3664-ADED-4A9BBEC6E517]@0xffffff7f83b96000->0xffffff7f83b9efff
    com.apple.driver.AppleACPIPlatform(6.1)[1804645B-B360-305E-B1BE-916F5E3E1CC4]@0xffffff7f85611000->0xffffff7f856acfff
    dependency: com.apple.iokit.IOACPIFamily(1.4)[8794C760-FDD9-3664-ADED-4A9BBEC6E517]@0xffffff7f83b96000
    dependency: com.apple.driver.AppleSMCRTC(1.0)[3F01C7A4-754F-39DD-A872-B4FAF0442276]@0xffffff7f84be4000
    dependency: com.apple.iokit.IOPCIFamily(2.9)[C08F7FC1-78A4-3A1B-BFE2-C07080CF2048]@0xffffff7f83734000
    dependency: com.apple.driver.AppleSMC(3.1.9)[259F0A4B-0AAB-30F3-8896-629A102CBD70]@0xffffff7f83b9f000
    com.apple.iokit.IOGraphicsFamily(517.22)[2AEA02BF-2A38-3674-A187-E5F610FD65B7]@0xffffff7f84500000->0xffffff7f84546fff
    dependency: com.apple.iokit.IOPCIFamily(2.9)[C08F7FC1-78A4-3A1B-BFE2-C07080CF2048]@0xffffff7f83734000




    Es ist alles relativ
    Wie bekommen wir nun raus, was da passiert ? Der Programmcode eines Kextes befindet sich für gewöhnlich in der Datei im MacOS Ordner des Kextes. Der Name der Datei steht in der Info.plist des Kextes und stimmt meist mit dem Namen des Kextes überein.
    Wie kommt man nun von einer Rücksprungadresse zu einer Stelle im Programm bzw. der Datei ?
    Man berechnet den Abstand zwischen der Rücksprungadresse und dem Anfang des Kextes. Dazu zieht man einfach die Startadresse des Kextes von der Rücksprungadresse ab.


    Das sieht dann so aus


    Backtrace (CPU 2), Frame : Return Address
    0xffffff91201531a0 : 0xffffff8002e505f6
    0xffffff91201531f0 : 0xffffff8002f7d604
    0xffffff9120153230 : 0xffffff8002f6f0f9
    0xffffff91201532b0 : 0xffffff8002e02120
    0xffffff91201532d0 : 0xffffff8002e5002c
    0xffffff9120153400 : 0xffffff8002e4fdac
    0xffffff9120153460 : 0xffffff8002f6f2e9
    0xffffff91201535e0 : 0xffffff8002e02120
    0xffffff9120153600 : 0x10d08
    0xffffff9120153720 : 0x28388
    0xffffff9120153760 : 0x280f0
    0xffffff91201537b0 : 0x28037
    0xffffff9120153810 : 0x257e5
    0xffffff9120153850 : 0x2Aa0c
    0xffffff9120153880 : 0x2F088
    0xffffff91201538d0 : 0x50134
    0xffffff9120153950 : 0x514d9
    0xffffff9120153990 : 0x521c2
    0xffffff91201539e0 : 0x4968c
    0xffffff9120153a20 : 0x4dded
    0xffffff9120153a80 : 0x062830

    0xffffff9120153b10 : 0x1e99
    0xffffff9120153b60 : 0x134c
    0xffffff9120153b80 : 0x14ca

    0xffffff9120153bb0 : 0x16c80
    0xffffff9120153bf0 : 0x17352
    0xffffff9120153c70 : 0x0f158

    0xffffff9120153cc0 : 0xffffff8003464cff
    0xffffff9120153d10 : 0xffffff80034c0ee7
    0xffffff9120153d70 : 0xffffff8002f292f2
    0xffffff9120153dc0 : 0xffffff8002e55c30
    0xffffff9120153e10 : 0xffffff8002e32cbd
    0xffffff9120153e60 : 0xffffff8002e45b7b
    0xffffff9120153ef0 : 0xffffff8002f5952d
    0xffffff9120153fa0 : 0xffffff8002e02926
    Kernel Extensions in backtrace:
    com.apple.iokit.IOACPIFamily(1.4)[8794C760-FDD9-3664-ADED-4A9BBEC6E517]@0xffffff7f83b96000->0xffffff7f83b9efff
    com.apple.driver.AppleACPIPlatform(6.1)[1804645B-B360-305E-B1BE-916F5E3E1CC4]@0xffffff7f85611000->0xffffff7f856acfff
    dependency: com.apple.iokit.IOACPIFamily(1.4)[8794C760-FDD9-3664-ADED-4A9BBEC6E517]@0xffffff7f83b96000
    dependency: com.apple.driver.AppleSMCRTC(1.0)[3F01C7A4-754F-39DD-A872-B4FAF0442276]@0xffffff7f84be4000
    dependency: com.apple.iokit.IOPCIFamily(2.9)[C08F7FC1-78A4-3A1B-BFE2-C07080CF2048]@0xffffff7f83734000
    dependency: com.apple.driver.AppleSMC(3.1.9)[259F0A4B-0AAB-30F3-8896-629A102CBD70]@0xffffff7f83b9f000
    com.apple.iokit.IOGraphicsFamily(517.22)[2AEA02BF-2A38-3674-A187-E5F610FD65B7]@0xffffff7f84500000->0xffffff7f84546fff
    dependency: com.apple.iokit.IOPCIFamily(2.9)[C08F7FC1-78A4-3A1B-BFE2-C07080CF2048]@0xffffff7f83734000



    Lesbar ist anders
    In der Datei stehen einfach nur ein Haufen Bytes. Hin und wieder lässt sich ein Text erkennen, aber alles in allem kommt einem das spanisch vor, außer man ist Engländer, dann kommt es einem griechisch vor. Weiß jemand wie es einem Spanier oder einem Griechen vorkommt ?


    Disassembler machen aus Maschinencode Assemblercode: Der ist besser lesbar, hält aber dem Vergleich mit C oder einer anderen Hochsprache nicht stand.
    Ich verwende Hopper um die Datei zu öffnen und zu disassemblieren, aber es geht auch mit Bordmitteln. Damit jeder die hiesigen Schritte nachvollziehen kann verwende ich deshalb den Terminal Befehl otool statt Hopper.


    Alles eine Frage der Perspektive
    Ok, wo fangen wir an ? Tief in der Hierarchie sind wir dem Fehler näher, aber erkennen möglicherweise vor lauter Bäumen den Wald nicht. Ganz oben sind wir möglicherweise so weit vom Wald weg, dass wir keine Bäume sehen. Also ..... eeene meeene Miste.......... oben, warum nicht, das sollte uns zumindest einen groben Hinweise geben worum es geht.
    Die "oberste" Rücksprungadresse in einem Kext ist 0x0f158 in IOGraphicsFamily. Das ist ein systemeigenes Kext und somit in /System/Library/Extensions zu finden. Mit einem Rechtsclick auf das Kext, kann man sich den Paketinhalt anzeigen lassen. Und wie immer wenn man etwas zeigen will, verwendet dieses Kext nicht die "normale" Kext-Struktur, sondern schmeißt alle Dateien zusammen. Der Finder zeigt uns zwei ausführbare Dateien iogdiagnose und IOGraphicsFamily. Wir könnten nun in der Info.plist nachschauen, welche Datei, den Programmcode für das Kext enthält, aber ich wage es zu behaupten, dass es die Datei mit dem Namen des Kextes ist.


    Zerleger
    "otool, otool bitte, auf die Bühne". Wir öffnen das Terminal. Und schreiben

    Code
    1. otool -tV


    Nach dem V folgt ein Leerschritt. -tV bedeutet Text-Segment anzeigen und mit Symbolen disassemblieren. Das Text Segment beinhaltet, anders als er der Name vermuten lässt, Programmcode.


    Nun ziehen wir die IOGraphicsFamily Datei aus dem Finder auf das Terminal Fenster, das spart es und den Pfad zu tippen.

    Code
    1. otool -tV /System/Library/Extensions/IOGraphicsFamily.kext/IOGraphicsFamily


    Dahinter kommt noch ein Leerschritt und die Angabe der Datei in die wir den Assemblercode geschrieben haben wollen. Da wir hier ein Unix Derivat haben kommt ein > vor den Dateinamen.

    Code
    1. otool -tV /System/Library/Extensions/IOGraphicsFamily.kext/IOGraphicsFamily >~/IOGF.txt


    Drücken wir nun Eingabe haben wir das Assemblerlisting in der Datei IOGF.txt im Benutzerverzeichnis. Die Tilde ~bedeutet Benutzerverzeichnis.


    Zuviel ist zuviel
    Öffnen wir die Datei werden wir von der schieren Anzahl von Zeilen erschlagen. Aber Gott sei Dank, müssen wir uns nicht alle Zeilen anschauen, sondern nur die in der näheren Umgebung unserer Rücksprungadressen. 0x0f158 ist die Rücksprungadresse die uns Interessiert also suchen wir nach 000f158 im Text. das 0x lassen wir weg, weil das Format der Adressen in der Datei kein 0x enthält und die Nullen fügen wir hinzu um die Suche einzugrenzen.


    Eine Code Zeile beginnt mit der Adresse, gefolgt vom Befehl und dessen Parametern und gegebenenfalls einem Kommentar.
    Kalt



    Rücksprungadressen zeigen hinter den Aufruf, denn dort soll das Programm ja weiter machen, wenn es aus dem Unterprogramm zurückkommt. Aufrufe von Unterprogrammen heißen call irgendwas.
    Wir scrollen nun solange nach oben, bis wir einen Namen sehen, wo sonst Adressen stehen. Das ist der Name des Unterprogrammes dessen Code wir gerade sehen entdecken.



    __ZN13IOFramebuffer13newUserClientEP4taskPvjPP12IOUserClient ist C++ Compiler Gibberish. Es geht los mit der Klasse IOFramebuffer, dann kommt der Unterprogrammname, newUserClient und dann der Typ des Parameters, IOUserClient.
    Wir wissen nun der Aufruf erfolgt sobald ein Framebuffer einen neuen UserClient anlegt. Die restlichen Texte zwischen diesem Namen und dem Aufruf sind genauso wenig hilfreich. Probieren wir es mit der nächst tieferen Rücksprungadresse.


    Warm
    Das ist die 0x17352. Suchen nach 00017352 und nach oben scrollen zum Unterprogrammnamen zeigt uns.



    Höre ich da ein Aaah ? Wir sind in der Open Methode eines FrameBuffers. Aber wichtiger ist der Aufruf der zu unserer Rücksprungadresse gehört heißt readClamshellState. Entweder erkundigt sich macos nach der Qualität der Muscheln oder es hat etwas mit dem Zuklappen des Laptops zu tun.


    Also auf zum nächsten Rücksprung, 0x16c80.


    Heiß



    Den Unterprogrammnamen brauchen wir nicht suchen, denn den kennen wir schon vom Aufruf, readClamshellState. Das sagt schon alles. Die Frage ist wie das Unterprogramm das macht. Wir versuchen nicht den Code zu analysieren, wir halten uns erst mal nur an die Texte.
    Wie jeder DSDT Junky weiß ist "PNP0C0D" die Kennung für ein Lid Device. Und wer es nicht weiß kann es googeln. Lid ist ein Deckel, eine Klappe, aber wir waren ja schon soweit, dass es was mit der Klappe zu tun hat. Wir können mit dem IORegistryEditor oder in der DSDT nachschauen, ob unser Rechner so ein klappriges Gerät hat. Er hat.
    Wir gehen also davon aus, dass das Programm nach dem Gerät mit dieser Kennung sucht - warum sonst würde die Kennung hier erwähnt.
    Nun stellt sich die Frage ob es das richtige Gerät ist, "IOACPIPlatformDevice" lässt vermuten, dass hier nachgeschaut wird ob es sich bei dem Gerät um ein IOACPIPlatformDevice handelt.
    Das sind ziemlich viele Vermutungen, aber sie lassen sich mit Hopper erhärten. Hopper liefert mehr Informationen und zeigt, dass mit "PNP0C0D" IOService::nameMatching(char const*, OSDictionary*) und mit dessen Ergebnis IOService::getMatchingServices(OSDictionary*) aufgerufen wird. Das ist die Art, wie man nach einem Service(Gerät) mit dieser Kennung gesucht.
    Hopper bestätigt auch, dass "IOACPIPlatformDevice" für einen DynamicCast und somit für eine Überprüfung des Gerätetyps verwendet wird.
    Der nächste Text ist "_LID". Unterstrich und 3 Buchstaben schreit nach einem DSDT Namen. Also die DSDT geöffnet und danach gesucht und siehe da es gibt eine Methode namens _LID in dem Gerät LID0, das vom Typ PNP0C0D ist. Es scheint nicht zu gewagt zu sein, zu behaupten, dass hier die Methode _LID ausgeführt wird. Leider gibt auch Hopper an der Stelle keinen Namen aus. Das ist aber kein Problem, da die nächste Rücksprungadresse im Backtrace innerhalb des aufgerufenen Unterprogrammes liegt. Die nächste Rücksprungadresse ist 0x14ca in IOACPIFamily.
    Wenn man nun AppleACPIPlatform mit otool disassembliert, wird man feststellen, dass die Rücksprungadresse in evaluateInteger liegt. Es wird also _LID ausgeführt und das Ergebnis als Integer interpretiert.


    Land in Sicht
    An der Stelle können wir sagen, dass der Crash dann erfolgt, wenn die _LID Methode des Gerätes vom Typ "PNP0C0D" aufgerufen wird. Das ist wie Amerika entdecken. Die Frage ist gehen wir an Land und erforschen den neuen Kontinent ? Wasser und Vorräte müssen wir nicht ergänzen, Anzeichen von Skorbut gibt es auch keine, wir müssen also nicht, wir können Amerika auch Columbus überlassen.


    Einfach nur die Klappe halten
    Da wir wissen wo es kracht, können wir überlegen wie wir es verhindern. Wenn das Gerät keine _LID Methode hat, kann es mit der _LID Methode keine Probleme geben. Oder man lässt ihn erst gar kein passendes Gerät finden.
    Ich entscheide mich für die Methode mit der Methode.
    Damit _LID nicht aufgerufen werden kann, wird die Methode einfach umbenannt. Mit einem passenden ACPI Patch macht das Clover sehr schön. Wir wollen _LID durch etwas anderes, sagen wir, BLID ersetzen. Der zu findende Wert ist 5F4C4944. Den ersetzen wir mit 424C4944.
    Der Rechner wird jetzt nicht mehr auf ein Schließen der Klappe reagieren, aber hoffentlich nicht mehr crashen.


    Und immer wieder geht die Sonne auf
    Also config.plist angepasst. Neustart und - alles ist gut und Neustart und immer noch gut.


    Der Fehler tritt nicht mehr auf, aber wir haben ihn nicht behoben, wir haben nur das Symptom bekämpft. Genau genommen haben wir nicht mal den Fehler gefunden, denn der tritt in einem der tieferen Unterprogramme auf, aber ein bootfähiges ist mir im Moment erstmal genug.


    Hexenwerk
    Der letzte Schritt, das Feststellen was passiert, scheint wie Hexenwerk und vielleicht etwas willkürlich. Das ist es aber nicht.
    Wenn man sich aus dem Assemblercode einen Pseudocode (etwas das aussieht wie Quellcode, aber keiner ist) bastelt bekommt man so etwas wie



    Wenn man Erfahrung mit IOKit hat, erkennt man die Vorgehensweise. Das ist Standard, wie man halt ein Gerät eines Gerätetypes, der in der DSDT vorkommt, findet, hat also nicht mit Gerate oder Hellsehen zu tun.
    Raten oder "Sich-Denken" muss man nur, wen einem das Wissen fehlt, führt aber zum selben Ziel - zumindest, wenn man richtig rät.


    Auf Regen folgt der Sonnenschein
    Nächstes Mal wird's wieder einfacher und alltagstauglicher.

    Edited 2 times, last by Brumbaer ().

  • für einen Imbus Schraubendreher gedacht, den vermutlich Ameisen für ihre Uhren verwenden.


    ooooh, Brumbaer.


    Diese Schreibe,.... und dann schließt das ganze noch mit einem Cliffhänger. :thumbup:


    Und jetzt höre ich auf zu lesen und freue mich auf morgen Abend mit dem dritten Teil...


    Danke.

    Liebe Grüße aus Berlin

  • @Brumbaer


    Hut ab , :P ( Auch wenn meine Kompetenz hier nichtig ist .)
    Lyrik und Wissenschaft !
    Das als Buch und ich kaufe es sofort. :D

  • @Brumbaer


    da bin ich ganz bei @coopter: einfach großartig geschrieben! Inhalt und Stil - einfach Klasse! Ich freue mich schon auf den nächsten Teil! :thumbsup:

    iMac13,2: Gigabyte Ga-Z77X-UD3H, i5-3450, XFX Radeon HD7850 2GB, 8GB RAM, Clover, OSX 10.15.4, 10.14.6, 10.12.6

    iMac14,1: Asus B85M-E, Xeon E3-1230 v3, XFX Radeon RX570 4GB, 8GB RAM, Clover, macOS 10.14.6, Windows 10

    iMac13,3: Asus H61M-K, i3-3225, intel HD4000, 4GB RAM, Clover, 10.13.6, 10.14, Ubuntu 18.04, Windows 10

    MacBookPro11,4: Lenovo Thinkpad W541, i5-4340M, intel HD4600 (+nVidia deaktiviert), 16 GB Ram, Whitelist-BIOS-Mod, Clover, macOS 10.14.6, Windows 10

  • Quote

    Dazu zieht man einfach die Startadresse des Kextes von der Rücksprungadresse ab.


    Habe mal die erste rote Return Adress genommen und den Startspeicherbereich von IOACPIFamiliy:


    0xffffff7f85621d08 - 0xffffff7f83b96000 = 0x1A8BD08 ≠ 0x10d08


    Was mache ich denn hier falsch?


    Edit: Hab was vergessen: Cooler dritter Teil. :thumbup:

    Liebe Grüße aus Berlin

  • So , ein Innensechskantschraubenschlüssel der Marke Inbus (S/B) =O


    Zum Glück kein Nimbus . :)


  • Habe mal die erste rote Return Adress genommen und den Startspeicherbereich von IOACPIFamiliy:


    0xffffff7f85621d08 - 0xffffff7f83b96000 = 0x1A8BD08 ≠ 0x10d08


    Was mache ich denn hier falsch?


    Nichts.
    Ich habe unten bei den Kexten die Farben vertauscht. Das ist alles.
    Vielen Dank fürs aufmerksame lesen.


    cu

  • @Brumbaer
    Habe ich es jetzt richtig verstanden... er läuft? 100% :)

  • Er läuft als Laptop, aber bei den Sonderfunktionen, wie Touch, Kameras und LTE sehe ich mitternachtsblau.
    Es folgen noch drei oder vier Artikel, die das Einrichten der Laptop Funktionen beschreiben, und dann muss ich mich entscheiden, ob ich Zeit in Touch, Kameras und LTE investieren will. Was ohne Datenblätter der Chips/Bauteile extrem aufwändig wäre. Leider sind Kameras und Touch über I2C angebunden, da besteht wenig Hoffnung einen Treiber zu finden. Für die Kameras kann man vielleicht einen Linux Treiber, an dem man sich orientieren kann, finden, für Touch sieht es da schlecht aus. Aber ich habe ja noch etwas Zeit.

  • Wegen der Touch-Geschichte solltest du mal mit @BlackOSX in Kontakt treten...
    Sein Xiaomi hat auch ein Touchpad an I2C hängen und bei ihm tut es wohl...

    Gruß
    Al6042

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

  • Das Touchpad funktioniert. Ich spreche vom Touchscreen von Wacom. Aber vielleicht gibt es einen HID Modus der sich ansprechen lässt.
    Googlen zeigt es gibt wohl ein VoodooI2C das auch Touchscreens unterstützt. Schau ma mal.

  • Oh... "Touch" und "Touch" sind an der Stelle dann zwei verschiedene Sachen...
    Upps... :)

    Gruß
    Al6042

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

  • Dumdidum
    Dumdidum, Dumdidum, Dumdidum, Dumdidum.
    Oberwasser, ich habe Oberwasser, denn nun bootet der Miix endlich, wie er soll, wann er soll, Dumdidum.


    Ja, ja, ja, jetzt wird wieder in die Hände gespuckt!
    Und als nächstes, werden all die Kexte, Patches und Häkchen, die ich in meiner Verzweiflung hinzugefügt hatte, wieder entfernt, Dumdidum.
    Hinterher, sehen Config.plist, Other und drivers64UEFI Ordner ganz normal aus und - das System bootet immer noch. Bevor ich es vergesse: Dumdidum.


    The sound of music
    So jetzt was Einfaches, Sound. Der Miix hat einen ALC298. Das weiß ich von Blick durchs Fenster, aber ich hätte es auch im IORegistryExplorer feststellen können.
    Ich bin ein großer AppleALC Fan und er hat mich bisher noch nicht im Stich gelassen. AppleALC braucht Lilu, aber das habe ich schon im Other Ordner.
    Nach AppleALC gegoogelt und da wird ein Link zu den "Supported" Codecs angeboten und - Dumdidum - die Layouts 3, 11, 13, 28, 29, 47 und 72 werden angeboten. Wo fängt man am besten an ? Wie wäre es mit dem Anfang. Ruckzucki, Layout Id 3 in der Config gesetzt, Neustarti und Booti - Dumdidum - Systemsteuerung, Ton, sieht gut aus, mal ein Böng und mal ein Bing und mal ein Tschingderassabum.


    Plaudertasche
    Strg-Leerschritt und nichts. Immer noch Dumdidium, aber eine Oktave tiefer, etwas knurriger, ich bin scheinbar leicht zu verstimmen. Siri angeclickt, "Öffne ITunes", Siri öffnet ITunes. Dumdidum, wieder zurück in normaler Tonlage.
    Siri, kann die Systemeinstellungen öffnen, aber nicht ihr eigenes Kontrollfeld, das BT Kontrollfeld hingegen schon. Egal. Die Siri-Öffnen-Taste auf Strg Leerschritt gelegt und - geht doch.
    Es kommen Töne raus, es gehen Töne rein, Layout Id 3 muss es sein.


    Trari-Trara, die Post ist da
    Zufälle gibt's, da bringt am selben der Tag der Postbote doch tatsächlich die DW1560. Es ist dem Postboten gegenüber ungerecht von zufällig zu reden, der ist sehr zuverlässig.
    "6 Schrauben, 6 Schrauben, die gehen leicht auf, der Rechner, der Rechner, der öffnet seinen Bauch". Auch nicht besser als Dumdidum, aber noch habe ich Oberwasser.
    Ok, Original raus, DW1560 rein. Antennen angeschlossen, Bildschirm hochgehalten, Rechner eingeschaltet und es kommt ein Logo, eigentlich ein Grund zur Freude, wenn es nicht so hässlich wäre, aber nicht hässlich genug um mir die Laune zu verderben. Dumdidum.


    Neustart, weder WiFi noch Bluetooth. Keine Überraschung, ist ja kein Standard Mac Gerät. Ich habe mit Absicht eine Lenovo Variante genommen, für den Fall, dass es eine Whitelist gibt.
    IORegistry Editor zeigt aber, dass die Teile erkannt werden. Falls man keine Mac kompatible Karte hat, ist der Standardweg für WiFi die Verwendung von FakePCIID und FakePCIID_Broadcom_WIFI und für Bluetooth die Verwendung von BrcmPatchRAM2 und BrcmFirmwareData.
    Reinkopiert und siehe da WiFI WiFiet, aber BT BTed nicht.
    Laut IORegistryExplorer handelt es sich um einen BCM20702A mit der VendorId 0x489 und der ProductId 0xe07a. Das sind USB Ids, äquivalent zur PCIId.
    Die DeviceClass ist 0xFF, das ist seltsam normalerweise ist sie bei BT Geräten 0xE0.
    "Kein Problem", denke ich noch, "trägst den Wert in BrcmPatchRAM2 nach". Gesagt, getan und was auch immer ich mache, es geht nicht. BrcmPatchRAM2 und BrcmFirmwareData wieder raus.


    Da gibt's doch ne App für, oder en Kext ?
    Apples BT Treiber befinden sich als PlugIns im IOBluetoothFamily.kext. PlugIns sind Kexte, die im PlugIns Ordner anderer Kexte abgelegt sind.

    • BroadcomBluetoothHostControllerUSBTransport.kext
    • BroadcomBluetooth20703USBTransport.kext
    • CSRBluetoothHostControllerUSBTransport.kext
    • CSRHIDTransitionDriver.kext
    • IOBluetoothHostControllerTransport.kext
    • IOBluetoothHostControllerUARTTransport.kext
    • IOBluetoothHostControllerUSBTransport.kext
    • IOBluetoothSerialManager.kext
    • IOBluetoothUSBDFU.kext

    Die CSR können aus der Liste raus (nicht aus dem Ordner), falscher Hersteller, da waren es nur noch 7.
    UART und Serial Manager haben mit speziellen Funktionen zu tun, können auch raus, da waren es nur noch 5.
    IOBluetoothHostControllerTransport scheint nichts mit USB zu tun zu haben, also erst mal raus, da waren es nur noch 4.

    • BroadcomBluetooth20703USBTransport.kext
    • BroadcomBluetoothHostControllerUSBTransport.kext
    • IOBluetoothUSBDFU.kext
    • IOBluetoothHostControllerUSBTransport.kext


    Mit plist und Tücke
    Kexte, die als Gerätetreiber dienen, haben in ihrer Info.plist meist IOKitPersonalities Einträge, in denen die Geräte identifiziert werden, die sie treiben sollen.


    Fangen wir mit der Info.plist des BroadcomBluetoothHostControllerUSBTransport.kext an. Tausende Einträge, alle rufen dieselbe Klasse auf und unterscheiden sich durch idProduct und idVendor.
    Die Controller basieren alle auf den 2045 und 2046 Serien von Broadcom also laut Google nur BT2.0 und BT 2.1. "Ihrrrr seieieieied rrrraus".


    Das nächste Broadcom Kext ist BroadcomBluetooth20703USBTransport.
    Die Einträge unterscheiden sich wieder nur in idProduct und idVendor. Der folgende Eintrag ist typisch:



    Alle verwenden eine Klasse, die BroadcomBluetooth20703USBTransport heißt. Dank Google wissen wir, dass der Chipsatz 20703 BT4.1 unterstützt, der 20702 aber nur BT4.0. Aufeinanderfolgende Teilenummer beim selben Hersteller, da kann man den Treiber schon mal probieren, kann funktionieren, muss aber nicht.
    Also lassen wir für das BT Modul diesen Treiber laden. Sowas haben wir schon mal für den USB Treiber gemacht. Der Eintrag wird kopiert und in das USB Kext im Other Ordner eingesetzt. Es muss nicht das USB Kext sein, man kann auch ein neues Kext machen, oder irgendein anderes nehmen, aber ich habe das Kext genau für solche Anpassungen eingeplant also hinein.
    idProduct und idVendor müssen noch angepasst werden.



    BrcmPatchRAM2 und BrcmFirmwareData werden nicht gebraucht. Neustart und WiFi und BT.
    Läuft, läuft bei mir.


    PS.
    Dumdidum

    Edited once, last by Brumbaer ().

  • Sound, wlan und BT :p
    glückwunsch :)