welches macOS soll das denn befeuern .. ab Sonoma und höher ist der Umweg über OCLP nötig, da Broadcom Chip .. da gibts gute Anleitungen hier ..
Beiträge von hObelware
-
-
mhaeuser Danke für Dein Dienstprogramm, hab gleich mal meinen M3Pro damit bestückt ..
-
Rissbildung in der hinteren Felge hab ich bei meinem Riese&Müller Load 60 auch .. das erste Mal bei etwa 6500 km (Ryde Andra 40) .. hab mittlerweile bei 17000 km schon die dritte Felge drin 😳 .. zum Glück lief das bislang alles über die Versicherung, aber nervig ist das schon ..
Bei meinem Urban Arrow Family ist nach 15500 km noch alles paletti .. merkwürdig .. aber das UA hat nur nen Perfomance Line Motor, nich Cargo Line (CX mit 550W Spitzenleistung 85 Nm) und keine Federung .. vllt. liegts daran
-
Scanduz maybe you could upload your EFI (as a zip) .. I might take a look
-
before entering what? the screen flashes once when loading the driver .. that is normal
-
i got no experience on booting real macs via OLCP .. lilu.kext has to be present to load nootrx and whatevergreen as they are lilu plugins
-
yes, that would be the correct way .. but nootrx not first! only prior to whatevergreen .. lilu has to be first at any circumstance
-
mitchde .. agdpmod=pikera will simply have no effect at all, if WhateverGreen.kext is not used (because this is implemented there) ..
NootRX.kext implements the same modification to AppleGraphicsDisplayPolicy as WhateverGreen.kext does, but only when iMacPro1,1 SMBIOS is used. if you want to run that, you should need nothing but NootRX.kext.
if you want to run another SMBIOS (e.g. some iMac, which uses IGPU and dGPU, or MacMini) then make sure NootRX.kext is loaded prior to WhateverGreen.kext in config.plist and everthing should work as intended. you run into a dependency problem, as NootRX.kext will not work with several values modified by WhateverGreen, which results in a kernel panic if you load these kexts the other way around. when using WhateverGreen.kext agdpmod=pikera is mandatory as well, as their initiaization process reverts the modification NootRX.kext did to AppleGraphicsDisplayPolicy.
-
na dorr kollaesch, .. ist ja wirklich Jahre her! (meine Telefonnummer ist aber seit 20 Jahren die gleiche)
Mac/Hackintosh betreibe ich als Haupt-/Produktivsystem seit 2011, die Landung ist daher auch schon irgendwo im Erinnerungsnebel verschollen .egal.
Wenn Du Dein Problem mit meiner Kext lösen (naja) konntest: fein!, eine echte Lösung (auch DRM) ist das hier: https://github.com/ChefKissInc/NootRX
Das ist die Treibererweiterung als Lilu PlugIn. Der Einsatz dieser Kext erfolgt, wie bei meiner, ohne DeviceProperties und GFX0 Bridge. Optimal fährst Du damit nen iMacPro1,1 mit Lilu.kext und ohne WhatEverGreen.kext - und damit auch ohne agdpmod=pikera. Damit geht dann grafikseitig alles.
Falls Du auf QuickSync (für Sidecar z.B.) angewiesen bist, und nen iMac als SMBIOS bevorzugt wird, muß WhatEverGreen für die IGPU (mit agdpmod=pikera) nach NootRX in der config geladen werden, sonst gibts ne KernelPanic. Da geht auch alles, wie es soll. Ob mit der Kombi Stabilitätsprobleme auftreten (glaube ich nicht), habe ich nicht mehr genügend lange getestet, da ich mir in der BlackWeek ne RX 6800 günstig geschossen habe. Die RX 6650 XT hab ich wieder verhökert.
Falls Du den Code nicht selber kompilieren willst, findest Du die Builds auch bei GitHub unter Actions->CI als Artefacts.zip
lg
-
zum Thema "Mythos" kann ich anmerken, dass ich irgendwann mal einen Satz Kingston RAM auf meinem 2012er MacBook Pro versucht habe (Specs analog den original verbauten) und der wurde auch erkannt/genutzt, allerdings wollte der aber partout nicht als Dual Channel laufen 🙃
Mit Corsair mit den gleichen Specs hats dann gewuppt.
-
Denke eine AX210 im M2 Format wird sicherlich auch easy laufen.
leider nein .. CNVi Slots sind nicht voll beschalten, da laufen nur CNVi Karten
-
du kannst einen der beiden nvme m2 slots mit der Broadcom belegen .. brauchst dann aber nen adapter der usb (am internern header) mit verkabeln kann ..
-
auch gut recherchiert .. das ASUS Handbuch hält sich hierzu bedeckt
alles andere als CNVi hätte mich aber auch gewundert .. ist ja (leider) standard heute
-
sofern deine intel m2 karte keine wifi6e ax210 ist, wird das nichts .. alle anderen intel modelle sind cnvi .. möglicherweise gibts im bios ne option cnvi für den wifi m2 port zu deaktivieren?
und: OOB mit broadcom und sonoma wird sowieso nichts, das läuft meines wissens nach immer auf OCLP hinaus.
dieser cnvi krempel hat mich bisher auch davon abgehalten was aktuelleres als z370 chipsätze als itx board zu benutzen. das sind die letzten mit vollwertigen pci-e/usb m2 wifi slots, wenn man 2 nvme disks verwenden will .. 🙄
-
nope .. it is not that easy. you have to port the kext to a dext (driver extension), which has to be signed.
and then MAYBE DRM will work .. but thats a capital maybe (as writren 😉)
-
ich sehe Du hast keine Unterstützung von AppleVTD, .. vielleicht ist das für Sonoma nötig ..
die Polaris sollte ja eigentlich laufen ..
kannst Du mal die info.plist aus S/L/E/AMD9500Controller.kext von Sonoma hochladen? .. ich hab keine derartige Installation
-
nein .. Navi22 wird vom Apple Treiber (bislang) nicht unterstützt.
.. dazu wird es wohl auch nicht mehr kommen, da es auf der Basis keine "Pro"- (Workstation-) Karten gibt.
-
nein, bislang liegt das Projekt auf Eis, da ich Sonoma vermutlich nicht mehr betreiben werde und für DRM auch schon unter Ventura keine praktikable Lösung in Sicht ist, außer ich ließe die kext von Apple selbst signieren (was sicher nicht passieren wird) .. sorry
Wer sich daran weiter versuchen will, kann dem github Link zu voight kampf in Post 1 folgen. Ich habe im Grunde genau diese Funktionalität benutzt, um die DeviceProperties zu schubsen (.. ich hab zusätzlich noch versucht die Strings der Properties als OSData zu casten, damit man „Klartext“ weiterreichen kann .. leider erfolglos .. OSDynamicCast greift nicht und OSRequiredCast führt zu schweren Abstürzen beim Booten).
Die eigentliche „Leistung“ der kext ist die Zuweisung der diversen Treiberklassen an die Geräte, das läuft alles in der info.plist ab und ist eigentlich ein simpler Injektor. (Wer das lesen kann, wird es auch als solches erkennen.)
Für DRM sieht der Forschungsstand meinerseits so aus, dass der DRM VDADecoder keine unsignierten Caller akzeptiert. Ne Möglichkeit wäre das Konzept ggf. als *.dext statt als *.kext aufzusetzen (mal im Apple DriverKit stöbern), da greifen möglicherweise die Apple Signaturen der originalen Treiberklassen, dann haperts aber vermutlich mit der Initialisierung durch OpenCore.
knock yourselves out .., zum Weiterbasteln reicht die info.plist, mein Programmcode entspricht dem oben genannten, meiner heißt erstmal nur anders, (meine Erweiterungen sind in meiner angehängten kext aus Stabilitätsgründen bislang nicht „scharf“ geschalten)
-
bevor wir hier mit umschlagenden Veränderungen anfangen .. laut dem Screenshot ist BT aber nicht von einer Fenvi T919 .. hast Du zwei Karten da drin?
da steht klar intel Jefferson Peak, bei PCI auch als en2 (intel Canon Lake PCH CNVi) .. schmeiß die mal raus, oder disable die via BIOS, dann sehen wir weiter ..
bei den USB Port muss auch aufgeräumt werden, aber das hatte KungfuMarek ja schon gesagt.
Hab dir hier mal die EFI hochgeladen
Hab übrigens diesen Guide verwendet inkl. BIOS Settings und CO
https://github.com/seven-of-el…signare-z390-opencore-efi -
die RX580 2048SP ist keine RX580 sondern eine aufgebohrte RX570 .. die Device ID wird nicht wird nicht von whatsevergreen erkannt und die VBIOS Version sieht sicher aus wie xxx-xxx .. das alles mag macOS gar nicht, OOB läuft die in jedem Falle nicht. ggf. kannst Du es mit GPU-ID Spoofing versuchen, kann aber durchaus sein, dass die Hardwarebeschleunigung an der VBIOS Geschichte scheitert ..
ich hatte schon mal so einen Fall hier im Forum
lies den Thread mal durch