Beiträge von hObelware

utopia it seems, there is something not properly set regarding USBX (please upload your ACPI folder from OC)

besides that .. your PCI path to set DeviceProperties must be

PciRoot(0x0)/Pci(0x3,0x1)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)

the (for spoofing mandatory) SSDT-BRG0 has to be edited too, but for that I'd need a IORegistryExlorer save from your running system (kext based)

I usually don't care about benchmark scores at all. Additionally (from what I read) they may vary from OS Version to OS Version ..

Are the scores better when using spoofing? I didn't test that, but I believe there shouldn't be a big difference, since my kext utilizes the very same drivers as spoofing does.

For the time being, I use spoofing, since I ran into VDADecoder issues after upgrading to 13.3 .. my next step will be, to implement the rx 6650 support as driver extension .dext (as intended by apple), maybe that will solve DRM Decoding .. but I'm rather short on spare time right now, so I can't predict, when exactly I will be able to do something about that.

meine Kiste hat gestern auch lange überlegt, bis es weiter ging beim Update (aber es ging schlussendlich weiter) .. aber mit 13.3 is der VDA Decoder tot, mit Spoofing gehts aber alles .. ich geh der Sache nach .. Danke für die Info

hi there, .. yes, I would be best to upload an anonymized config for further investigation .. probably add an ioreg save with active ID Spoofing too

cobanramo .. ja, das sind die Files, die Du beschrieben hast, .. wenn Du dem Verweis CopyObject(/UPC1,UPCP) nachgehst, findest Du die Informationen alle .. am Anfang der SsdtProj

da werden nie 26 ports auftauchen bei kru102, denn lenovo schaltet im bios erstmal alles ab, .. liest das denn keiner

.. außerdem beschränkt sich der adressrahmen auch schon auf max 18 ports, denn ss01 liegt auf 0x0D und nicht auf 0x10, wie bei Desktops üblich ..

ne Ist-Analyse macht hier offensichtlich niemand vorher .. will sagen, was findet macOS eigentlich aus der Firmware vor? .. ohne die originalen ACPI Tabellen zu kennen ist das alles immer nur Stochern im Dunklen .. jajaja, bei Desktopboards ist meist stumpf alles angeschalten, aber auch da lohnt sicht der Blick in die Systemtabellen vorher, abseits vom Ein-/Ausschaltzustand kann man da auch abegfahrene PortPairings ablesen, (zB hs01/02 mit ss05/06 .. wtf gigabyte?) ..

egal, das hier ist ein laptop, und da ist diese Analyse ganz besonders interessant, denn meist (wie auch hier) werden gar nicht alle technisch möglichen Ports befeuert.

be my Guest und schmeiss meine ssdt raus (oem drop dann aber auch raus), und Du wirst sehn, hackintool findet nur noch die ports 01, 02 und 04 jeweils hs und ss …

portmapping ist kein hexenwerk oder sonstiges voodoo, und jeder sollte heutzutage zumindest in Grundzügen Code lesen lernen .. das sollte, wie einfaches Englisch, Allgemeinbildung für jedermann sein, damit man mal von diesem BlackBoxverhalten wegkommt. .. und wer dann den Code der Systemtabellen liest, weiss genau, was anliegt, und was eben nicht ..

mhmm mein Tipp wäre jetzt der Embedded Controller (Device EC), den hat dein Laptop tatsächlich auch als Device EC .. wie man den anpasst, muss ich mich mal belesen .. (Dortania?) .. meine Expertise beschränkt sich nahezu ausschliesslich auf Desktops

sorry, war 2 tage krank im bett ..

meine usb-map fundiert auf der originalen dsdt und dem screenshot von usbtoolbox in windows. die läuft ohne weitere toolbox.kext .. die ssdt von mir bildet die originale von lenovo vollständig ab, nur dass die internal ports 7 und 8 aktiviert sind, lenovo schaltet per bios alles ab, außer port 1, 2 und 4 (jeweils hs und ss) .. normalerweise fluppt das mit der ssdt ganz ohne weitere usbmap.kext

