Posts by kuckkuck

    Ich dachte was im Bootloader eingestellt ist, bleibt dann auch gültig.

    Zwei Sachen:

    Erstmal allgemein was DF wahrscheinlich meint:

    Sehen wir es mal vereinfacht so: dein Computer startet -> dein Computer startet (weil als standard ausgewählt) OpenCore vom Datenträger -> OpenCore startet nun (weil als Standard in macOS ausgewählt) macOS. MacOS startet also nur, nachdem überhaupt OpenCore die Kontrolle hatte.

    Wenn du jetzt Windows bootest und Windows schiebt sich im BIOS vor den OpenCore Datenträger, dann sieht es so aus: dein Computer startet -> dein Computer startet (weil jetzt als Standard ausgewählt) Windows direkt vom Datenträger. OpenCore kommt insofern garnicht zum Zug und kann deswegen nichts an der Situation ändern. Windows wird an OpenCore "vorbei" gestartet.


    Die andere Sache ist: vielleicht musst du dein Problem einfach mal ein bisschen besser beschreiben. Der * symbolisiert im OC BootPicker ja die Standard-Bootoption. Was ist jetzt das Problem: nach einem Windows Start steht das * vor Windows und nicht mehr vor macOS oder sonstwo? Oder, nach einem Windows Start startet automatisch Windows und der Bootpicker erscheint garnicht, bei manuellem Start vom OC Datenträger ist die Standard-Bootoption aber nach wie vor macOS?

    CMMChris Zu dem Zeitpunkt zu dem USBInjectAll entworfen wurde hat Apple auch schon Port Injectors genutzt, genau wie heute, und USB Dummy Kexts waren ebenfalls bereits bekannt und funktionell. Die Idee und Funktion von USBInjectAll ist eine andere. Hier lohnt es sich eventuell einen genaueren Blick auf _UPC im ACPI Spec sowie die verkorksten OEM ACPI Tabellen zu werfen. Inwiefern ist die Methode veraltet?


    Ebenfalls lese ich ständig an verschiedensten Stellen, teilweise von Personen die wirklich in der Materie stecken, dass USBInjectAll schädlich ist und nicht long term genutzt werden soll. Woher kommt das? Was sollte der Grund dafür sein? USB Port Limit Patch und die damit verbundene fixed size array Problematik und USBInjectAll sind zwei paar Schuhe, USBInjectAll ist kein PortLimit Patch.

    al6042 Stimmt, man kann da auch anders ansetzen und anstatt links zu sammeln eine Anleitung dazu schreiben, wie man Kexts richtig aus den Originalquellen raussucht und dann installiert. Finde ich nicht dumm....


    BastelKlug du musst auf einen Unterbereich gehen und dann gibt es auch noch den Bereich "Community Anleitungen"

    hehe Naja für ein Network Install unter Windows bringt es einen wenig

    al6042 Geht eher darum, dass der KextUpdater ja nicht zwingend läuft, wenn man den Hacky noch garnicht installiert hat ;)

    Soll ich jetzt einen Foreneintrag veröffentlichen, der dann vielleicht später verschoben wird?

    Nein, du kannst wie gesagt einfach einen Beitrag im richtigen Bereich der Wiki verfassen, probiers mal aus.

    Stimmt, eine KextUpdater Windows und Linux Version bräuchte es :D [wech]

    Aber ich verstehe was du meinst, evtl könnte sich auch einfach Sascha_77 die Links die im KU eingebaut sind automatisch ausgeben lassen oder dir einen entsprechenden Weg zeigen, damit du einen solchen Links Beitrag aktuell halten könntest. Wieder andere Idee wäre einfach dafür zu sorgen, dass unsere Downloadsektion, die ja eigentlich genau dafür da ist, etwas aktueller wäre.


    Anyway, wenn dir irgendeine Idee kommt und du brauchst links, hier sind schonmal ein paar bevor du anfängst zu googeln ;)

    'beim lieben roten Apfel mit der 86' aka TomatenTony gibt es praktisch nie aktuelle Kexts und von dort stammt auch fast nichts :D Aber gut, dass nur am Rande.


    Hast du dir mal den Kext Updater genauer angeschaut? Der macht im Prinzip genau das und eigentlich noch viel mehr:zustimm:

    Was genau ist denn die Idee? Ein Eintrag in dem die Links zu den original Quellen aller möglichen Kexts stehen? Oder ein Thread in dem alle Kexts runterladbar sind? Oder ein Eintrag in dem die Funktionalität aller/verschiedener Kexts beschrieben wird?

    Es gibt bereits den Kext Updater und das hier: Lilu & Plugins mit Bootflags und Beispielen :)

    Nur zur Information:

    Du kannst ohne weiteres im Bereich Wiki des Lexikons einen neuen Eintrag erstellen und diesen mit Inhalt füllen, den du für sinnvoll hältst, das Team stellt den Beitrag dann frei :) Wenn du das ganze auch noch aktuell halten würdest, würden sich sicherlich einige über die entstandene Kext Liste freuen. Tipp: Sei dir des Aufwands bewusst, die das aktuell halten einer solchen Liste mit sich bringt oder entwirf die Liste von Anfang an so, dass sie mit wenig Aufwand oder automatisch per Bot aktuell gehalten werden kann:thumbup:

    It is also used when installing operating system updates.

    Naja repliziert halt den authenticated restart den macOS nutzt, ein Feature was dadurch möglich wird und auf das beispielsweise Systemupdates zurückgreifen oder was bei remote-usage extrem praktisch ist. Das ungeschützte Speichern des encryption Keys in den Speicher durch VirtualSMC ist eher notgedrungen, bzw nicht einfach anders möglich, soweit ich weiß landet der Key bei echten Macs auf dem SMC.


    Edit:

    Nähere Infos gibts bei fdesetup, zB mittels man fdesetup im Terminal:

    Macht euch nicht zu große Sorgen um ssdtprgen, die Inhalte von ssdtprgen sind bis auf den Plugin-Type irrelevant sobald das X86PlatformPlugin für aktuelle CPUs lädt und haben keinen Einfluss auf PowerManagement. Einfluss auf PM kann dann nur durch Veränderungen am X86PlatformPlugin, zB an den FrequencyVector Daten, genommen werden (hier kann CPUFriend für Custom Injects helfen)

    Werden ACPI Renames auch beim Boot von Nicht-MacOS vorgenommen?:/ Ich habs gerade nicht im Kopf...


    karacho Hast du bei dem Setup bei dem Linux nicht so ganz will eine DSDT oded SSDTs im Einsatz? _OSI ist eigentlich ziemlich intuitiv, man könnte wahrscheinlich sogar irgendwie ein _OSI Konstrukt um eine gesamte DSDT spannen aber irgendwie ist das hirnrissig :D

    Der XOSI Patch macht nur in Kombination mit einer SSDT-XOSI Sinn, welche alle _OSI Calls abfängt und bestimmt definiert (zB Windows 10). Der Patch wird häufig verwendet um zB Windows zu simulieren und die Feature Sets bei Laptops dadurch zu erweitern, aber ist in den meisten Fällen nicht besonders sinnvoll oder bringt mehr Probleme als Lösungen.

    Obst-Terminator Hast du auch die zweite DSDT getestet, die ich dir noch gesendet hatte? Da taucht auch kein Audio-Gerät im Systembericht auf?

    Abgesehen davon sollte der Inject von verschiedenen Layout-IDs ja jetzt funktionieren. Häng dich also am besten einfach an unseren AppleALC Spezialisten MacPeet an, ich bin mir sicher ihr werdet irgendetwas finden :)


    MacPeet Was unsere Offtopic Diskussion angeht: Es mag in Teilen eine Geschmacksache sein, in den allermeisten aller Fälle ist die SSDT- und Hotpatch-Methode aber schlichtweg die bessere, sauberere und zuverlässigere Methode und der beste Weg dirty ACPI Relocate-Patches (wie FixRegions) oder gar -Konflikte zu umgehen und das ist ebenfalls seit langem bekannt. Ich weiß wie man eine DSDT patcht und welche Patches dabei allgemein verwendet werden, ich weiß auch wie das ACPI funktioniert und deswegen sind mir auch die Probleme von DSDT Injections bekannt, sowie dass allerhand User von iASL ausgelesene DSDTs patchen und benutzen. Ich sage auch nicht, dass letzteres pauschal falsch ist, aber wie oben genauestens erklärt ist diese Vorgehensweise nicht zukunftssicher und Allem voraus nicht Windows-Kompatibel, siehe Operating System Interface Level und ACPI Interface im ACPI Spec, und somit mindestens für OpenCore nicht geeignet.

    ändern sich mit einem Bios-Update evtl. auch die ganzen External-Einträge zu den SSDT´s

    Du meinst komplette Device-Names wie sie in Add-On SSDTs meist innerhalb von External-Deklarationen vorhanden sind? Das wäre mir neu, diese sind sogar fast immer innerhalb aller Boards eines Herstellers, eines Chipsatzes, konsistent...

    Ich muss mal ein paar Sachen, u.a Missverständnisse richtigstellen. Also eins nach dem anderen:

    Hast Du nun Audio mit AppleALC? Mit welcher Id und welchen Ergebnissen/Geräten?

    Ja, er hat jetzt (wenn auch rauschendes) Audio mit AppleALC. Wie gesagt, wir haben da nur ganz kurz dran arbeiten können, aber ich habe dir mal den letzten IOReg angehängt, den ich von Obst-Terminator erhalten habe, sowie die "proof-of-concept" DSDT, die ich ihm bereitgestellt hatte.

    Ferner wurde hier gesagt, dass die DSDT nicht komplett gepatcht ist und Du die nicht benutzen solltest.

    Habe auch nie behauptet, dass ich diese komplett gepatcht hätte.

    Erstmal bezog sich das nicht auf deine, sondern auf meine DSDT. Ich habe nicht deine DSDT überarbeitet, sondern mir die Arbeit gespart nachzuvollziehen, was du gemacht hast, und eine neue gepatcht. Diese DSDT ist die "proof-of-concept" DSDT von der ich rede (im Anhang).

    Habe nur HDEF eingefügt und einige IRQ´s entfernt (IRQ-Patch).

    Dann haben wir also praktisch das Gleiche gemacht. Ich habe ebenfalls nur verschiedene _DSM Properties zu HDEF hinzugefügt und verschiedene IRQs überarbeitet. Ich habe diesen Beitrag verlinkt bekommen und gesehen, dass unter OC die alc-layout-id wohl nicht auf IO Ebene erscheint und zudem mitbekommen, dass verschiedene Versuche die ID zu injecten scheitern. Daraufhin habe ich mich daran gemacht analog zum anscheinend funktionierenden Clover Ordner+IOReg die ID 28 zu injecten. Um zu sehen, ob es überhaupt funktioniert direkt mehrfach (wie gesagt wir hatten keine Zeit) nach folgendem Schema: https://github.com/acidanthera…ppleALC/kern_alc.cpp#L173

    Sprich inject von layout-id (wie eh und je, wird zu alc-layout-id gecastet) und alc-layout-id über _DSM, sowie global override durch "alcid" bootarg. Schon hier sieht man, dass die DSDT nur proof-of-concept ist.

    Wenn man keine gepatchte einträgt, dann wird immer die Clean geladen, welche auch nicht gepatcht ist.

    Ich verstehe nicht genau was du damit sagen willst. Klar wird die in die FW gegossene (dynamische) DSDT geladen, wenn kein Override per Bootloader erfolgt, aber die Idee ist ja die dynamische Struktur der Main-System-Table (DSDT) beizubehalten und diese durch SSDTs zu erweitern...

    Diese von mir ist quasi die Clean mit den kleinen Änderungen.

    Die von mir ebenfalls, aber hier liegt ja bereits das Problem. Die von uns bereitgestellten DSDTs sind marginal, nicht "komplett" gepatcht und somit nicht als "gepatchtes ACPI" zu bezeichnen. Das heißt es bedarf entweder noch einigen Erweiterungen der DSDT damit auf dem Laptop alles läuft, oder die ACPI Struktur muss noch anderweitig erweitert werden, zB mit SSDTs und Hotpatches. Besonders Renames werden hier problematisch, da OC Hotpatch-Renames vor dem Laden der hinterlegten Tabellen ausführt "Perform binary patches in ACPI tables before table addition or removal.". Vor diesem Hintergrund & wegen den doppelten Injections in meiner HDEF Methode & aufgrund meiner allgemeinen Ablehnung gegenüber gepatchten DSDTs (siehe unten) habe ich dazu geraten meine halb gepatchte proof-of-concept DSDT nicht zu benutzen und stattdessen eine sinnvolle ACPI Struktur aufzusetzen.

    Auch nach Biosupdate lässt sich auf Grund der bereits gemachten Erfahrungen schnell wieder eine DSDT patchen und warum überhaupt ein Biosupdate, sofern alles super läuft.

    Eine DSDT ist was Device-States und besonders OperationRegions und die darin enthaltenen MMIO Adressen angeht weitaus dynamischer als das, nicht nur Biosupdates, sondern besonders BIOS-Settings und Boot-environments (OS), sowie Hardware-Veränderungen und BIOS-Patches haben Einfluss auf die DSDT und verändern dieses dynamische Konstrukt. In dem Moment wo wir eine DSDT (über zB MaciASL) auslesen sehen wir den aktuellen Machine-State, das ist ein Snapshot aber nicht mehr und im Falle MaciASL sogar bereits durch das Boot-environment modifiziert. Wenn wir diesen Snapshot als Basis für eine DSDT nutzen, die allgemeingültig sein soll und unter OC selbst mit Windows kompatibel sein muss, sind wir meiner Meinung nach auf dem Holzweg. Der beste Weg sollte deshalb sein die bestehende ACPI Struktur höchstens zu ergänzen und diese Ergänzungen möglichst dynamisch zu gestalten, und das passiert am allerbesten indem man ACPI Patches umgeht und IO-Patches (siehe WEG & AppleALC) benutzt und wenn es doch ACPI sein muss, dann auf SSDTs zurückgreift und diese mindestens Boot-environment-abhängig gestaltet (_OSI-abhängige Konstrukte um zB Windows-Kompatibilität zu sichern). Und ob das jetzt 20 oder 2 SSDTs sind ist erstmal Präferenz des Users (Übersicht etc.) und der Injection-Zeit-Unterschied von 20 SSDTs gegenüber von 2 sollte erstens marginal sein und zweitens zu vernachlässigen sein gegenüber der Zeit die es braucht den Inhalt der SSDT-Tabellen zu Parsen ganz zu schweigen vom Blocken und Parsen einer kompletten DSDT. Und was Renames angeht, sollten globale Hotpatch-Renames benutzt werden, denn beim Durchführen von Renames in einer DSDT, müssten ohne Hotpatch alle anderen Tabellen, die auch die umbenannten Devices enthalten, ebenfalls gepatcht und explizit gepatcht injected werden, da es sonst zu Device-Name Inkonsistenzen kommen würde, aber ich glaube das ist klar.

    Ich hoffe es fühlt sich niemand angegriffen, ich wollte nur meine Gedanken zu dem Thema loswerden und wenn es andere Erkenntnisse gibt lasse ich mich auch gerne eines besseren belehren :) Ansonsten angenehme Weihnachtsferien an alle!

    Files

    • IOREG_Test_4.zip

      (542.13 kB, downloaded 6 times, last: )
    • DSDT.aml

      (64.78 kB, downloaded 6 times, last: )

    Wir hatten gestern nur Zeit für genau einen Versuch. Ich habe mir diesen Beitrag angeschaut (OC-config) Lenovo Thinkpad T450 Bluetooth und Soundprobleme wobei mir aufgefallen ist, dass es an der HDEF injection hapert. Daraufhin wollte ich erstmal primär die Injektion nach HDEF über _DSM testen und habe ein Testproperty hinterlegt. Zudem habe ich mir die noch vorhandenen Unterschiede im ACPI zwischen der Clover und OC EFI angeschaut, auf den schnellen Blick sah es mir so aus als würden unter OC bisher keine IRQ Fixes injected werden (unter Clover HPET, TMR, IPIC...). Deswegen habe ich als ersten test Obst-Terminator dazu geraten die bestehende ACPI Struktur (teilweise) zu deaktivieren (Damit sich nichts in die Quere kommt, diese Angst hat sich später bestätigt) und habe eine DSDT schnellerhand mit den HPET fixes aus einer deiner SSDTs grt + IRQ Fixes und "alc-layout-id" (letzteres wahrscheinlich nicht nötig) ausgestattet. Daraufhin funktionierte bereits die Injektion, Audio aber nur, wenn große Teile der restlichen vorhandenen ACPI Struktur (kommt wohl von irgendeinem Github) deaktiviert waren.

    Daraufhin meine Zusammenfassung der gestrigen Erkenntnisse im Discord:

    Quote

    Also ich denke es gibt mehrere Probleme, erstmals wurde bei vielen Zwischenergebnissen im Thread (nur schnell überflogen) garnicht mehr die layout-id injected. In dem Fall macht es keinen Sinn an etwas anderem zu arbeiten (wie der Injektion eines anderes layouts), als daran die layout-id korrekt zu injecten. Und in den Fällen in denen die layout-id korrekt injected wurde war es wahrscheinlich eins von 2 Problemen: 1. zu viel Zeug im ACPI was sich in die Quere kommt, injection von Werten die AppleALC/WEG selber fixt, inkonsistente Renames etc. oder 2. der altbekannte IRQ Fix, unter Clover angehakt und beim Übertragen zu OC übersehen und per OC-Hotpatch ein wenig tricky zu implementieren.

    Wie im Discord bereits gesagt solltest du die DSDT nicht weiter verwenden Obst-Terminator . Lies am besten nochmal alles was ich gestern abend dazu noch geschrieben habe.

    Die DSDT war nur ein proof of concept und eine schnelle Möglichkeit für mich um Devices zu finden und IRQ Fixes u.ä einzubauen. Die DSDT ist ansonsten bis auf die HDEF _DSM in keiner weise gepatcht.

    Also bitte wie gesagt per SSDTs und Renames in Hotpatches überführen und außerdem die bestehende ACPI Struktur überarbeiten, die an einigen stellen inkonsistent ist/war.

    Das kommt auf das SMBios und die Hardware drauf an. Aber da müsste man mal tiefer graben und zB mit gezielten grep Befehlen Apples KernelExtensions durchforsten, um zu sehen welche Treiber von SBUS abhängig sind. Dann entweder die Treiber bereits so weit kennen, um zu wissen was sie in etwa tun (eindeutige Namen, bereits in der Community bekannt, etc) oder die Treiber soweit auseinander nehmen/reverse engineeren bis man weiß was der Treiber genau mit SBUS macht. Daraufhin dann sehen, ob man will, dass die abhängigen Treiber laden, ob die von ihnen ausgeführten Aktionen ausschlaggebend für Funktionen des gewählten SMBIOS sind, oder sinnvoll für die benutzte Hardware erscheinen, im letzteren Fall wieder SMBIOS Dependencies beachten (kann man einen Treiber eines vorhandenen SMBIOS laden, der auf die eigene HW passt? Lädt ein bestimmter Treiber nur bei Benutzung eines bestimmten SMBios?...) und dann gegebenfalls SBUS im ACPI so implementieren/faken, wie es beim passenden SMBios gemacht wird um die richtigen Treiber zu laden. Man sieht, das Ganze ist ziemlich kompliziert wenn man ins Detail geht und wir reden hier nur von einem einzigen, evtl sogar kosmetischen Treiber...

    XDSM ist ein dirty patch und macht nichts anderes als die Device Specific Method zu deaktivieren. Du könntest statt XDSM auch HEYY schreiben, würde das gleiche bewirken. Über _DSM Methoden kann man zB Properties einem Device mitgeben, die von Apples SW verarbeitet werden. Das geht aber nicht nur über _DSM Methoden sondern auch auf verschiedenen andere Wegen wie zB durch injection auf I/O Ebene, wie es zB WEG macht. Wenn du gerne DeviceProperties per _DSM injecten willst, dann kannst du das natürlich machen, ich würde dir aber dann stark davon abraten allgemeine Patches wie _DSM zu XDSM zu benutzen und stattdessen in allen Fällen in denen deine gewünschte DevProp-Injection aufgrund einer bereits vorhandenen _DSM nicht funktioniert, auf alternative Wege umzusteigen, wie zB auf die DeviceProperty Injection von OpenCore oder Clover. Viel Erfolg!