Suchergebnisse

Anbei mein EFI für mein Asus Prime X299-Deluxe. Habe nur im "Generic" die MLB/ROM/SystemSerialNumber/SystemUUID entfernt, läuft als iMac Pro. Ansonsten alles wie mit Clover. Derzeit noch im Verbose-Mode, aber mit nativer Monitorauflösung von meinem alten "Apple Cinema HD Display" (16:10), 1920x1200. Also kein grober Text mehr wie in der ersten Variante.

Wobei auch immer interessant ist, wie sich die config.plist ändert, also welche Funktionen dazu kommen.

Nein, ist nicht zwingend.

In der config.plist gibt es unter PlatformInfo bei den SMBIOS Properties den "ProcessorType".Bei mir folgend gesetzt:(Quelltext, 3 Zeilen) Entspricht Hex 0x0F01tata, schon wird aus "unbekannt":Nur Kosmetik, aber schön ist's.

Völlig unnötig diese SSDT. Zumal du das 1:1 schon in deiner DSDT drin hast (Device BUS0 innerhalb von SBUS). Darüber hinaus ist diese SSDT auch so schon merkwürdig. Wozu ist da eine DTGP-Methode eingesetzt, wenn die nirgends aufgerufen wird? Völliger Unfug. Und, benötigst du ein SMBS/SBUS überhaupt? Damit mehr in der PCI-Liste in der Systeminformation steht?

Sascha_77„habe ich hier schon irgendetwas übersehen?“Das ist möglich. Dein Screenshot zeigt nicht alles. Besser wäre die entsprechende Passage per XML hier zu zeigen. Auf jeden Fall gibt es einen Wert innerhalb der ACPI Patches (nur aus dem Gedächtnis, bin im Kurzurlaub), der ist standardmäßig auf „1“ gesetzt und ist ein Zähler. Verantwortlich dafür, wie oft der Patch innerhalb der ACPI oder weiter definierte Table ausgeführt werden soll. Setzt du diesen auf „0“, dann werden sämtliche Treffer e…

Ich dachte, dass du das als „Code“ hier direkt einbindest (die plist liegt ja in einer XML-Struktur vor). Ist bissel umständlich mobil mit iPhone. Egal, es scheint mir „count=0“ zu fehlen. Schaue dir dazu die OpenCore beiliegende plist genau an, zum Beispiel mit einem Texteditor oder besser PlistPro oder Xcode, und lese für die entsprechenden Parameter in der aktuellen Dokumentation (pdf).Grundsätzlich funktioniert das hervorragend, ich nutze das auch.

Die Dokumentation zu Clover ist spärlich, unvollkommen. Das es damit scheinbar besser geht, liegt lediglich an Verbreitung, Community und externen Tools. Clover an sich und pur ist eine Katastrophe. Vergleicht man das lange gewachsene Clover (pur) in Sachen Funktion, Verständlichkeit, Dokumentation und Technologie mit der aktuellen Version 0.4 (!) von OpenCore, steht für mich jetzt schon der klare Gewinner fest. Es ist „Alpha“, nicht vergessen. Sind die Entwicklungen so weit abgeschlossen, dass …

Das nutze ich – "prev-lang:kbd" = "64653A30"

(Zitat von al6042)Einen Teil davon. Der größere Anteil ist direkt in OpenCore gewandert.(Zitat von Erdenwind Inc.)Das ist für Clover. Es ersetzt den Teil, der sonst in OpenCore schon integriert ist. Nur die "FwRuntimeServices.efi" reicht in Clover nicht aus. Beides kann als modernere Alternative die sonst dort verwendeten (verschiedenen) AptioMemoryFixes ersetzen.https://github.com/acidanthera/AptioFixPkghttps://github.com/ReddestDream/OcQuirks

Vermutlich die Grafik im BIOS. Primär PCIe, sekundär nix. IGPU ausschalten, SMBIOS iMacPro1.1 nutzen. Dann sollte das laufen.

mhaeuserWozu wird dieses Sicherheitsrisiko eingebaut, welche Vorteile kann das haben?(Zitat)

(Zitat von Herky85)Einfach hier bei den Entwicklern vorbei schauen: https://github.com/acidanthera/OpenCorePkg/releases

Sascha_77zwar nicht passend zum Fred, aber kannst du mal schauen, warum Clover bei dir seit längerem auf eine ältere Version verharrt und sowohl Build wie auch Nightly Build nicht aktuell anbietet?

Wie sollte man das beantworten? Schau doch rein mit MaciASL.

DerTschnigWie immer, "Configuration.pdf" lesen. Gehört zu "Security Properties", dort zu "BootProtect". Wenn da nix weiter eingestellt ist (None), dann entferne den kompletten Ordner.

mhaeuser(Zitat)Die Funktion finde ich gut, speziell für echte Macs, die man mit anderem SMBIOS laufen lassen möchte. Nur bin ich mir nicht ganz sicher, ob nun "YES" oder "NO", wenn ich möchte, dass eventuelle Firmware-Updates ignoriert werden sollen.Heißt es "JA", ich möchte solche Boot-Optionen ignorieren (lassen)?

ExposeSensitiveData• 0x01 — Expose printable booter path as an UEFI variable.• 0x02 — Expose OpenCore version as an UEFI variable.• 0x04 — Expose OpenCore version in boot picker menu title.• 0x08 — Expose OEM information as a set of UEFI variables.____________________________________________________• 0x0F beziehungsweise 15.Wofür kann man diese Daten dann benutzen?

Sehe ich nicht.Mir ging es auch nicht allgemein um "SensitiveData" (die sind schon lange bekannt und sinnvoll, zum Beispiel liest "Kext Updater" damit die Bootloader-Version aus), sondern speziell um die recht neuen "Expose OEM Information" wie "oem-board" und "oem-vendor".Wen interessieren Angaben wie "ASUSTeK COMPUTER INC." und "PRIME X299-DELUXE"?

Ach guck, nicht gesehen.