Beiträge von griven

Den eigentlich entscheidenden Hinweis hat grt in Post #6 gegeben...

Das Problem/die Artefakte liegen an der Art und Weise wie der GOP Treiber (UEFI Mode) die iGPU initialisiert. Das Problem ist ein altes und durchaus bekanntes Problem und tritt fast nur bei Laptops auf. Die "Tricks" gegen das Problem liegen entweder in dem von grt beschriebenen aktivieren des CSM Modes (was das initialisieren des UEFI GOP unterdrückt und macOS erlaubt die iGPU sauber zu initialisieren) oder in der Wahl einer anderen als der nativen Auflösung für die Bios/Preboot Phase was dann einen Modewechsel beim initialisieren des Grafiktreibers von macOS zur Folge hat mit einem vergleichbaren Ergebnis wie dem aktivieren des CSM Modes (gleiches passiert beim Sleep/Wake Zyklus von macOS was dann auch zu einer sauberen Ausgabe führt).

Hier liegt bluebyte vollkommen richtig. Alle M-Serie Mac's haben unified Memory welcher direkt mit auf dem SoC sitzt. Ein einfaches Aufrüsten im Sinne von DIMM Module tauschen/hinzufügen ist hier nicht.

Die beiden schwarzen Bausteine auf dem Bild sind der RAM. Ein wenig irreführend ist der Titel des Videos denn der dort gezeigte Mini ist ein Macmini 8.1 aus dem Jahr 2018 welcher bis zum erscheinen des M1 MacMini ende 2020 verkauft wurde

Wie oben schon erwähnt die OWC Aura passt und ist speziell dafür gemacht

bluebyte ich hab am Elitebook auch nur eine NVME verbaut die sich Win11 und macOS (Sequoia und Tahoe) teilen hier gibt es mit dem Boot von Win11 über OC allerdings keine Probleme (mit ausnahme des weiter vorne schon erwähnten Bios Settings das beim Windows Start via OC nicht aktiv sein darf). Spezielle Einstellungen habe ich nicht vorgenommen im Gegenteil ich habe hier mehr oder weniger einfach die von OpCoreSimplify erzeugte EFI übernommen und nur geringfügig angepasst.

Nee beim early 2013 funktioniert das so tatsächlich nicht