das portmapping greift ja auch, wie man an den screenshots sieht, .. die geschwindigket kann nicht per map definiert werden (soweit mir bekannt), die handeln die devices bei initialisierung aus ..

der hase liegt irgendwo anders im pfeffer ..

gibts mal n hackintool screenshot von usb, wenn bluetooth funktioniert? würde mich interessieren auf welchem port das liegt

oh, .. ich sehe Du räumst auf .. löblich, löblich ..

haste noch n IOReg? und gibts nen bestimmten Grund, warum Du macOS 13.2 beta 2 fährst?

poste nochmal n IOReg und Deine config.plist ..

vorab könntest Du auch erstmal versuchen in der Config bei ACPI->Delete die Daten bei OemTableID zu löschen und nur Length und Signature drin zu lassen

kru102 so, .. (ein) Problem entdeckt. .. wenn Du mal die SSDTs aus origin durchliest, fällt auf, dass Lenovo alle Ports außer 01, 02, und 04 (jeweils HS und SS) als internal/disabled deklariert. Windows ist egal, was im BIOS steht, das initialisiert stumpf alles was möglich wäre, .. unabhängig von der Firmware. macOS tut das aber nicht, weswegen der Port HS07 für Bluetooth in Windows an ist, in macOS aber nicht. Die Webcam (HS08) funktioniert in macOS auch nur, weil dafür ein extra Device angelegt wird .. alles nachzulesen in SSDT-4-ProjSsdt.aml (aus origin.zip)

ERGO: eine USBMap reicht bei Dir nicht aus (und ist im Grunde auch nicht nötig, da dem Controller eh nur 10 Ports zugewiesen sind), Du mußt zudem die OEM Table loswerden, damit die Ports HS07 und HS08 auch initialisiert werden.

das geht folgendermaßen:

in die config.plist muß folgender Eintrag rein: .. der schmeißt die OEM Table raus

allerdings sollte die nicht ersatzlos rausfliegen, da darin noch andere Devices beschrieben werden. Deshalb mußt Du auch noch die angehängte SSDT (SSDT-XHC_SATA) einbinden. Ich hab die mal ACPI konform überarbeitet.

Der Ordung halber, habe ich auch noch die USBMap.kext berichtigt und angehängt.

versuchs mal damit ..

ACHSO .. ich finde es gut, dass Du Deine EFI nochmal neu aufsetzen willst. Ich empfehle DRINGEND die Notwendigkeit all der SSDTs zu verifizieren. Bei der EFI sollte "minimalinvasiv" oberster Anspruch sein. Das Credo "Viel hilft viel" ist total kontraproduktiv und führt ggf. zu schwer nachvollziehbaren Seiteneffekten.

der ioReg Dump is gut, .. für die ACPI Geschichte einfach nen Clover Stick erstellen, der muss überhaupt nicht konfiguriert sein .. in der Clover Boot Auswahl dann F11 oder F4? .. weiss nich genau .. F1 ist die Hilfe, da stehts jedenfalls drin .. und dann speichert Clover unter ACPI/origin Deine DSDT und SSDTs ab .. die zippen und hier hochladen ..

mit den beiden Sachen kann ich Dir ne USBMap schreiben ganz ohne Skripte Voodoo ..

die Treiber der Apple Hardware für Windows finden sich alle im Bootcamp Package .. die für Windows 10 funktionieren bei mir alle auch mit Windows 11 .. allerdings kam es bei mir zu Verbindungsproblemen, da ich die USB Map auch per SSDT gemacht hatte und aus der Anleitung von apfelnico auch die Einstellungen für sein Bluetooth übernommen hatte. Da paßten die Powerzustände aber nicht. .. nachdem ich das wieder rausgeschmissen hatte läuft alles, wie es soll

Bootcamp kann man sich übrigens prima via brigadier (mal bei github suchen) ziehen

ja, 15 (0x1 bis 0xF) pro Controller

also, die 94360ng benötigt bei mir keine Kexts weder bei Monterey, noch bei Ventura .. kru102 hättest Du ggf ein IOReg Dump .. die ACPI Additionen sind sehr variabel angesetzt ..

