Booteinträge bei OpenCore

Wenn in Misc -> Security -> ScanPolicy der Wert "0" eingetragen ist, dann werden alle startbaren Laufwerke und Volumes angezeigt. Ich rate aber davon ab, die Systeme über den Opencore-Picker zu starten, wenn DSDT und SSDTs nicht sauber mit _OSI konfiguriert sind. Alle ACPI-Patches, die für den Betrieb von Mac OS notwendig sind, kämen sonst auch in Windows und Linux zum Einsatz. Beim Start von Windows könnte das zu einem Blue Screen führen mit der Meldung "ACPI-Error". Außerdem hätte der PC dann den wunderschönen Namen "acidanthera". Mit Linux habe ich das noch nicht probiert.

Die Werte für ScanPolicy sind in der Anleitung ausführlich dokumentiert. Den entsprechenden Wert erhält man durch das aufaddieren der einzelnen Bits und das Umwandeln in dezimal. Also braucht man dafür einen Taschenrechner mit "Programmiermodus". Hört sich jetzt wild an, ist aber halb so schlimm.

Das Thema wurde hier schon x-mal diskutiert. Einfach mal die Suchfunktion bemühen.

Ich starte meine verschiedenen Systeme über die Auswahl im BIOS. Weil ich, ehrlich gesagt, keinen Bock dazu habe, diese _OSI-Weichen zu konfigurieren. Bei Gigabyte-Boards in den meisten Fällen "F12".

https://www.hackintosh-forum.d…t/1631156/?highlight=_OSI

Der apfelnico oder griven können das gut!

So lange du keine wilden ACPI-Patches gemacht hast, die Windows ins Gehege kommen, kann im NORMALFALL nicht viel passieren. Außer das Windows beim nächsten Start die Reparatur startet.

Ist mir auch schon passiert.

Nachtrag zu vorhin: das Umrechnen geht mit der Doku und der Calculator.App ganz easy.

Erweiterte Suche oder Suche nach "_OSI" oder "OSI".

ASUS X550L Hackintosh

5T33Z0 hast Recht, geht damit einfacher. Benutze heute noch den Clover Configurator zum Erzeugen des SMBIOS. Gibt nichts Besseres.

Meine Empfehlung ist den beiliegenden SSDT-OC-XOSI.aml im Config unter Acpi einzubinden und unter patch den rename anzuwenden, damit ist das problem behoben und benötigt kein hantieren mit Bios boot Menü.

Allerdings wird auf diese weise unter Windows oder Linux die Hardware auch so erkannt wie unter SMBios definiert wurde.

Gruss Coban

EDit:

Mit Scanpolicy 0 gibt es wiederum andere probleme, da können auch unerwünschte Einträge auftauchen.

Mit dem Eintrag ScanPolicy=28252931 erzielte ich für meine Bedürfnisse das beste Ergebnis.

cobanramo ist es noch heute so, dass der Rechner bei Automatik noch acidanthera heißt, es sei denn man deaktiviert die Automatik/Generic und füllt die Felder selbst aus?

Als Systemhersteller wird es als acidanthera definiert ja, aber kannst ja den auch anpassen wenn es anders heissen soll. Laut Handbuch soll wird es ja auch nicht empfohlen den als Apple zu definieren.

Hier bei mir sieht es so aus..

Unter Windows sieht es dann so aus.

Gruss Coban

Ich bin zwar nicht cobanramo aber kann vielleicht auch die eine oder andere Frage beantworten

1. _OSI steht für "Operation System Interface" und ist eine Methode im ACPI die dazu dient zu erkennen welche Funktionen ein Betriebssystem unterstützt oder eben auch nicht. Im ACPI eines Rechners werden so zum Beispiel bestimmte Features nur für bestimmte Betriebssysteme bereitgestellt man erkennt das im AML Code dann an Konstrukten die in etwas so aussehen if(_OSI("Darwin")) oder if(_OSI("Windows_2013")). Der Patch benennt alle Aufrufe der _OSI Methode in XOSI um und deaktiviert diese damit faktisch. Gemacht wird das um etwaige Einschränkungen die durch die _OSI Methode ggf. gegeben sind aufzuheben bzw. wie im gegebenen Beispiel diese Aufrufe auf die in der SSDT definierte Methode XOSI umzuleiten.

