Search results

USB maps need a different format for Tahoe. And you probably should fix your mapping in Sonoma or Sequoia first to get these front ports working.

[I had to split the post in two parts…] Having identified the human DSL code, we can find the corresponding binary AML by its context in an hex editor (or even use section 20.3 of the ACPI specification to work out the full string of OpCodes for the conditions…) Here is the condition If...

Things are getting more complicated. First, @Edhawk reported that he needed both patches #1 and #1a (in addition to #2 and 3) for his Asus Prime X670E-Pro WiFi. Strange, but still relatively simple. Then @henrikato posted the ACPI tables of his Asus TUF Gaming B850M-Plus WiFi. And in there, I...

Thanks! That's one more in my little collection. And, unfortunately, the plot thickens… Your DSDT has the usual patterns from the general set #1, #2, #3… and then some more. Short version: Here is an extended version of the "general" set with additional patches #4, #5, #6 and #7 for your DSDT...

Strange that you need both #1 and #1a, as they were designed to patch the same declaration, in two alternative binary forms. Maybe Asus has broken this large block of ACPI code in two chunks? Anyway I'm glad the full write-up was useful.

Failing that, you may try the semi-generic patches in this post. "am5_patches" is likely the suitable set and there's an explanation of how you can check against your DSDT.

As far as I know Apple VTd does NOT work with AMD-V but only with Intel VT-d. So the answer is "no".

Have you adapted your USB map for Tahoe? What makes you think you need specific patches for Tahoe or Sequoia? You have not mentioned Sequoia otherwise…

Tahoe uses a different format of USB map than the previous versions, so yours was in need of an update. No idea why USB mapping would affect SATA…

You're already using CaseySJ's patches for PCI enumeration. Your config plist shows property injection for a 5080 GPU which is not supported, and apparently not disabled. Where is the RX 6600 XT? Do you need AMDCPUSupport.kext in the first place?

Browsing through your configuration (keep in mind I'm no expert…) I wonder what the GPRW and PWDE patches are doing, as there's no SSDT which use the renamed functions. Based on the comments, the USB map appears to feature logical HS ports with type 0 and SS ports with type 3 for the same...

OK. At least, I infer that it still boots with my patches. And this has provided two more motherboards to my records, which has eventually prompted me to write a better explanation. Do the patches affect USB behaviour, or other devices? (@Jumper981 reported that he had to modify the RTL812x...

In a further twist, AsRock B650E Steel Legend and X670E PG Lightning have been found to fit the patterns for MSI boards, while AsRock X870E Taichi Lite fits the "general" patterns … which are not so general, and just looking at the manufacturer may not be good enough. Which leaves my "Universal...

You're welcome. So I see you are not using motherboard-specific patches for the conditional device declarations, so you may try my almost-generic patches above ("MSI" version). I don't know if that alone will fix the ghost reboot issue, but it should improve how macOS sees the USB controllers...

@errevi You have posted the ACPI tables but not the EFI folder you're using. In the spirit of the International Journal of Negative Results, even failed SSDTs could be interesting to analyse. Are you using custom ACPI patches, such as those provided on request by CorpGhost? If not, you may try...

Which post? Are you referring to MY patches? :oops: If so, you may try the MSI version from this post (and below) on your AsRock X670E motherboard (patches #1a and #3a looking for the ACPI condition with a mask of three bytes) as an alternative to your set of "AM5 translate" patches, if I...

The problem is that, from reading your document, you're already at "guru" level of technical skills yourself… I notice you first posted in another thread by @errevi involving an AsRock B650E motherboard. Has the issue been reported from other manufacturers? If not, it might not be an AGESA...

Nothing I've seen or read on LiquidGlass has convinced me to try and dip any toe on the 26 family of OS in any Mac, Hack or iDevice… Your bst bet is to reach out to Thunderbolt Master @CaseySJ . But I suspect an IOMMU issue without a solution on AMD.

IORegistryExplorer would show where devices are. If it worked with previous releases, the configuration is fine and it must be that Tahoe has removed non-virtualised access over Thunderbolt. If so the only solutions are (1) revert to Sonoma, (2) make an Intel hack, or (3) get a real Mac.

Assuming that the TitanRidge is at _SB.PCI0.RP21 and everything is correctly configured, your issue could be that macOS wants to address the Thunderbolt device through AppleVTd… which is not available on Ryzentoshes. Was the Octo correctly detected on previous releases of macOS?