Beiträge von MacPeet

Dieser User hatte Sound auf der Kiste, allerdings noch unter BigSur:

https://github.com/jerryhan77/dell-optiplex-7070mff-opencore

Es ist ja oft so, dass die User die alten Kisten dann verkaufen und nicht weiter an der EFI arbeiten, aber man kann die EFI ja auf neueres OC anheben und die Kext's erneuern.

Ich selbst habe meine EFI's bei meinen Hackintosh-Lappi's über viele Versionen erneuert und betreffs Audio hat sich da nie was geändert, höchstens mal neue bootargs oder Kexts, welche für die neue Version nötig waren.

Betreffs usbports.kext oder Audio war dies aber immer gleich.

Er hat hierbei nur HPET.aml verwendet. Die IRQ-Patches für RTC und TIMR sind evtl. auf dieser Kiste gar nicht nötig.

Ferner sind die EFI's für Dell 3070, 8080mmf und 7070m wohl alle ziemlich gleich, wobei man auch Informationen abkupfern könnte.

Die angegebenen Bios-Einstellungen sollte man beachten.

Er hat betreffs Audio ein DeviceProperties mit layoutID 0B gesetzt, was ja 11 entspricht und zusätzlich alcid=11 als boot-arg gesetzt.

Einfach mal die EFI's vergleichen, dann wird es auch mit neueren macOS-Versionen laufen, wenn man die Erkenntnisse aus früheren EFI's entsprechend anwenden kann.

Startsound wird hier eingestellt:

...hat mit dem späteren Sound im System aber nichts zu tun. Es ist ziemlich sicher, dass Du HPET lösen musst und ggf. auch die IRQ-Patches RTC und TIMR, dann wirst Du auch Sound im System bekommen.

Zitat: Aber wie kann es denn sein, dass mit der EFI Hackintosh-OptiPlex-7070-MFF dieser typische Mac Start Ton kommt, und mit meiner EFI nicht? Also muss diese EFI doch wohl Sound haben, oder?!

Weil in Deiner EFI 0x1B eingegeben war und in der EFI Hackintosh-OptiPlex-7070-MFF war es richtig 0x1F,0x3

Wie ich schon oben weiter geschrieben hatte, wenn HPET nicht passt, dann gibt's auch kein Sound unter Hackintosh. War schon immer so. Dann siehst Du auch kein Gerät unter Hackintool/Sound.

In der PCI-Liste ist die Hardware immer zu sehen.

Versuche mal als Variante 1 diese aml einzubinden:

SSDT-HPET.aml.zip

oder als Variante 2 diese aml und IRQ-Patches:

ACPI.zip

Diese Hinweise stammen von Usern auf GitHub, welche für Dein Gerät EFI's für BigSur bis Sonoma gebaut haben und mit LayoutID 11 Audio haben, teilweise wohl auch mit entsprechenden Grafik-Properties-Framebuffer-Eintrag auch HDMI/DP-Audio haben.

"PCIe Devices geht vor boot-arg." Seit wann? War früher immer umgekehrt, alcid=xx hatte immer Vorrang vor PCI-Device-layout-ID-Eintrag.

Ok, danke, dann spielt csr-active-config ja keine Rolle bei Lilu + AppleALC, ich hatte dies nicht mehr genau auf dem Schirm.

Da ich nun schon seit längerer Zeit nur noch mit relaMac's arbeite, noch einen älteren Hackintosh habe und auch nur noch einige unsupported realMac's betreue, bin ich gerade aus der Erinnerung etwas überfragt, ob Lilu + AppleALC mit csr-active-config 00000000, quasi SIP enebled, noch die Rechte hat, die Layout-ID's zur Laufzeit bei Boot ins System zu impfen.

Vielleicht können hier andere User noch diesbezüglich antworten. Ich bin hier nicht ganz sicher. Bei den WLAN-Patches musste SIP immer entsprechend eingestellt werden.

Falls man hier dann auch mal mit csr-active-config 030A0000 versucht, muss man natürlich csr-active-config auch unter nvram/delete eintragen, damit die Änderungen nach Boot auch fruchten.

Ich vermute ganz stark, dass Du die IRQ-Patches brauchst, wie ich es oben beschrieben habe, denn davon ist in der Eli nichts zu sehen und ich gehe davon aus, dass Dein Gerät ein Laptop-Bios hat.