am besten noch n unmodifiziertes ACPI Dump (DSDT und alle SSDTs) via Clover Bootstick

danke

DerTschnig Wofür hast Du denn all die DeviceProperties für die IGPU drin?,ne Laptop UHD 630? force-online? das haut auf jeden Fall in die RenderPipeline rein .. wenn Du an der IGPU noch ein Display betreiben willst, ist DRM (meines Wissens nach) nicht

drin mit iMac19,1.

bei mir funktioniert es mit folgender Konfiguration:

BIOS: Init Display first -> PCIe, IGPU->enabled (hier: multi monitor support) , DVMT 64 MB

config.plist: DeviceProperties->Add->PciRoot(0x0)/Pci(0x2,0x0), AAPL,AAPL,ig-platform-id: 0x0300913E ... headless halt, sonst nix weiter

Terminal: defaults write com.apple.AppleGVA gvaForceAMDKE -boolean yes

dann sollte es gehen ..

achso: .. hast Du unter PciRoot(0x0)/Pci(0x1b,0x0) noch ein zweites Onboard Audio? ansonsten kann der Eintrag raus

SchmockLord der Treiber ist ja auch der gleiche wie voher .. die Taktung VRAM/GPU wird sowieso vom VBIOS bestimmt.

Unterm Strich ist der Betriebszustand exakt der gleiche, wie vorher, .. nur der Weg dahin ist dynamisch und der DeviceTree bildet die Wirklichkeit ab ..

genau, über IONameMatch, .. entweder ne Kopie des Root Devices mit anderem IONameMatch angeben (für unterschiedliche DeviceProperties) oder aus IONameMatch ein Array machen und für jeden Namenstreffer einen (string) Eintrag für resultierend gleiche Properties.

Im Grunde kannst Du IOClass ACPIProviderMergeProperties (hier die jeweiligen RootDevices) dazu verwenden, an jedes beliebige IOPCIDevice oder IOUSBDevice DeviceProperties zu übergeben, von dem Du den IOName und/oder die DeviceID (IOPCIMatch) kennst, ganz unabhängig vom PCI Pfad .. das läuft vom X6000 Treiber völlig losgelöst. Nur die übrigen IOPersonalities (nicht RootDevices) machen die Treiberanbindung.

Im Detail arbeitet Voight-Kampfs IOClass so, dass sie beim Testen ob die Klasse für das Device instanziert bleiben soll (probe), in der Probe() Routine statt zu Testen, die DeviceProperties schubst und dann immer NULL meldet (für: kann weg). Danach wird die Instanz wieder abgebaut.

wer auf Spoofing angewiesen ist, .. für den ist das Thema vielleicht interessant

Hallo allerseits,

ich stelle hier mal meine Kernel Extension für die eigentlich nicht unterstützten Ausbaustufen von Navi21 (RX 6950 XT und RX 6900 XTXH) und Navi23 (RX 6650 XT) zur Verfügung.

Ein Vorwort

Warum weg vom DeviceID Spoofing? ..

DeviceID Spoofing hat meines Erachtens nach "unsaubere" und sogar "dreckige" Lösungsqualitäten und sollte eigentlich nur als temporärer Workaround in Betracht gezogen werden.

unsauber, weil das GPU-ID Spoofing offensichtlich nicht bis zu letzten (untersten) Ebene greift. Wer mit gespoofter GPU-ID mal im IORegistryExplorer im GFX0 Device den "compatible" Key ansieht, wird dort nur die originale und nicht die gespoofte ID vorfinden. .. Bisher hatte ich zwar noch nie das Problem, daß das relevant wird, .. richtig konsistent ist dieser Zustand aber auch nicht.

dreckig, weil hier Device-unkritisch in die Geräte-/Treiberinstanzierung eingegriffen wird, und mit der Festlegung der DeviceID nach PCI-Pfad alle Geräte in diesem Steckplatz die gleiche DeviceID (und damit den gleichen Teiber) aufgedrückt bekommen, .. ganz egal, was da drin steckt. Die Flexibilität der Hardwarekonfiguration ist damit (zumindest für die Grafikkarte) dahin.

