Asrock Z77E-ITX Ozmosis-Clover

    Bootet durch aber immer noch Buildin=0

    Produktivsystem: Mainboard: Gigabyte Z77N-WIFI Ozmosis 1494 CPU: Intel Xeon 1230v2 RAM: 16GB Grafikkarte: AMD HD 6850 1GB


    Spielsystem: Mainboard: Asus Sabertooth 990FX Rev 2.0 CPU: AMD FX8350@4,7GHZ Ram: 8GB Grafikkarte: AMD R9 290@Raijintek Morpheus

    Ja, hier auch ohne builtin.


    Weiterhin geht im Vergleich zum DB-Bios auch kein DSDT LOSES Audio mehr.
    Dh im ersten Bios war zumindest die Audioseite gepatcht gewesen.
    Jetzt kann ich wenigstens definitiv sagen, dass das DSDt im EFI wird bei mir nicht geladen wird. ;-)


    Das oder es ins Bios zu integrieren bringt uns wohl weiter ... aber wie ?

    Das gleiche hier ;-)

    Produktivsystem: Mainboard: Gigabyte Z77N-WIFI Ozmosis 1494 CPU: Intel Xeon 1230v2 RAM: 16GB Grafikkarte: AMD HD 6850 1GB


    Spielsystem: Mainboard: Asus Sabertooth 990FX Rev 2.0 CPU: AMD FX8350@4,7GHZ Ram: 8GB Grafikkarte: AMD R9 290@Raijintek Morpheus

    Wie schon geschrieben in dem DB BIOS ist der HDAEnabler.kext als HDAEnabler.ffs drin enthalten ;) Das war mal die Ersten versuche.


    Der DSDT patch von Pjalm bzw. selbst nur der Teil der für das Lan zuständig ist passt wenn ich es in die DSDT einfüge nicht wieder ins Bios.
    Das Tool Dsdt2Bios verweigert in der aktuellen Version auch seinen dienst und gibt beim zusammen führen Fehler Meldung aus. Nicht mit einer älteren version experimentieren das führt zum Brick des Modthermoards (das war der Grund für das Update auf die jetzige Version 0.4.10)


    Bleibt also im Moment nur die EFI Partition...


    Sieht man ja an der bdmesg Ausgabe


    04:916 00:000 Base Directory Path :\Efi\Quo\:
    04:944 00:027 Local Path :\Efi\Quo\Darwin\:
    04:944 00:000 Common Kexts Path :\Efi\Quo\Darwin\Extensions\:
    04:945 00:000 ACPI Dump Path :\Efi\Quo\Acpi\Dump:
    04:945 00:000 ACPI Load Path :\Efi\Quo\Acpi\Load:


    ....normaler weise sollte er die von dort laden. ?(

    bei mir sieht es etwas anders aus


    02:642 00:000 Base Directory Path :\Efi\Quo:
    02:662 00:020 Local Path :\Efi\QuoDarwin\:
    02:662 00:000 Common Kexts Path :\Efi\QuoDarwin\Extensions\:
    02:663 00:001 ACPI Dump Path :\Efi\QuoAcpi\Dump:
    02:663 00:000 ACPI Load Path :\Efi\QuoAcpi\Load:


    siehe auch Screenshot. Habe es an beiden Stellen schon probiert, kein Erfolg.
    Werde jetzt eine komplette Neuinstallation durchführen und dann mal sehen, was auf der EFI dann zu sehen ist.


    Frage, ihr verwendet Ozmosis 828m und nicht 894m. Gibt es dafür eine Grund ?
    894m soll laut changelog automatisch die BaseBoardSerial auf 17 Stellen auffüllen und noch andere kosmetische Veränderungen haben.
    Löst aber unser Problem wohl nicht ;-)


    Edit
    Frage 2
    Siehst du bei deinem Board in der bdmesg irgendwas, das er die DSDT und die KEXT auch lädt ?


    Edit 2
    Keine Änderung nach kompletter Neuinstallation :|


    Die Ordner waren beim ersten boot
    02:642 00:000 Base Directory Path :\Efi\Quo:
    02:662 00:020 Local Path :\Efi\Quo\Darwin\:
    02:662 00:000 Common Kexts Path :\Efi\Quo\Darwin\Extensions\:
    02:663 00:001 ACPI Dump Path :\Efi\Quo\Acpi\Dump:
    02:663 00:000 ACPI Load Path :\Efi\Quo\Acpi\Load:


    nach dem reboot
    02:642 00:000 Base Directory Path :\Efi\Quo:
    02:662 00:020 Local Path :\Efi\QuoDarwin\:
    02:662 00:000 Common Kexts Path :\Efi\QuoDarwin\Extensions\:
    02:663 00:001 ACPI Dump Path :\Efi\QuoAcpi\Dump:
    02:663 00:000 ACPI Load Path :\Efi\QuoAcpi\Load:


    merkwürdig ?(

    894m ist ein Thema für sich...bringt mehr Probleme als es nutzen bring.


    Sieht nach dem Reboot irgendwie komisch bei dir aus...stehe da nun auch auf dem schlauch...

    Ich habe mal nach ähnlichen Problemen gegoogled, bei dem einzigen Ergebnis was ich gefunden habe, lag der Fehler darin, das von einen anderen Partition gebootet wurde, als die auf der das EFI lag.
    Da ich nur eine SSD im Rechner (mit den drei Partitionen für EFI, Rescue OSX und der eigentlichen OSX) habe, sollte dies ausscheiden.


    Der 16 GB BootUSB Stick hat zwei Partitionen, einmal die Installationspartition und eine Datenpartition, welche alle für das Projekt nötigen oder unnötigen Dateien enthält.


    Was mich wundert, ist das die Installation bei mir in drei statt zwei steps abläuft.
    1. Standard boot, Vorbereiten der Partition und Installation, welcher 8 Minuten anzeigt. Nach dem automatischen Reboot bleibt der Bildschirm schwarz, und nix passiert.
    2. Nach einem Reset bootet er erneut vom Usb-Stick und setzt die Installation fort. Diesmal veranschlagt er dafür 24 Minuten !
    3. Wenn das durch ist, bootet er nach Abstecken des USB-Sticks in die endgültige Konfiguration durch und alles ist wie gewohnt.


    Da ich bei meinem MBP 5,1 mit welchem ich produktiv arbeite, lediglich upgrade, aber schon lange nicht mehr neuinstalliert habe, kann ich nicht sagen, ob dies standardmäßig auch so ist.


    Ich werde jetzt das Ganze mal mit Clover versuchen, und berichte in wie weit der LAntreiber dort korrekt eingebunden wird.


    Wenn Jemand noch ne Idee hat, woran das mit dem Nicht-laden der DSDT im EFI zu tun haben könnte, wäre ich sehr dankbar !

    Also die 2 Stufen sind beim echten Mac auch vorhanden, beim ersten SSD/Festplatte einrichten und Recovery Partition erstellen, beim 2 dann die eigentliche Installation des OSX.

    So, mit Clover läuft alles wie geschmiert ....


    Bedeutet für mich, wenn wir klären könnten, wie man die DSDT aus dem EFI unter Ozmosis bei diesem Board lädt, würde es dort auch klappen.


    Edit.
    Kurze Erläuterung falls Jemand weiter versuchen möchte, diese Board mit dem integrierten Lan-Adapter unter Ozmosis zum Laufen zu bringen. Mit einem von einer von Apple direkt erkannten PCIe-LANkarte sollte es auch direkt mit dem Bios in der Ozmosis-DB funktionieren.


    Um den Test mit dem letzten BIOS (no 5) von Thomaso66 oder der DB-BIOS fortzuführen habe ich die "DSDT + AppleBCM5701Ethernet.kext.zip" angefügt. Diese enthält eine gepatchte DSDT und den Treiber für die integrierte Karte BCM 57781 mit der Vendor ID (14E4,16B1).
    Die AppleBCM5701Ethernet.kext muss in der IONetworkingFamily.kext ausgetauscht werden. Minimal sieht es dann so wie im Screenshot "IONetworkingFamily BCM57781 minimal kext" aus.


    Ein herzliches Dankeschön geht an Thomaso66 für die unermüdliche Hilfe auch zu später Stunde !
    :danke:

    --------


    Alternativ (und das ist der Weg, welcher für mich funktioniert) ist das Ganze via Clover aufzusetzen.
    Ich bin dabei der Beschreibung einer englischsprachigen Seite gefolgt - Suchwort ist "how-install-os-x-mavericks-using-clover". Installation von clover klappt im legacy modus.


    Im Screenshot "EFI Clover USB Stick" ist zu sehen was wo einfügt bzw. wegzulassen ist.
    DSDT und LAN Treiber sind dabei identisch zu der oben beschrieben Ozmosis Lösung.


    Nach der Installation sind lediglich die markierten Dateien im Screenshot " EFI Boot Disk" nötig. Der LANtreiber wird in der bestehenden IONetworkingFamily.kext ausgetauscht. Alternativ kann man die Family.kext auch ins EFI VERSCHIEBEN, durch das nötige bundling in der Familiy.kext ergeben sich aber andere Probleme.


    Nun noch die Einträge via Multibeast hinzugefügt (in 6.3 gibt es keine Unterscheidung mehr zwischen DSDT und nonDSDT)
    und alle Komponenten funktionieren.


    Beim Upgrade ist wie immer zu prüfen, was mit gepatched werden muss, aber das Ganze ist wesentlich einfacher als mit dem Chamäleon gelöst.


    Hoffe die "Alternative" hilft Jemandem weiter, der das wirklich schöne kleine Board einsetzen möchte.

    Ozmosis und Clover sind sich ähnlicher als man vielleicht denkt. Ähnlich, wie auch Clover ist es unter Ozmosis möglich eine bearbeitete DSDT nachzuladen ohne diese in das Bios einbauen zu müssen. Das Ganze funktioniert eigentlich ganz genau so, wie bei Clover. Ozmosis legt in der EFI Partition der Bootplatte eine eigene Verzeichnisstruktur an, die man genau so bestücken kann, wie bei Clover auch ;)

    Code
    1. Efi
    2. -APPLE
    3. -Quo
    4. ->Acpi
    5. ->Dump
    6. ->Load
    7. ->dsdt.aml
    8. -Darwin
    9. ->Extensions
    10. ->Common
    Haswell, Notebook

    Spontan habe ich keine Idee warum die DSDT bei Dir von dort nicht geladen wird. Ich selber habe das hier so im Einsatz und die DSDT wird ohne weiteres maulen und murren geladen. Wie ist die EFI Partition bei Dir formatiert, meine ist im FAT Format und das scheint wichtig zu sein, damit sie von Ozmosis gelesen werden kann.

    Haswell, Notebook

    Jepp hier ebenso.


    Ich habe extra eine Neuinstallation angestoßen, dabei dann auch die gesamte Platte incl Efi bei der Installation neu parttioniert.


    Ergebnis siehst du im Post 46.


    Das Merkwürdige ist auch, dass sich die Ordnerstruktur an der er die Daten versucht zu laden, nach dem ersten reboot verändert.


    Vorher hatte auch Nimrod859 auch festgestellt, dass bei ihm die DSDT nicht geladen wird. siehe post 27 ff.


    Kannst du in deiner bdmesg erkennen das er tatsächlich die DSDT berücksichtigt ?

    Dem bdmesg kann man es nicht klar entnehmen ob die DSDT geladen wird oder nicht, es gibt lediglich eine Info über die Pfade

    Code
    1. 02:074 00:038 Found Storage PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0x0)/HD(1,GPT,70DE9778-E075-4CBE-A796-7F2CD8824FD3,0x28,0x64000)
    2. 02:074 00:000 Base Directory Path :\Efi\Quo\:
    3. 02:077 00:002 Local Path :\Efi\Quo\Darwin\:
    4. 02:077 00:000 Common Kexts Path :\Efi\Quo\Darwin\Extensions\:
    5. 02:077 00:000 ACPI Dump Path :\Efi\Quo\Acpi\Dump\:
    6. 02:077 00:000 ACPI Load Path :\Efi\Quo\Acpi\Load\:

    ich kann aber dennoch mit 100% Sicherheit sagen, dass meine DSDT geladen wird, denn

    und genau das übergehe ich in der dsdt, da die Baboon Personality den DVI Port meiner Karte nicht unterstützt. In der DSDT hab ich also Eulemur als Frambuffer eingepatched und genau das funktioniert auch

    Mit DSDT im Verzeichnis = Bild über DVI und erkannt als Eulemur, ohne kein Bild über DVI und per HDMI=>DVI als Baboon von daher gehe ich fest davon aus, dass die DSDT geladen und berücksichtigt wird.

    Haswell, Notebook

    Gibt es vielleicht irgendeine BIOS-Einstellung, oder ein fehlender Treiber im Ozmosis-Bios, der das Laden beeinflusst ?


    Gibt es bei dir auch die "verkürzte" Ordnerstruktur ? siehe Screenshot Post 46
    \Efi\Quo\Acpi\Load: <-> \Efi\QuoAcpi\Load:

    Die gibt es bei mir nicht, die Ordner sind 1:1 so, wie im bdmesg angegeben sprich die Struktur auf der Platte entspricht genau der Struktur, die auch von bdmesg angegeben wird. Im Bios selbst habe ich keine besonderen Einstellungen vorgenommen sprich nur das Übliche (AHCI, VT-D usw). Als Besonderheit gibt es die EFI Partition bei mir 2 mal (FusionDrive) also auf beiden Platten des Fusion Verbunds aber das sollte eigentlich keine Rolle spielen, wenn man kein Fusion oder sonstigen Raid Verbund einsetzt.

    Haswell, Notebook

    scheint bei Asrock-Boards wohl nicht so gut zu funktionieren wie bei Gigabyte.
    DSDT2BIOS klappte ja auch nicht.


    Clover ist zwar ne ausreichende Alternative für mich, aber es reizt mich schon es doch hin zu bekommen ...

    Hehe, ja kenne ich ;)
    Mir geht das aktuell mit dem PowerNap so. Ich kann zwar die DSDT entsprechend patchen und dann PowerNap auch aktivieren allerdings ist mein Rechner dann der Ansicht er wäre ein 486er ( 800Mhz Takt und das egal wie hoch die Last ist). Klar, man braucht das Feature nicht wirklich aber es kratzt einen schon, wenn es bei anderen funktioniert und auf der eigenen Kiste eben nicht.

    Haswell, Notebook

    Hi,


    Danke für die Mühen Schneider! Und natürlich allen anderen auch! Ich werde mal versuchen es mit Clover zu installieren auch wenn ich es noch nie gemacht habe. Bei mir wird allerdings keine rescue Partition angelegt egal ob Fusion Drive oder einzelne SSD. Ich hoffe ihr werdet mich weiter Supporten. Denn Clover kann für mich noch eine haarige Angelegenheit werden. Ich möchte die Maschine halt gerne produktiv als meine Photoshop Station einsetzen ;-)

    Produktivsystem: Mainboard: Gigabyte Z77N-WIFI Ozmosis 1494 CPU: Intel Xeon 1230v2 RAM: 16GB Grafikkarte: AMD HD 6850 1GB


    Spielsystem: Mainboard: Asus Sabertooth 990FX Rev 2.0 CPU: AMD FX8350@4,7GHZ Ram: 8GB Grafikkarte: AMD R9 290@Raijintek Morpheus