In der config.plist hast Du unter UEFI/Audio auch einen falschen Device-Pfad drin "PciRoot(0x0)/Pci(0x1b,0x0)". 0x1b,0x0 hatten frühere ältere Rechner, Deiner hat Device ""PciRoot(0x0)/Pci(0x1f,0x3)"".

...oder mal Deine aktuelle EFI hier hochladen, dann sehen wir evtl. auch wo es klemmt.

Tatsächlich ist es alc255, denn alc3234 ist ja nur ein Pseudo-Name verschiedener Hersteller.

In AppleALC sind dafür die folgenden ID's speziell für Optiplex konfiguriert, siehe Bild, wobei natürlich auch die anderen ID's für Dell, Acer und weitere Hersteller durchaus Ergebnisse liefern können, weil die ID's oft sehr gleich sind, aber natürlich würde ich mal mit ID 11, 12 und 66 anfangen.

Hierbei ist der Hinweis betreffs boot-arg in der config.plist unter nvram/add/boot-arg ein sehr guter Weg, z.B. alcid=11 oder alcid=12 oder alcid=66 mitgeben, natürlich Lilu.kext und AppleALC.kext in der EFI mitgeben und wichtig, auch in der Reihenfolge.

Natürlich sollte dann in der config unter nvram/delete auch boot-arg gesetzt sein, damit die Änderungen nach Neustart auch wirksam werden können.

Wenn Du mit all diesen Versuchen dann im Hackintool unter Audio noch immer nichts siehst, dann liegt es an der vermutlich verbauten Laptop-Hardware und dem vermutlichem Laptop-Bios.

Alle Laptop's und auch diese Art Mini-Desktop-PC's brauchen den HPET-Patch und die IRQ-Patches für RTC und TIMR, damit Audio unter macOS mit Hackintosh und AppleALC geht.

Hierbei muss IRQ 0 und 8 aus RTC und TIMR gepatcht werden, weil 0 und 8 für HPET konfiguriert werden muss. Hierbei ist das Script ssdttime auf GitHub evtl. Dein Freund.

Ferner kann man auch die Internetsuche "OPTIPILEX 7070 MFF EFI github" bemühen, ob man ggf. eine EFI findet, welche diese Patches schon drin haben.

Hierbei auf spezielle SSDT.aml's oder DSDT-Patches in der config.plist achten!

Ich habe bei der Suche schon einige EFI's gesehen, welche bereits Audio mit dem Gerät hatten, auch wenn die EFI's von Monterey oder BigSur waren, aber wenn's dort ging, dann geht's auch noch weiter mit AppleALC und Audio.

Also einfach mal diese EFI's studieren und Du kannst Dir vermutlich ganz schnell selbst helfen. Info's abkupfern ist keine Schande, haben wir alle schon genutzt.

Kommt scheinbar nicht so ganz an. Hatte ich bereits in Post#6 alles geschrieben. Auf dem realMac braucht man die EFI nicht händisch verschlimmbessern, OCLP macht alles.

Sicherheit liegt doch eher am eigenen Verhalten, oder?

Früher gab es kein SIP in macOS-Versionen und dennoch war das System sicher, sofern nicht ein User irgend einen Blödsinn verzapft hat, was auch heute noch so ist.

SIP hat mit dem eigenen Verhalten nix zu tun und natürlich kann man SIP entsprechend freigeben, so dass gewisse Patches möglich werden. Viele haben den Sinn von SIP nicht wirklich verstanden.

Apple's Hintergrund war betreffs SIP-Einführung damals sicher eher der Hintergrund, dass viele Apple-real-Nutzer, mit vollem Zugriff auf die Systemplatte, wie es ja damals üblich war, sich oft selbst das System zerschossen hatten und Apple einen riesigen Support liefern musste.

Dies haben sie nicht wegen Hackintosh eingeführt, ganz sicher nicht.

Vielleicht nicht der einzige Grund, vielleicht stecken auch noch weitere Aspekte dahinter, aber die Aussage "Ich will SIP nicht brechen", ist oft nicht der richtige Weg in Sachen Hackintosh und Patches für WLAN/BT.

Die Broadcom-Karten funktionieren noch heute mit den aktuellen Patches und dies im vollen Umfang, was die Apple-Services und Airdrop angeht.