Spätestens wenn man mal - z.B. im Notfall - ne andere Grafikkarte verbauen muß, holt einen das vielleicht wieder ein .. mit Sicherheit aber, wenn das Tauschgerät ne komplett andere Architektur aufweist.

Außerdem finde ich DeviceProperties per config.plist oder SSDT/DSM nur für Geräte angemessen, die man nicht austauschen kann, weil fest aufm Board verbaut (Ethernet, Onboard Audio, etc.) Bei allem, was tauschbar ist, sollte eine dynamische Lösung angestrebt werden ..

Das Ziel

Ein PersonalityProvider, der wie jeder normale Treiber gerätesensitiv die Treiberinstanzen erzeugt, und alle zusätzlichen DeviceProperties on-demand-only als All-In-One Lösung vergibt.

Das Ergebnis

Ursprünglich hatte ich das Projekt nur für die RX 6650 XT umgesetzt, da das Konzept im Grunde aber für jedes Device funktioniert, dass über ID Spoofing läuft (nicht nur Grafik), habe ich diese Kext mal auf alle mir bekannten, zu spoofenden Navi20 erweitert.

Die IOPersonalitiy zu erzeugen ist ja nicht sonderlich kompliziert und bei GitHub habe ich am Wochenende noch eine Lösung gefunden, die DeviceProperties via IOService zu übergeben (vgl. hier). Ich nutze eine leicht abgewandelte Version diese Codes, der Credit hierfür gebührt in jedem Falle Voight-Kampf. .. Danke

Installation/ggf. Anpassungen

Die Kernel Extension muß wie jede andere auch in Kernel->Add eingebunden werden.

Mindestvoraussetzung ist Navi23 Support, also macOS 12.1 ..

Die Bridge SSDT(SSDT-BRG0.aml oder vergleichbares) ist nicht mehr nötig (zumindest hier unter macOS 13.2.1 .. gerne testen und hier Bescheid geben ..) und alle DeviceProperties für die Navi20 .. bei mir: PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0) .. müssen auch weg (wir wollen ja explizit davon weg ).

Unmodifiziert gibt die Kext nur die Properties model (Graka-Name), ATY,FamilyName und ATY,DeviceName (die letzteren für MetalDeviceName) weiter. Ich habe bei model übrigens "AMD" weggelassen, damit bei "über diesen Mac" kein Zweizeiler draus wird, wer will kann das je wieder hinzufügen.

Wenn noch FramebuffersEdits, PowerPlayTables oder ggf. weitere Kosmetika etc. mitgegeben werden sollen, können diese in der info.plist unter IOKitpersonalities->entsprechendes Root Device->IOProviderMergeProperties als Kind-Elemente eingetragen werden.

Achtung!: Hierbei müssen die erwarteten Datentypen passen (meist Data, .. vermute ich) .. am besten vorher mit gespoofter ID mit IORegistryExplorer das Device GFX0 abgleichen. Strings sind z.B. Null-terminated in Mac Roman Encoding zu übergeben (vgl. hier)

fertig .. echter Device Support bei vollständiger Flexibilität!

Zum Testen habe ich hier nur macOS 13.2.1, da funktioniert es mit WhateverGreen /agdpmod=pikera bislang ohne Einschränkungen

EDIT 07.04.23

DRM Decoder funktioniert mit dieser Lösung leider nicht. Das ist mir bedauerlicherweise nicht aufgefallen, da Trailer allgemein funktionieren - HD Content aber nicht .. und damit (inkl. Netflix) beriesele ich mich eigentlich nur übers Apple TV am Fernseher.

Mein Plan ist das Ganze nochmal als .dext (DriverExtension) anzusetzen, so wie Apple das vorsieht. Leider weiss ich noch nicht genau, wann ich Zeit dafür finde und wie das mit den Developerlizenzen dafür aussehen muß, damit das auch überall geht (und nicht nur lokal bei mir).