Bei diesen Modellen kommst Du nicht mit einer Adapter Lösung hin sondern musst ein Modul kaufen das direkt passt (OWC Aura Pro zum Beispiel hier: https://www.proshop.de/SSD/OWC…dJhPyxifO0tfyHHUfU3cAAR5h). Der Hintergrund dafür ist das die early 2013 Modelle kein NVME unterstützen sondern nur SATA und auch keinen Anschluss verwenden der direkt auf dem MB sitzt sondern die SSD in ein eigenes "Gehäuse" verbaut haben innerhalb des Rechners.

Ist ein Mid 2015 und frisst SATA M.2 oder M.2 NVME SSD's

Wichtig an der Stelle zu wissen ist das das MacBook einen properitären Anschluss hat sprich Du kannst nicht einfach eine beliebige NVME verwenden da diese nicht passt. Entweder verwendest Du wie von artmusic erwähnt eine SSD von Kingspec (habe ich auch in einem Mid 2015 verbaut und ist okay) die dann direkt mit dem korrekten Anschluss ausgestattet ist oder Du kaufst Dir einen Adapter (https://www.sintech-shop.de/m-…13-2015-jahr-imac/a-10813 als Beispiel) und verwendest dann eine M.2 NVME nach Geschmack

Wirkt sie sich aber nicht Arkturus

Wie ich ja oben schon versucht habe zu erklären sorgt die Methode _STA in der SSDT dafür das deren Code nur dann ausgeführt wird wenn sich das OS als Darwin identifiziert. Die _STA Methode wird immer als erstes ausgeführt und definiert durch die dort enthaltene _OSI Weiche das dieses Device nur dann im ACPI Gerätebaum erscheint wenn das OS Darwin ist (Return 0X0F) und in allen anderen Fällen eben nicht (Return ZERO). Anders ausgedrückt die _INI Methode auf das Geräte wir nur ausgeführt wenn Darwin bootet andernfalls passiert einfach gar nichts und der Rechner verhält sich exakt so wie im dessen originalen ACPI definiert.

Sieht soweit erstmal gut aus bzw. sehe ich nichts was auffällig wäre. Du kannst jetzt Testweise mal die SSDT-XOSI und den dazu gehörenden Patch/Rename deaktivieren und gucken ob das was ändert (ich bezweifle das zwar aber man weiß ja nie).

Die kann es aber eigentlich nicht sein denn laut M$ bezieht sich der Fehlercode explizit auf die _PWR Methode und die kommt in der SSDT ja gar nicht vor. Deine SSDT zu deaktivierung der NVIDIA macht grob das folgende:

• Device (DGPU) -> es wird ein logisches ACPI Device mit dem Namen DGPU erzeugt
• Method (_STA,-> dem erzeugten Device wird eine Status Methode hinzugefügt (wird als erstes verarbeitet) die mittels _OSI Weiche entscheidet on das Device existiert ( Return 0x0F) oder nicht ( Return ZERO)
• Für den Fall das sich das System als Darwin (MacOS) identifiziert gibt _STA 0x0F zurück das Device wird im ACPI Gerätebaum sichtbar und kann vom OS angesteuert werden für alle anderen Fälle gibt _STA Zero zurück und der Rest des Codes wird ignoriert. Wenn Darwin, dann folgt als nächstes Method (_INI und hier ist nur ein einziger Sprung definiert nämlich der zu Method (_OFF,. Das Gerät wird also direkt bei der Initialisierung (Method (_INI) abgeschaltet

Windows meckert hier aber über einen Fehler in einer der _PWR Methoden. Schau mal alle SSDT's durch die Du im Einsatz hast ob das irgendwo ein _PWR definiert ist und guck Dir auch mal an was unter ACPI->Patch so passiert ggf. gibt es auch hier irgendein Rename oder was in die Richtung das da möglicherweise problematisch ist...

Grundvoraussetzung für iGPU: Intel CPU mit maximal UHD 630 iGPU

Maximal von macOS unterstützte AMD Serie: NAVI 21 = RX6900XT (siehe hier: https://dortania.github.io/GPU…-gpu.html#native-amd-gpus )

NVIDIA GPU leider nein, leider gar nicht (zumindest nicht für Deinen usecase so paar olle Kepler basierte gehen mit Kniffen noch)

Insgesamt ist Dein Vorhaben zwar umsetzbar (also DUAL GPU) aber ob das so sinnvoll ist sei dahingestellt. Zum einen frisst ja die jeweils nicht genutzte GPU trotzdem Strom und benötigt die entsprechenden Anschlüsse (Netzteil entsprechend dimensionieren und auch an die Kühlung denken weil Abwärme erzeugt die auch) und zum anderen wird es vermutlich auch nicht reichen die AMD einfach zusätzlich einzubauen und rennt dann schon mit anderen Worten Du wirst Dir ggf. auch Gedanken dazu machen müssen wie Du die NVIDIA unter macOS abschaltest und verbirgst so, das macOS sie gar nicht erst zu Gesicht bekommt (ACPI Bastelspaß garantiert). Meiner Meinung nach wird man hier mit spitzem Stift rechnen müssen ob der nötige Aufwand (sowohl finanziell als auch in Zeit) das zu erwartenden Ergebnis rechtfertig oder ob es nicht am Ende doch mehr Sinn macht ggf. noch ein paar Euro zusätzlich zu investieren und lieber einen (kleinen) M-Serie Mac zu kaufen.

bluebyte zu dem Fehlercode auf Deinen Bild sagt M$ folgendes:

Kontrollier also mal Deine ACPI Dateien und ggf. auch Patches auf Dingen die eine _PWR Methode enthalten und/oder verändern und schau das da überall zwei Elemente drin sind (ggf. die Methode testweise einfach mal entfernen fall nötig oder sauber mit _OSI Weichen nur für Darwin implementieren)...

Ich hatte am Elitebook ganz ähnliche Probleme mit dem Win11 Boot über OC. Am langen Ende war es eine Bios Einstellung die das Problem "behoben" hat. Wenn ich Windows am Elite über OC booten möchte dann darf im Bios VT-x nicht aktiviert sein vielleicht ist ja hier der Fall ganz ähnlich gelagert? Mir hat das auch einige graue Haare beschert...

In den meißten Fällen braucht es zunächst mal ein gehacktes Bios/UEFI damit man damit überhaupt was anderes als ChromeOS laufen lassen kann und dann bleibt die Frage nach der Hardware Ausstattung. Viele Chromebooks/Chromedesks sind lowest End was Hardware angeht oder gleich ARM in beiden Fällen wird das mit macOS schwierig werden weil läuft dann entweder wie ein Sack Nüsse oder eben auch gar nicht je nachdem...

Bestimmt aber ein lustiges Versuchs/Bastelprojekt eben immer abhängig davon was in der Kiste drinnen steckt *gg*

Bluetooth bindet üblicherweise über USB an daher schau im Gerätemanger mal bei den USB Geräten da wirst Du dann wohl fündig werden.

Joa das geht (also sogar beides) wobei die IGPU je nachdem was Du unter macOS machen willst möglicherweise vollkommen ausreichend ist.

Hat bei mir am Elitebook gefühlt nicht länger gedauert als auch bei Sequoia bzw. kommt das mit der angezeigten Restzeit bei mir ganz gut hin

Wobei das von Dir beschriebene erinnert mich an die berühmt, berüchtigte Apple Sekunde die ja gerne mal ne Dreiviertel Stunde dauert *Hihi*

nobby auch wenn es Tahoe nicht anzeigt gib in dem Dialog einfach 25 an und geh weiter es erstellt dann in der Folge die EFI für Tahoe und zeigt in der Folge auch Tahoe an. Scheint evtl. ein Bug in der Darstellung zu sein (habe es eben unter Win11 am Elitebook getestet und da zeigt es mir Tahoe auch nicht an wenn ich aber 25 eintippe geht es weiter)...

Sound wird auch nur dann wieder über die Internen Quellen gehen wenn man die AppleHDA mittel Patcher nachinstalliert (ggf. auch mittels geeignetem Kextinstaller). Apple hat die Unterstützung für die "alten", analogen Codecs entfernt einfach weil es keine offiziell unterstützten Mac's mehr gibt die einen solchen Codec einsetzen. Aus Sicht von Apple also vollkommen nachvollziehbar das man ungenutzte Altlasten aus dem System wirft...

Witzigerweise war bei meinem M1 Macbook das Update etwas über 10Gig schwer entweder schraubt Apple deutlich mehr an den ARM Versionen von macOS 26 oder mein M1 ist ein Sonderling denn anders ist eigentlich kaum zu erklären warum die Intel Kiste von MacGrummel mit was um die 3 Gig klarkommt und das M1 nicht. Hat irgendwer mit M Chip ähnliche Erfahrungen gemacht?

Sieht auf den ersten Blick ganz okay aus...

Basiert die denn auf der EFI mit der Dein System aktuell läuft oder hast Du ganz von vorne angefangen? Im Grunde reicht es ja die aktuelle EFI einfach auf den aktuellsten Stand zu bringen (Kext und OpenCore) zumindest wenn das System erstmal so läuft wie es soll. Bzgl. AMFIPass.kext und den Anpassungen für OCLP bzgl. WLAN solltest Du ggf. so vorgehen das Du diese erst aktivierst wenn das Update vollständig installiert ist da es gelegentlich vorkommt das der Installer sich an AMFIPass reibt...

Sonst irgendwas am SATA dran ausser der Festplatte ?!?

Bitte auch nochmal das Bios auf korrekte Einstellungen checken. Im Bereich SATA muss:

-> SATA Mode: AHCI

-> HotPlug auf allen Ports: DIsabled

-> Alle ungenutzten SATA Ports: Disabled (ist optional)

Generell bitt auch sicherstellen das CSM Support disabled ist kann andernfalls auch zu Fehlern führen. Wenn das alles nicht fruchtet kannst Du ggf. auch noch den folgenden Kext einmal mit aufnehmen in Deine EFI: CtlnaAHCIPort.kext.zip