Natürlich gehen auch die Intel-Karten, sind dann aber im Universum nicht nativ und brauchen ggf. Zusatzsoftware, z.B. als Ersatz für Airdrop.

Ja, das 13 Zoll aus 2015, laut Deiner Angabe ganz oben, bis macOS Monterey ohnehin nativ.

Für mehr ist OCLP Dein Freund, mehr braucht es nicht.

Zitat von INVESTEGATE

Ja ok versteh. Allerdings sollte man doch trotzdem die KEXTE aktuell halten oder?

Ja, wenn Du einen Hackintosh hast, aber nicht bei Deinem realMac.

apfelnico hat oben schon alles genannt

Höre auf mit anderen Tools an der EFI zu schrauben, wenn es ein realMac ist!

In dem Fall gibt es nur ein Tool, was Du brauchst -> OCLP.

Vor jedem Update, insbesondere wenn Du von macOS Monterey auf Sequoia gehst, OCLP auf neue Release-Version bringen und die EFI mit OCLP erneuern. Danach nochmal den OCLP-Patcher laufen lassen, Reboot etc., erst dann das Update starten, was dann auch gehen sollte.

Nach Boot ins neue System den Patcher wieder ausführen, damit er die nötigen Patches machen kann. Hierbei ist vor dem Patch eine LAN-Verbindung nötig, weil bei dem realMac 2015 WLAN erst nach Patch geht.

OCLP ist auf die unsupported realMac's abgestimmt und dann geht auch alles, aber lass die Finger von dem OC in der EFI. Es ist doch ein realMac oder nicht?

Darf ich hier mal fragen, um welchen Rechner es hier überhaupt geht? Vermutlich um den Lenovo aus der Signatur Post#1, oder?

Falls ja, ist der Grafik-Patch (ID, Framebuffer, etc.) richtig eingebunden? ...diesbezüglich auch ein Hardwarenahes SMBIOS für MacBook (Pro) gewählt?

Je nach Tastatur-Treiber in OpenCore, funktionieren die originalen Tasten FN-Heller/Dunkler? ...liegen beim Hacki ja auch manchmal verschoben.

Ich kenne es von älteren Lenovo's, die ich mal hatte, dass sie nach Updates oder sonstigen Änderungen, gern mal auf unterstete Helligkeit ins System gingen, nach Boot.

Allerdings liefen bei mit die Tasten sauber und bei dem letzten Gerät sogar der Slider in den Display-Einstellungen.

griven

Mit Deiner Aussage komme ich noch nicht so ganz klar. Können diese Tools inzwischen denn wirklich auf die Hardware zugreifen, bzw. die Hintergrundbeleuchtung und somit tatsächlich Auswirkungen auf den Stromverbrauch haben? Ich habe die Sache mit dem HDR hier nicht ganz verstanden. Hast Du da einen Link, für entsprechende Erklärungen?

Ich habe derartige Tools schon damals vermieden und nur im Notfall verwendet, hatte allerdings immer nur den Eindruck, dass der Weiß-Anteil der Farben angehoben wird, mit dem Fazit, dass das Bild natürlich heller war und wirkte, aber auch farbuntreuer und milchig wurde, aber dies war ja im Prinzip nur eine Farbprofil-Änderung und noch keine Erhöhung des Stromverbrauches, oder doch?

Ältere Patcher-Versionen für 15.2 oder 15.3 zu versuchen, macht null Sinn. OCLP 2.2.0 hat offiziell Support für 15.2.

Hast Du mal versucht, die aktuelle Nightly-Version von OCLP zu laden?

Damit die EFI neu erstellen (auf dem echten Mac brauchst Du eigentlich keine Änderungen an den Einstellungen machen).

Nach dem Neustart, sofern Du schon auf 15.2 bist, mit dieser Version die Postinstall-Patches nochmal laufen lassen.

Erst danach dann die Installation von 15.3 versuchen.

Bezüglich der letzten Aussagen bekomme ich dann immer etwas Hals, weil hier in Kleinstadt Glasfaser in Straße, aber noch Kupfer ins Haus und ich für 100000er Leitung genauso viel bezahle, wie jemand (oder mein Kumpel in Berlin) in einer Großstadt, mit 10-facher Leistung.

Sollte nicht so sein, ist aber so. Fair? Absolut nicht.

