Posts by kuckkuck

    alexxandoer Naja erstmal nichts einbauen was du nicht brauchst. Und nur Sachen einbauen bei denen du weißt was sie tun. Dann eine DSDT extrahieren und nach dem Schlagwort "STAS" suchen. Wenn du STAS in MaciASL finden kannst, brauchst du SSDT-AWAC, ansonsten SSDT-RTC0. SSDT-EC-USBX aus den OC git solltest du ebenfalls benutzen. Renames brauchst du keine, nur die bekannten acidanthera und Lilu Kexts.


    Nightflyer Hast du es getestet?

    Das ist mMn kein NVME oder sonstiges Hardware Problem, ich würde auf ACPI tippen. Du musst die für dein Gerät passenden ACPI Tabellen einsetzen, Clover ACPI Renames sind bei OC fehl am Platz. SSDT-AWAC geht nicht in allen Fällen, je nach ACPI musst du ggf SSDT-RTC0 aus dem acidanthera Repository nutzen.

    _hai_ Jein. Die meisten Embedded Controller in Hackintoshs sind inkompatibel zu Apples EC-Implementation, man versucht garnicht erst echte Kompatibilität herzustellen und Apples Embedded Controller Treiber werden auf Hackys auch nicht benötigt. Unter Desktops ignoriert man den Embedded Controller einfach und injected per SSDT-EC ein Fake-Gerät, dass einfach nur sagt "Ich bin ein Apple kompatibler Embedded Controller", aber nichts tut wenn man es anspricht. Warum das Ganze? Weil bestimmte Gerätetreiber-Funktionalitäten außerhalb des EC von Apple nur aktiviert werden, wenn ein kompatibler Embedded Controller existiert. Das war früher vorallem der USB Strombedarf. Doch wenn man SMBios ≥ iMac17,1, ≥ MacBookPro14,3, ≥ iMacPro oder ≥ MacPro7,1 verwendet, hat selbst bei vorhandenem Fake-Apple-EC der gewollte Treiber nicht geladen, da diese Apple Geräte zusätzlich noch ein USBX Gerät besitzen. Deswegen injectet man hier zusätzlich noch ein Fake-USBX-Gerät (Non Apple Geräte besitzen diese Hardware nicht). Wie sich die Treibersituation in letzter Zeit entwickelt hat, konnte ich leider nicht wirklich mitverfolgen. Ich hab irgendwo mal gelesen, dass irgendwann angeblich macOS Boot nur möglich war, wenn ein EC vorhanden war, aber auch gelesen, dass die entsprechenden USB-Power Treiber inzwischen garnicht mehr von EC abhängen... Was da dran ist weiß ich nicht, in jedem Fall tut man nicht schlecht daran entsprechende Apple-kompatible Fake-Devices per ACPI zu injecten.

    Da steht doch alles was man wissen muss... Bis auf diesen Teil:

    Quote

    Skylake and newer devices will want USBX as well

    , der da heißen müsste:

    Für SMBios größer gleich ≥ iMac17,1 und ≥ MacBookPro14,3 (also einschließlich iMac17,1 und MacBookPro14,3) ist dies: SSDT_EC-USBX.aml


    Welche Unklarheiten gibt es denn noch? Mit NVMe-Platten, Speedstep oder Timer hat SSDT-EC nichts zu tun.

    plutect Wenn RebuildAppleMemoryMap funktioniert, dann benutzen. Wenn du im Debug Log die Meldung findest, dass MAT supportet ist, solltest du zusätzlichen EnableWriteUnprotector deaktivieren, sorgt für bessere Sicherheit.

    "OCS: Failed to parse data field als value..."

    Korrupte config.plist. Datei manuell überprüfen und verbessern, oder neu erstellen. Das kleine command-line Utility ocvalidate kann helfen um Fehler in der config.plist zu finden.

    serdeliuk Everything is documented in the first post. Currently I am not hosting the source code anywhere publicly as I think that it's not benefitial as the Main-Dev will have his own take and strategy dealing with the issue which should not be forcing the old prelinked kernel but instead implement KC support (my Clover Mod is a workaround!). Furthermore my explanations should be sufficient for anyone familiar with the Clover Source to implement it by themselves.

    The main part has been debugging Clover to find out what's wrong, creating the right KernelBooterExtension User-Patches for Big Sur Kernel, Injecting the two crucial NVRam properties and making sure that broken Clover Code will not be executed when booting Big Sur.

    Die Clover Version im Anhang setzt beim Boot von macOS Big Sur automatisch die NVRam Variablen booter-fileset-kernel und booter-fileset-basesystem, sodass beim Boot einer bestehenden Installation von Big Sur automatisch der prelinked kernel forciert wird. [...] In der angehängten Clover Version sind die eigentlichen internen Patchingmechanismen für den Boot von Big Sur (10.16) deaktiviert um Dopplungen zu meiden.

    You can take a look at the Clover Debug Log when booting Big Sur with my Clover Version and look out for debug prints including "BIG SUR". Everything should be clear by that.

    Sicher, und auch in Hibernation auf Hackys würde ich mich gerne mal noch etwas mehr reinfuchsen. Leider habe ich aktuell keine Zeit dazu.


    Was die Bootzeiten angeht gibt es ein paar Herangehensweisen. Wenn man den Verbose Boot anschaut, kann man darauf achten, ob bestimmte Teile besonders lange brauchen und versuchen herauszufinden an welcher Hard-/Software das liegt. An anderen Stellen ist es ganz normal, dass der Boot lange braucht. Erster Ansatz ist häufig ein sauberes ACPI, ACPI Errors sind hinderlich beim Boot. Ebenfalls kann mit IOReg überprüft werden, ob für alle Geräte die passenden Treiber laden. Manchmal gibt es problematische Hardware, zB WLAN Karten, welche man über den Verbose Boot ausfindig machen kann. Nächstes zentrales Thema ist Powermanagement, XCPM kann den Boot mitunter extrem beschleunigen. Ich habe hier einen Guide zum Powermanagement Feintuning geschrieben: CPUFriend Guide, HWP & Speedstep: X86PlatformPlugin vs ACPI_SMC_PlatformPlugin

    Was ebenfalls die Bootzeit verlangsamen kann sind HDDs mit APFS, da der fsck filesystemcheck mitunter sehr lange braucht. Die Problematik hat Brumbaer in den Anfängen von APFS mit Unsolid.kext umgangen. Auch kann WEG und Framebuffer Patching helfen, wenn der Boot im Bereich der Grafikinitialisierung (Bootlogo verschwindet kurz) ins Stocken gerät. Ansonsten gilt häufig die Faustregel: Je sauberer das System, desto schneller der Boot. Pauschale Bootbeschleuniger gibt es nicht wirklich...

    Ok, ich denke damit wäre dann das kleine Mysterium (leider) auch geklärt, denn wie chmeseb richtig schreibt:

    wenn Du FV aktiv hast, stellt der Login lediglich die Eingabe der Passphrase zum Entschlüsseln dar, der Bootvorgang läuft erst danach ab

    wir reden hier nur von der Zeit zwischen Bootauswahl und Anzeige des FileVault Login Bildschirms, welcher sich zeitlich gesehen im Bereich von boot.efi, also vor dem eigentlichen Boot befindet

    Liegt also nicht an Hibernation (hibernatemode ist 0) oder Warm-Boot wie ich dachte (bzw. wo ich gerne drauf hinaus wollte), sondern daran, dass die FileVault Login UI vor dem eigentlichen Boot gezeigt wird, welcher bei dir dann etwa 35 Sekunden braucht.

    Danke trotzdem für die Infos :)

    ozw00d Auf dem System aus dem Video ist FileVault aktiv? Sprich wir reden hier nur von der Zeit zwischen Bootauswahl und Anzeige des FileVault Login Bildschirms, welcher sich zeitlich gesehen im Bereich von boot.efi, also vor dem eigentlichen Boot befindet? Dann macht die "Bootzeit" wesentlich mehr Sinn, denn der eigentliche Boot sollte dann erst nach Eingabe des Passworts und dem daraus folgenden entschlüsseln der Platte und automatischen Login (Passwort Forwarding) ins macOS selber erfolgen.


    Edit: ozw00d ein Auszug aus pmset -g reicht ;)

    Danke :) Mich würde pmset und am liebsten sogar noch ein IOReg interessieren. Ich habe in der Vergangenheit häufiger versucht anderen zu helfen ihre Bootzeiten zu minimieren und ein paar Dinge haben meistens geholfen, würde mich interessieren ob diese Tweaks auch in deinem System zu finden sind.

    Wie kommt es, dass kein Fortschrittsbalken erscheint? Die Bootzeiten aller meiner Hackys waren schon immer deutlich unter 10 Sekunden, aber <2,5 Sekunden, wie in deinem Video, habe ich selbst bei Macs noch nie gesehen, Respekt. Meine Hardware ist auch etwas älter als deine, hast du APFS HDDs im System? Und welcher hibernatemode ist denn gesetzt laut pmset? Interessante Sache...

    Mich würde auch mal ein Verbose Boot Log interessieren, wenn das geht :)


    EDIT: ozw00d Ich habe die Beiträge mal in ein neuen Thema verschoben, weil wir von OpenCore abkommen. Ich würde hier sehr gerne etwas detaillierter über Warm-/Cold-Boot, Hibernation, etc reden :)

    Gemäß den besprochenen Veränderungen am Kernel von macOS Big Sur BETA 3:


    1. OSVersion lautet mit Beta 3+ 11.0 und nicht mehr 10.16. Die bisherigen Patches werden nur auf 10.16 angewandt. 11.0 muss also durch ein Komma getrennt zu MatchOS hinzugefügt werden.


    2. Die Suche nach dem StartPattern (488D152B262500) für Kxld ist verändert, das StartPattern heißt jetzt 488D157C542500. Dieses Bytepattern wird sich in der Zukunft weiter verändern und die Suche wieder kaputt gehen!
    Einfacher Fix:

    Code
    1. <key>StartPattern</key>
    2. <data>SI0VKyYlAA==</data>

    komplett aus der Plist entfernen, der Patch ist auch so einmalig und somit unproblematisch, da er relativ präzise gewählt ist.

    Alternativ die alten Werte durch das neue StartPattern ersetzen:

    Code
    1. <key>StartPattern</key>
    2. <data>SI0VfFQlAA==</data>


    Sinnvoller Fix: Symbolbasierte Suche mit procedure = removeKextBootstrap oder StartPattern mit Wildcards implementieren (00 00 00 00 c7 45 ?? 00 00 00 00 48 8d 15). Für Ersteres muss die MACH-O Bibliothek wieder funktionieren und für Letzteres muss die Suche nach StartPattern mit Wildcards möglich sein. Ich denke die offizielle Clover Version sollte bald auf diese Art und Weise funktionieren.


    Allgemein: Es ist nicht eindeutig, ob der Kxld Patch unter Big Sur auf allen Systemen notwendig ist, oder ob die dahinterliegende Race Condition garnicht erst entsteht. Eventuell kann der Fix also sogar ganz weg gelassen werden bzw. booten manche Systeme auch ohne Kxld Patch.


    Eine mögliche Plist mit den KernelPatches für Beta 3 sieht also wie folgt aus:

    StartPattern kann für KbeBS-KxldUnmap wieder hinzugefügt werden.

    Danke, hättest du noch ein passendes Clover Log für mich? Und hast du davor den NVRam geleert? Es geht explizit um das Setzen der Variablen, wenn sie davor schon im NVRam standen ist es natürliche klar, dass der prelinked lädt ;)