Das MacPro7,1 SMBios hat für dein System keinerlei Vorteile eher Nachteile während du vom iMacPro SMBios profitierst.
Wenn du meinst es besser zu wissen bitte, viel Erfolg, dann verbrate ich hier meine Zeit nicht weiter.
10.15.4 + Clover 5109 auf MSI X99A 5820K I Trotz Umfassenden EFI ist Installation von OSX Nicht Möglich I Probleme mit boot.efi
-
- In Arbeit
- Jumanji
- Erledigt
-
-
Also irgendwie verstehst du nicht wovon ich rede, ich habe von Amerco ausser das das SMBios falsch gewählt ist und das reichlich Fehler in der Konfiguration sind nichts weiter gesagt.
Du beklagst dich über die Wahl des SMBIOS und ich habe es dir einfach mal erklärt das ein MacPro7,1 SMBIOS mit deinem System nichts gemeinsam hat.
Das passendste SMBIOS wäre eigentlich sogar eher ein MacPro6,1 für dich, iMacPro1,1 habe ich dir aber gewählt weil man es dennoch gut für dein Setup aufgrund deiner Hardware nutzen kann.
Das SMBIOS gibt dir keine "höhere Kombinierbarkeit" das ist Schwachsinn, sorry aber wenn ich sowas lese wird mir schlecht.
Ich kann dir an meinem MacPro7,1 Hack der nun mal wirklich auch auf der MacPro7,1 Platform basiert auch ein MacMini8,1 SMBIOS hinterlegen
und trotzdem werde ich immer noch 2 GPUs und Erweiterungskarten drin haben und oben drauf 192 GB RAM.
Macht zwar gar keinen Sinn und würde mir bei einem C621 Chipsatz Sockel 3647 eher Nachteile bringen aber machen kann ich es dennoch.
Der Folder den du da in den Spoiler gepackt hast, hat keinerlei Auswirkung und ist die Original ACPI Table die Amerco extrahiert hat. (Origin Folder)
Die Verändert am System absolut gar nichts, alles was eingeladen wird in Bezug auf SSDTs würde/liegt unter patched.
Memory Modules Misconfigured Meldung kommt daher, dass ein SMBIOS genutzt wird, was soviel mit dem genutztem System gemeinsam hat wie ein Restaurant mit nem WC.
Für macOS ist es nicht schwierig zu erkennen das keine 12 RAM Bänke vorhanden bzw der RAM nicht korrekt verbaut ist.
Wie dem auch sei, ich hab echt besseres zu tun! Viel Erfolg und eine Gute Nacht!
PS: Die Fehlermeldung die du kriegst erinnert mich eher daran wenn Leute ein Legacy System fahren, dass ist die einzige Situation wo ich ähnliches gesehen habe.
-
Ehm. Falls meine Config nicht richtig sein sollte, dass war nur als start und Hilfe gedacht zum probieren und testen.
Mit den "alten" Kexts in meiner Config läuft alles stabil auf meinem System, Sleep, USBs, Wlan, Bluetooth, CPU mit fast allen States
Also ich kann mich nicht beklagen, dass etwas überhaupt nicht läuft.
-
Funktioniert es denn mit der EFI von DSM2 bei Dir Jumanji das ist doch unterm Strich und letztendlich der ausschlaggebende Faktor und nicht ob es bei Amerco geht oder nicht geht. Jedes System ist individuell und anders so macht es zum Beispiel ganz und gar keinen Sinn ein ASUS Board mit einem MSI Board zu vergleichen. Bei beiden gibt es zum Beispiel unter anderem gravierende Unterschiede in der Firmware und in der Art und Weise wie diese die MemoryMap organisieren. Diese Unterschiede beeinflussen unter anderem ob ein AptioFix funktioniert oder eben auch nicht. Das es hier in beiden Fällen mit dem alten AptioFix2 funktioniert ist Zufall sofern es sich dabei überhaupt um die offizielle Variante handelt und nicht um den OsxAptioFix2Drv-free2000 der in solchen Fällen nämlich gerne genommen wird. Um den free2000 sollte man, wo immer das möglich ist, einen ganz großen Bogen machen denn der geht mit der Holzhammer Methode vor und überschreibt einfach ohne Sinn und Verstand alles was ihm in die Quere kommt egal ob es noch benötigt wird oder nicht.
Der Ansatz den DSM2 verfolgt macht in jeder Hinsicht Sinn denn mit OCQuirks und FWRuntimeServices kommt hier die wohl am weitesten Entwickelte Variante aller Fixes zum Einsatz und die lässt sich nicht nur umfangreich konfigurieren sondern bietet auch einige andere Vorteile die keiner der genannten Fixe bietet inklusive der Möglichkeit automatisiert Slide Werte an macOS zu übergeben die auch wirklich nutzbar sind. Also Jumanji tu Dir und uns den Gefallen und probier einfach aus was man Dir sagt bzw. zur Verfügung stellt insbesondere deshalb weil Du in DSM2 jemanden hast der sich mit der X Generation unter macOS auskennt wie kaum ein anderer. Einen besseren, versierteren Helfer als ihn wirst Du nicht finden wenn es um diese Plattformen geht.
-
Aber funktioniert es denn auch mit den neuen AptioFixen?
Statt Aptio2 = OcQuirks.efi + FWRuntimeService.efi
Kann mit den DSM2 EFI gebootet werden, bei Beitrag #33 schau mal, ob es bei dir startet?
Mit der angegebenen Efi aus #33 konnte ich das System nicht starten.
Meine Config + OcQuirks.efi + FWRuntimeService.efi als Aptio Ersatz -> Boot geht.
Ich bin hier raus, da ich kein Experte fürs Patching bin. Die Config ist da und wie genau was gepatched werden muss, da hoffe ich können andere weiterhelfen.
-
Wie gesagt Amerco man kann das halt nicht wirklich vergleichen und gerade bei den Fixes gibt es auch keine Individuellen Lösungen weil das zum einen von Board zu Board anders ist und zum anderen auch von der eingesetzten sonstigen Hardware abhängt und nicht zuletzt auch von Bios Version zu Bios Version unterschiedlich sein kann.
Mein Post war auch ganz und gar nicht gegen Dich gerichtet ganz im Gegenteil Du hast Dein System im Griff und die Tatsache das Du mit Deiner individuellen OCQuirks Config booten kannst zeigt ja auch das Du mit einigem Sachverstand an die Sache gehst also alles gut
Mir ging und geht es dabei mehr darum das hier (mal wieder) zig Ansätze angefordert, angefragt und vermischt werden ohne mal konsequent eine Schiene zu verfolgen. Natürlich kannst Du nichts dafür und Dir macht auch niemand einen Vorwurf denn letztlich wolltest Du nur helfen und sonst nichts also bitte nicht falsch verstehen.
-
-
Jumanji Zum Booten macht es keinen Unterschied ob MacPro6,1/MacPro7,1/iMacPro1,1 als SMBios festgelegt.
Was anders läuft sieht man unter der Haube und selbst das nicht in allen Punkten. Als Laie wirst du da gar keinen Unterschied sehen!
ACPI Einträge machen nur dann Sinn, wenn das Board damit überhaupt etwas anfangen kann und das überprüft man indem man die ACPI Extrahiert.
Sprich in Clover F4 Taste drücken und Clover hinterlegt die Vollständige ACPI in den Origin Folder.
Dann schaut man in die DSDT um zu sehen wie das ganze überhaupt aufgebaut ist und was vorhanden ist oder eben auch nicht.
Man hinterlegt nicht einfach irgendwas wild und blind ohne überhaupt geprüft zu haben was Sache ist.
Von diesem "Speziellen" Aptio sollte man die Finger lassen und man kann diesen auch durchaus umgehen auch ohne OcQuirks und OpenRuntime.efi (hieß früher FWRuntimeService.efi).
Wenn man auf OcQuirks und OpenRuntime.efi setzt dann wird man aber wohl nicht ohne zusätzliche Settings für OpenRuntime.efi voran kommen.
Auch mit AptioMemoryFix kann man solche Boards grundsätzlich zum laufen bringen, die Konfiguration innerhalb der Plist sieht dann aber auch von Mainboard zu Mainboard anders aus.
Der "Fehler" den ich gemacht habe ist der Slide=0 Value, den ich in der Config.plist drin gelassen habe und alles weitere hätte man per Plist für OpenRuntime.efi (früher bekannt als FWRuntimeService.efi) festlegen müssen.
Der hat aber mit deinem boot.efi problem nichts zu tun und kann von mir von hier aus auch nicht wirklich nachvollzogen werden...
Was ich nicht verstehe ist das du jetzt einen anderen Fehler listest und vorher sagtest das du den boot.efi hattest mit meiner EFI, was den nun davon ?
Die OpenRuntime/OcQuirks kommt ja nicht von irgendwo daher sondern direkt von Github, falls du "nur" den Fehler mit Incompatible siehst, dann kann man ja auch den Step auf die Vorversion machen und dort die Quirks anpassen wenn nötig.
Tue mir bitte einen gefallen und lass meine Erwähnung in Bezug auf deine EFI... Von einer Korrektur meinerseits kann da keine Rede sein wenn die EFI so aussieht...
Schönen Tag noch...
PS:
Amerco No Front! Hab deine EFI erst heute morgen in Originalform gesehen, wusste nicht was alles noch von Jumanji hinterlegt wurde vorher.
Du hast zwar auch in der Original Version einiges an Optimierungsbedarf aber naja... bei Zeiten gehe ich mal drüber.
Ahja und bitte hinterleg alle Kexte in deiner EFI und nicht nur FakeSMC und den rest im System, den dort haben sie wirklich nichts verloren.
-
Nein, nein und nochmals nein!
Alles was Du im Clover Configurator eintragen kannst bzgl. des SMBIOS hat keinerlei Einfluss auf Dein Problem denn der Fehler tritt bereits auf bevor das SMBISO von macOS überhaupt erkannt/verarbeitet wird. Bitte bitte mach Dich erstmal schlau bevor Du weiter wild in der Weltgeschichte herumspekulierst. Die Stichworte auf die es ankommt (Sorry ich habe aktuell nicht die Zeit das genau zu erklären da auf der Arbeit) sind Kernel Adress Space Layer Randomization, MemoryMap und die Funktion der Aptio Firmware als solcher. Das Problem hat nichts aber auch rein gar nichts mit dem RAM in Deinem Rechner zu tun oder damit wie der an macOS weitergegeben wird. Die unterschielichen AptioFixe (AptioMemoryFix, OSXAptioFix, FWRuntimeServices inkl. OCQuirks) arbeiten im Tanzbereich der Firmware also irgendwo zwischen Ende initialisierung des Rechners durch das UEFI und Start des Betriebssystems durch den Bootloader. Im Falle von macOS will die boot.efi (der Bootloader von macOS) den Betriebsystemkern (Kernel) gerne an einen zusammenhängenden Speicherbereich unterhalb der 4GB Grenze entpacken und von dort starten und genau das schlägt in Deinem Fall fehl.
Zum Verständnis die Firmware des Rechners (UEFI/BIOS) schreibt beim initialisieren des Rechners Informationen zu der im Rechner vorhandenen Hardware in den Speicher das sind in erster Linie Informationen darüber unter welchen Adressen welche Geräte erreichbar sind usw. die Menge der Informationen schwankt mit der Menge der verfügbaren PCI Lanes (daher sind X Serie Boards auch öfter von dem Problem bertoffen als Z Serie Boards) und mit der Menge der verbauten Steckkarten denn je mehr Steckkarten ums so mehr landet auch im Speicher. Die Firmware geht dabei mehr oder weniger verschwenderisch mit den Ressourcen um denn ausser für macOS ist es nicht sonderlich wichtig das im Bereich unterhalb von 4GB möglichst unfragmentierter freier Speicher verfügbar ist (und Windows Board sollen bekanntlich auch kein macOS booten). Die diversen Memoryfixe nehmen sich nun diesen Problems an indem sie analysieren wie der Speicher belegt ist und versuchen die Fragmentierung des Speichers aufzulösen (um zu erklären wie das genau funktioniert fehlt mir zum einen die Zeit und zum anderen auch das Verständnis das können andere sicher besser als ich spielt hier aber auch nur eine untergeordnete Rolle). Je nach Generation des Fixes gelingt das mehr oder weniger gut. Der AptioMemoryFix und die FWRuntimeServices (quasi der "Nachfolger" des Memoryfixes) haben hier die ausgefeiltesten Strategien auf Lager und können weit mehr als "nur" Speicheradressen virtuell umbiegen die einfachen Fixes beschränken sich auf das umbiegen der Adressen. Du siehst also das alles hat nix mit dem SMBIOS oder dem RAM im Rechner zu tun sondern eben damit wie die Firmware mit den gegebenen Ressourcen umgeht und genau deshalb macht es auch keinen Sinn ASUS mit MSI Mainboards zu vergleichen denn das ist so als vergleiche man Äpfel mit Birnen. Schlimmer noch es kann sein das ein und das selbe Mainboard bei User A läuft und bei User B ums verrecken nicht was dann unter anderem daran liegen kann das beide unterschiedlich viele Erweiterungskarten einsetzen oder eben einfach auch nur andere Karten verwenden (verschiedene Grafikkarten etc.).
Jetzt noch ein paar Worte zum Slide Wert und was der eigentlich macht. Wie ich eingangs schon schrieb solltest Du Dich mal schlau machen was eigentlich gemeint ist wenn von KASLR die Rede ist denn der Slide Wert steht damit im direkten Zusammenhang. Gültige Werte für Slide sind Ganzzahl Werte zwischen 1 und 256 wobei der Wert bei jedem Start des Systems per Zufallsgenerator ausgewürfelt wird. Dieser Wert gibt einen Versatz ein sogenanntes Offset an von dem ausgehend die Bootloader versucht den Kernel im Speicher zu installieren. Ein Beispiel der Slide Wert 0 würde dazu führen das ausgehend von der Startadresse 0x0000000000 ein Offset von 0 hinzuaddiert würde sprich boot.efi würde versuchen den Kernel an der Basisadresse zu installieren und wirft einen Fehler aus wenn das nicht erfolgreich ist sowas in der Art:
Gibt man keinen Slide Wert vor dann wird bei jedem Start ein anderer verwendet und es kann sein das dabei zufällig einer getroffen wird der zu einem ausreichend großen freien Bereich passt und das System durchbootet (passiert ja Bei Dir zuweilen auch siehe Dein Screenshot 2 -> Übrigens keine MemoryPanic sondern vermutlich eher wegbrechender USB Support aber das ist ein anderes Thema). So nun habe ich mehr geschrieben und Zeit investiert als ich eigentlich gerade habe aber vielleicht hilft Dir das das richtige Verständnis für die Sache zu entwickeln und an den richtigen Stellen zu schrauben (-> OCQuirks -> OcQuirks.plist und hier insbesondere die Punkte DevirtualiseMmio, AvoidRuntimeDefrag, ProvideCustomSlide und SetupVirtualMap )...
-
...
PS:
Amerco No Front! Hab deine EFI erst heute morgen in Originalform gesehen, wusste nicht was alles noch von Jumanji hinterlegt wurde vorher.
Du hast zwar auch in der Original Version einiges an Optimierungsbedarf aber naja... bei Zeiten gehe ich mal drüber.
Ahja und bitte hinterleg alle Kexte in deiner EFI und nicht nur FakeSMC und den rest im System, den dort haben sie wirklich nichts verloren.
ehrlich gesagt war das schon alles an Kexts die ich aktuell nutze. Ich hab keine in /Library/Extensions etc. installiert. Einzig für Wlan habe ich die "IO80211Family.kext" mit "AirPortAtheros40.kext"(editierte <IONameMatch>) erweitert. Habs nicht hinbekommen das über Clover zu lösen. Vielleicht kannst du mir in Zukunft mal helfen auf OpenCore mit aktuellen Kexts zu switchen
-