Obwohl TV nun auch darüber läuft (Kabel-TV beendet) und auch alles Sonstige ohne Probleme, ferner ich damit auch gut zurecht komme, es ist halt ungerecht.

bluebyte hat es hier ja schon angesprochen. Sein Dorf hatte hierbei halt bereits Glück.

Zum eigentlichen Thema in Post#1:

Was willst Du bei Glasfaser mit der alten Fritzbox 7390 noch machen, wenn nicht einmal die Fritz!Box 7590/7590ax und die neue 7690 mit Wifi7 mehr als 300Mbit können?

Hier sollte es doch eher ein neues Gerät werden, wenn man schon so eine fette Leitung bekommt, oder?

Miete oder Kauf ist auch so ein Thema. Ich kaufe nur noch. Früher hatte ich auch Miet-Verträge, wo versprochen wurde, dass diese bei Bedarf kostenlos erneuert werden, was so nie passiert ist.

Dies muss aber jeder für sich selbst entscheiden, bzw. muss man sich dies auf die Laufzeit ausrechnen und dann für sich entscheiden.

Ich habe auch so einen älteren Rechner, wo ursprünglich BT und WLAN getrennt verbaut war. Dort habe ich auch eine DW15xx eingebaut und es gab dann Probleme, weil sich das eingebaute alte BT2.1 immer vordrängelte und das neue BT4.0 nicht gesehen wurde.

Dann habe ich BT im Bios abgeschaltet und siehe da, BT und WLAN von der DW15xx geht auf einmal super, auch mit allen Apple-Funktionen. Natürlich dies mit richtigem USB-Port-Mapping für BT und die richtigen nötigen Kext's für's WLAN. BT im Bios bezieht sich dabei nur auf das originale Device, was ja ohnehin nicht mehr gebraucht wird.

Vielleicht hilft Euch dieser Hinweis ja, ansonsten einfach ignorieren.

Das war 2015 aber sicher eine ganz andere Geschichte.

Bei den neuen Apple Silicon Geräten braucht jede neue interne SSD, auch externe SSD's, wo ein System drauf installiert werden soll, eine spezielle Benutzerfreigabe.

Wobei die OC-Quirks AppleCpuPmCfgLock und AppleXcpmCfgLock stabil arbeiten, so meine Erfahrung mit einigen Rechnern.

Ansonsten wäre im Verbose nach dem berühmten kleinen Block mit Exit Starts bla bla schon Ende.

Ich denke, dass betreffs der mehreren Starts für die Grafik die aktuelle EFI noch andere Baustellen hat, zumal die Möglichkeit besteht, dass nach Bios-Update sich auch Dinge/Pfade betreffs DSDT/SSDT ändern können und evtl. Patches nicht mehr fruchten oder DeviceProperties sich geändert haben.

Da bin ich auch mal gespannt auf erste Berichte.

Ist nur schade, dass man dadurch wohl die Garantie bei Apple bricht, bzw. verliert.

Externe TB-SSD wäre sicher auch eine Option, wenn es um viel Lagerdaten geht, wäre sicher auch günstiger.

Die Einrichtungsgeschichte via DFU-Mode ist jetzt aber auch nicht so schwer, wenn man es erst einmal gemacht und verstanden hat.

Ok, dann berichte mal, wenn alles da ist!

Für Freunde gibt's ja auch in der Regel die Möglichkeit für Gast-WLAN.

Das AppleID-Problem war hausgemacht, sehe ich genauso. Läuft ja nun, schön.

Betreffs versteckte SSID des WLAN's, warum überhaupt?

Tatsächlich gab es auch früher schon Geräte (WLAN-Drucker, etc.), welche dies nicht unbedingt mochten, hab's selbst aber auch lange nicht mehr versucht, da ich früher mit einigen Geräte auf diese Weise auch Probleme hatte.

Die SSID kann man ja "noname" oder "unbekannt0815" nennen, um eine Zuordnung durch die Nachbarn zu vermeiden, was aber eigentlich auch belanglos ist.

Wichtig ist doch nur die ordentliche Sicherung mit PW und WPA3 (WPA2, falls noch nötig).

Wichtiger ist heutzutage eher, dass man das 2,4 und 5 WLAN trennt.

Das Verstecken der SSID kannst Du Dir eigentlich auch sparen, dann bekommst Du auch keine Fehlermeldungen mehr.