2. Fast richtig. Die XOSI Methode bekommt bei Ihrem Aufruf ein Argument mitgegeben als Argument kommt hier das mit was vor dem rename im Original mal da gestanden hat. Der rename sorgt ja dafür das jedes vorkommen von _OSI durch XOSI ersetzt wird so würde aus einem _OSI("Windows-2015") ein XOSI("Windows-2015") werden wobei das Argument Windows-2015 eben an die XOSI Methode durchgereicht wird. Die Methode in der SSDT prüft jetzt im ersten Aufschlag ob es sich beim Inhalt von _OSI um macOS handelt (Darwin) wobei dieser Wert von macOS selbst ans ACPI übergeben wird und sofern es sich um macOS handelt wird im weiteren geprüft ob das übergebene Argument "Windows-2015" (Steht für Windows 10) ist und falls dem so ist gibt XOSI den Wert 0xFFFFFFFF zurück ansonsten halt ZERO. Sollte nicht Darwin gestartet worden sein wird von XOSI einfach das Argument zurückgegeben womit die Methode aufgerufen wurde.

3. Kannst Du ohne weiteres weglassen wenn Du diese Medien Formen nicht nutzt oder als Bootlaufwerk verwenden möchtest.

lg und Bitteschön

Also das letzte zuerst, ScanPolicy ist natürlich für die eigene Bedürfnisse anzupassen, wenn du kein SAS oder SDCard usw. hast brauchst du diesen Bit auch nicht konfigurieren.

Anderseits sieht es so aus, ScanPolicy auf 0 zu stellen und somit komplett auszuschalten ist nicht grad von Vorteil, somit wird je nach installation (MultiBoot, Windows, Linux usw.) zbspl. unbenötigte Einträge auch mehrfach aufgelistet oder einfach alles in einem Haufen dargestellt.

Ich persönlich Steuer mit diesem Wert halt umgekehrt, es soll alles scannen aber das was ich nicht benötige ausschliessen.

Die _OSI zu XOSI geschichte beruht auf die Acpi Call von Microsoft Windows, wurde glaub zum ersten mal von Rehabman aktiv eingesetzt für USBInject und patching.

Mit der Methode kann man eben abfragen ob "Windows" oder "Darwin" (MacOs) gestartet wurde somit eben auch mitgeben wenn "Darwin" am start wert x ansonsten halt y usw.

Das Arg0 == "Windows 2015" basiert auch auf die Microsoft Acpi Dokumentation im obigen link, bedeutet halt das es ein Windows 10 ist.

Bspl.

Gruss Coban

Edit: Bin nicht grad der Schreiber, griven mag das bestimmt besser rüberbringen.

Danke Bert

Genau die Reihenfolge dabei ist immer wie folgt:

- ggf. definierte ACPI Tabellen droppen.

- Patches anwenden.

- ACPI Tabellen die geladen werden sollen (load) laden und ggf. vorhandene gegen die geladenen ersetzen.

Damit ist dann auch sichergestellt das sich Patches nicht auf die custom erzeugten Tabellen auswirken.

Den rename brauchst du damit eben ein neues "zustand" im ACPI erhältst, du kannst nicht ein vorhandenes sagen wir mal "_OSI" einfach so verändern. Benennst den eben zu "XOSI" und verpasst den einen neuen zustand.

Gruss Coban

Hier ein Link zu Microsoft mit den aktuellen _OSI-Einträgen

_OSI Strings for Windows Operating Systems

In unserem Fall mit OC spielt bei dem vorgehen mit dem SSDT genaugenommen keine rolle welche Version vom Windows angegeben wurde, nach der Übergabe des "wertes" übernimmt das die Windows selber was es zutun hat.

Das mit aktuellem oder verschiedenen versionen vom Windows kommt zu tragen wenn du im Firmware "funktionen oder Werte" bereitstellen willst die halt bsplw. bei Windows 7 anders als bei Windows 10 oder Server Systemen behandelt werden.

Gruss Coban

Quelle: Advanced Configuration and Power Interface (ACPI) Specification (search _OSI)

Hallo miteinander,

ich hänge mich mal hier mit meiner Frage an diesen Thread da es im weitesten Sinne auch mit dem Booten und Windows 10 zu tun hat.

System ist aktuelles Catalina im Dual Boot mit aktuellem Windows 10 auf seperaten SSD.

Bootloader ist Open Core 0.6.2.

Ich denke beide Systeme und OpenCore sind sauber konfiguriert. Beide Betriebssysteme starten sauber und laufen ohnen Probleme oder abstürze flott und stabil.

Nun ist mir unter Windows 10 unter der Systeminformation aufgefallen das unter

Systemhersteller: Acidanthera

Systemmodel: iMacPro 1,1 usw. steht (siehe Anhang)

Frage: Ist dies nur ein tolerierbarer kosmetischer Fehler durch das booten von Windows 10 mit Opencore oder steckt da doch ein größerer Fehler in der Konfiguration von OC dahinter?

Wie kann man das beheben?

_OSI Einträge wären eingefügt..

Wie gesagt läuft alles sauber und stabil und ohne Probleme..., aber nerft trotzdem..

PS: Was haltet ihr von ReFind als Bootmanager vor OpenCore als Bootloader gesetzt, das würde das Problem ja auch beheben..