Windows über Opencore

Aber am Ende führen alle Wege zur bootmgfw.efi. Die Fehler mit dem Bluescreen werden von OC verursacht, warum fällt mir jetzt nicht ein, aber mit der ACPI von Baio1977 bootet W11 bei mir.

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...

griven Ich bekomme einen Black Screen.

Hat das eine andere Bedeutung?

Blackscreen Urs ja nicht, vielmehr ein Error-Screen.
bei mir hat sich das gerade durch die Bootoption UEFI/SCM = yes aufgelöst. Windows bootet nun ohne den ACPI Error. bluebyte

Arkturus du meinst sicherlich im BIOS Bootoption UEFI/CSM

Da muss vorher Kernel DMA Protection ausgeschaltet werden.

So weit war ich jetzt auch schon.

Also CSM Support auf yes

Hast du auch diesen Bühneneffekt?

Sieht voll sch... aus wenn CSM-Mode aktiv.

Dann lieber Windows über BIOS-Bootmenü.

Oder gar kein Windows. Wer braucht Windows?

Habe jetzt wieder UEFI/CSM disabled.

Na ja, UEFI/CSM findet sich im BIOS-Segment Boot. Ob das auch in der config.plist zu OC zu finden? Darüber habe noch gar nicht nachgedacht. Ich hatte ja auch an den Thread von MacPeet angeknüpft. bluebyte

Aber hier bist du genau richtig. Ich habe nun die EFI von cobanramo auf der Disk. Mit dem ACPI kann ich nun Windows aus OC booten.

Habe in der Zwischenzeit auch AppleVTD mit angepasster DMAR.aml und DMAC über SSDT aktiviert.

Den Rest mache ich morgen auf Arbeit. Da habe ich meine Ruhe.

Bei CSM habe ich beim Start von Windows ein Schachbrett auf dem Bildschirm.

Da hängt wohl mit der Nvidia MX330 und der SSDT-Disable_GPU_RP09.aml zusammen.

Da muss ich wohl nachbessern.

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)...

griven vielen Dank für deinen Hinweis.

Es ist wirklich so, dass ich mit einer SSDT die Nvidia Mx330 für Mac OS deaktiviere.

Die SSDT hat Simpify in Windows generiert. Leider kenne ich mich damit zu wenig aus.

Die OSI-Weichen sind gesetzt.

Ich habe ein T15 ohne dGPU bestellt und ein T19 mit Nvidia MX330 bekommen.

Eigentlich ein Mehrwert für den gleichen Preis.

Im Gegensatz zu meinem T520 haben die neuen Kisten kein Optimus.

Die Nvidia lässt sich somit im BIOS nicht deaktivieren.

Dank des TB/USBC lässt sich ein externer Monitor anschließen.

Der HDMI ist unter Mac OS tot.

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...

griven da kommt kein _PWR. Ich schicke hier jetzt auch mal meine EFI hoch zur TÜV-Prüfung. Die Mega-Kexts sind deaktiviert. Die deaktivierten SSDT stammen aus Simplify. Die habe ich durch SSDT aus der OCAT-Database ersetzt. Der SSDT-EC.aml hatte besagten Compiler-Fehler. Kein Warning, sondern richtigen Error. Die roten Kexts stammen aus Simplify. Die grünen Kexts stammen aus der OCAT-Database.

Rot-Grün bedeutet, dass die Kext aus Simplify stammt und ich sie nutze, weil ich es nicht besser weiss. Das betrifft die Kext für die dGPU.

Die Serial ist durch mehrmaliges Klicken neu generiert. So meckert OCAT nicht.

Auf Github sind Repos, die sind mit SSDT, Patches und Renames dermaßen vollgeknallt, dagegen sieht meine Konfiguration richtig jungfräulich aus.

Es sollte natürlich T15 heißen. T19 mit 19 Zoll Panel.

Das wäre schön, aber es würde nicht in meine Arbeitstasche passen.

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).

Quote from bluebyte

Habe in der Zwischenzeit auch AppleVTD mit angepasster DMAR.aml und DMAC über SSDT aktiviert.

Den Rest mache ich morgen auf Arbeit. Da habe ich meine Ruhe.

Bei CSM habe ich beim Start von Windows ein Schachbrett auf dem Bildschirm.

Da hängt wohl mit der Nvidia MX330 und der SSDT-Disable_GPU_RP09.aml zusammen.

Da muss ich wohl nachbessern.

Wenn die Deaktivierung der NVIDIA sich auch auf Windows auswirkt, würde ich Windows über das BIOS-Bootmenü booten. Dann kannst du die Vorteile der Nvidia genießen bluebyte

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.

griven ich habe schon letzte Woche testweise alles für ACPI deaktiviert.

Auch damit bekam ich einen Blue Screen beim Starten von Windows.

Kann das ja nochmal versuchen. Versuch macht klug.

Einen hab ich noch in petto.

bluebyte windows merkt sich scheinbar Fehlstarts und wartet auf Reparatur. Du musst noch den Anpassungen in der config.plist einmal über BIOS-Bootmenü bis zum Desktop durchstarten. Das hatte ich hier oder in Konversation schon mal beschrieben. Manchmal hatte es geholfen über ESC UEFI aufzurufen und ohne irgendwas bootete W11 dann. Das ist nicht stabil.

tja, inzwischen nutze ich für W11 wieder das BIOS-Bootmenü. Weder aktives UEFI/CSM noch die in #5 genannten Quirks haben dauerhaft das Problem mit dem Stop Code: ACPI_Bios_Error (0xA5) gelöst.

Arkturus  griven  apfel-baum habt ihr schon mal refind probiert?

Hab mir das gestern mal angeschaut. Bei der Ausführung des Scripts hat er gemeckert wegen SIP. Ausserdem soll die Installation über die Recovery erfolgen?

Andererseits, was wollen wir mit Windows?

bluebyte

du meinst den bootmanager? nein, bisher nicht

lg

Nein kenne ich nicht. bluebyte