Driftwood
-
Posts
457 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Events
Downloads
Everything posted by Driftwood
-
Aquantia Problems 12.3 onwards Did anyone try this solution on AMD using IOMMU? DisableIOMapper=false + ForceAquantiaEthernet quirck works on Intel Hacks.. We just need an AMD fix equivalent. Because we are AMD we have to turn on IOMMU in BIOS and IVRS indicates I/O MMU (IOMMU) support A user writes below on insanelyMac: The problem that many people have here is that you can't enable VT-d in UEFI and disable DisableIOMapper on every platform, just like that. For this reason there is this kernel-quirk. This was intended for the fact that one can leave VT-d active in the BIOS, in order to be able to use it at least in another system, because AppleVTD does not run on each system problem-free without making changes at DMAR and dropping the original DMAR table. Unfortunately this was not considered when introducing the ForceAquantiaEthernet quirk and that's why there are now the complaints that e.g. WIFI doesn't work anymore when following the instructions. That the Fenvi T919 did not work in @Rankrotten 's case has nothing to do with the card itself, even a BCM94360NG would not work here. This is due to the bad implementation of VT-d in the firmware of the (older) consumer boards. On server and HEDT platforms it usually works properly. X299 and newer platforms, like Z690 and partly Z590, don't seem to be affected by this problem, but everything before that apparently is. With an AMD hack, you're probably at a complete loss there, as I think enabling AppleVTD will prove much more difficult, if not impossible (maybe a patch can help, but I don't know). AMD's equivalent to Intel's VT-d is AMD Vi / AMD I/O or IOMMU and not SVM - SVM is the equivalent of VT-x. After enabling VT-d in the BIOS of an Intel system and with the DisableIOMapper quirk disabled, you will see AppleVTD quite high up in the IORegistryExplorer (IOService). With AMD systems, it would be now interesting to know whether one can see AppleVTD after the activation of IOMMU in the BIOS likewise in the IORegistryExplorer, which will be however rather not the case, because for AMD systems, IVRS indicates I/O MMU (IOMMU) support and not DMAR
-
@valmeida Send me aqc driver from beta2 if you could as Ive now replaced mine with 12.2.1. Ive got a someone who is going to take a look at repatching it.
-
Perhaps if we update the Aquantia fw/Windows drivers (I know Asrock TRX40 Creator have an updated fw/driver on their site for Windows 11 ), then the Monterey beta 12.3 betas driver may tally up with it and work? Ill try this out over the next few days unless someone wants to do it quickly. I think you can roll back the Aquantia fw update driver to Windows 10 if it fails.
-
Can you try this patch out and see if it works @valmeida on 12.3 beta? Im currently back on 12.2
-
Aquantia still dead even with latest patches on 12.3 beta 2 Failure! And can freeze Monterey requiring reboot. Reduced to using WIFI now with Lucy kext and Monterey Aquantia patch not working! 🙂
-
Hey @tomnic and @fabiosun Can we get this thread a little more organised as to where we are at. ie In your guide you mentioned you are doing are you including 2022 Adobe stuff as well as the old. Im doing a reinstall on Monterey and I see fake intel is no longer required, and other info here and there. Could you update the correct method in the first post of the thread for all to see with dated updates to help? Can you list each app and version into respective sections in the first post, together with patch method and coding required. When you've been away, to read everything again is time consuming 😉 All the best to you guys for the awesome work.
-
The time has come to go to water-cooling after rendering issues in Davinci 🙂 Can anyone recommend thee BEST and for Asrock TRX40 mobo?
-
If any Asrock Creator TRX40 owner requires a clean DSDT (with all external methods/arguments patched correctly) with no Warnings for Asrock's latest fw (Resizeable BAR support) please find attached. There are still (like many DSDTs, non-problematic syntax errors regarding compile (leave them), but it does correctly incorporate all argument variables from SSDT1, SSDT5 & SSDT6. If you want the previous firmware 1.70 cleaned DSDT, simply grab your ACPI files using DEBUG Opencore, run from command prompt 'aisl' in Terminal and enter at the prompt (replacing 'Your path' with the actual path to the aisl command and the path to the SSDTs/DSDT) as follows:- /[Your path]/ iasl -e /[Your path]/SSDT.aml /[Your path]/SSDT5.aml -d /[Your path]/DSDT.aml Note: You only need SSDT.aml and SSDT5.aml to fix 1.70 FW. DSDT_Cleaned_Asrock_TRX40_Creator-ResizableBAR_FW.aml.zip
-
I use the old Aquantia patch (I boot with same Config) in both Big Sur and Monterey - didnt adapt anything since beta 0.75 OC... Also I set up Manual IPv4 DHCP address in Network. IDs:
-
I don't think you can use it! Its supposed to be reserved.
-
@Rocket88 The 18th (port 8 on XHC1), when you do a fresh USBMAp. Its the Reserved port on the Asrock TRX40
-
Shutdown/Restart is easy. All you need (crazily) do in BIOS is Enable 'USB Power Delivery in SoftOff State (S5)' under the ACPI section. As for SLEEP/Wake its been a PITA since upgrading to Big Sur 11.6 and Monterey. Ive rewritten the DSDT (several times), Ive analysed Fabiosun's DSDT (and other boards) against ours and pulled certain WoP variables, edited USB Maps galore, tested with different BIOS settings (one change at a time) and marking them off on a spreadsheet. Still have many variables to try out. Its been an exhausting two weeks of failures. But the same problem exists on other Asrock boards. Asrock Support will not support any requests if they suspect its for MacOS (or Linux). They are total Window heads. I've changed GPRW method arguments 0x08, 0x04s to 0x09s and 0x03s to no avail. Ive combined many ideas with one at a time variable changes... the list goes on. It seems Sleep/Wake is broke atm. The strange thing is fabiosun's Reason for Wake lists the same D0A0 etc... as ours - I can knock them Wake Reasons out easily from my Reasons but you are left with a "/" empty reason which suspiciously means exactly the same reason. Its a private reason. The DSDT is badly designed - and certainly Windows Biased (Sleep/Wake works perfectly in Windows no matter what I throw at it!) Ive disabled XMP Profile 1 and gone stock settings, MAcPro 2993 settings, lots of power related items... but same errors. BTW Every time you change something (if you are to try anything) ensure you NVRAM reset, else you'll see no changes. Ive removed all USBs, PCIe cards, BT/Wifi all to no avail... and yet as I get closer or further to a discovery I keep coming back to this amazing 'chess' problem... I will continue until we nail the variables which are stopping Sleep/Wake. The S5, S4, S3 sleep states erratic to other boards... even on the same devices! I love Asrock 😞 Ive also looked at Rocket88's newly updated USB SSDT and played around with some of the unknown settings zero'ing / disabling, changing port types etc... Its been fun... BTW Rocket88 Port 18 on the XHC0 (original RHUB name) - the Unknown weird port is a type 254 (not 255) Work goes on...
- 3,970 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
With that code sign PS 23 Beta now works @fabiosun
- 154 replies
-
- 1
-
-
- photoshop
- amd adobe fix
- (and 1 more)
-
@tomnic Everything seems to work fine in CSR = 67000000 inc PS Beta 23, PS 21, PS 20, PP Beta 22 (Liquify, Object Select, etc)
-
Camtasia 2019 Error Termination Reason: Namespace CODESIGNING, Code 0x2
-
@tomnic on Camtasia 2019 I get Still getting denied after: Driftwood@Driftwood-Mac-Pro ~ % sudo xattr -rd com.apple.quarantine /Applications/Camtasia\ 2019.app Driftwood@Driftwood-Mac-Pro ~ % /Applications/Camtasia\ 2019.app zsh: permission denied: /Applications/Camtasia 2019.app
-
F*ckin amazing work @tomnic! Well done dude. Thank you so much. Does 2020 version do same?
-
I can report that Photoshop Beta v23 (inc. Liquify etc) working fine on AMD with @tomnic method.
- 154 replies
-
- 2
-
-
-
- photoshop
- amd adobe fix
- (and 1 more)
-
@tomnic Try the latest one. Though. you can go on their site and download older versions: https://www.techsmith.com/download/camtasia/?utm_source=google&utm_medium=cpc&utm_campaign=1537281055&utm_content=56328315102&utm_term=camtasia pc&gclid=EAIaIQobChMIseyUyfTZ8wIVR7TtCh1vFQgyEAAYASACEgI57_D_BwE
-
@tomnic Excellent work! Gonna try this on Photoshop beta 23. Could you take a look at this for Camtasia 2019? (Camtasia 2 mid version works in AMD but ever since Oct 2016 version onwards of Camtasia 2 and upto version 2020 it fails. Here's the Camtasia 2019 lib failure.
-
As well as Monterey Big Sur has been officially updated to the final 11.61! (along with a device Support update) Well we shall see what the Mac Pro is next year... then realise how expensive it will be!
- 3,970 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Searching thru the DSDT Differences in Fabiosun's MSI board to Asrock TRX40 board I found a reference (highlighted in BOLD) in Prepare To Sleep and Wake to Asrock TRX40... interesting.... Do we need: \_SB.PCI0.SBRG.SIO1.SIOS ? Hmmm SIOS (SIO to sleep?) Also the LEDS (Arg0) is not in MSI ? We need to take a look at what the LEDS/LEDW sleep / Wake are doing. MSI TRX40 Method (_PTS, 1, NotSerialized) // _PTS: Prepare To Sleep { If (Arg0) { \_SB.TPM.TPTS (Arg0) MPTS (Arg0, SPTS (Arg0), \_SB.PCI0.NPTS (Arg0)) } } Method (_WAK, 1, NotSerialized) // _WAK: Wake { DBG8 = (Arg0 << 0x04) \_SB.PCI0.NWAK (Arg0) DBG8 = (Arg0 << 0x04) SWAK (Arg0) MWAK (Arg0) Return (WAKP) /* \WAKP */ ASROCk TRX40 Creator Method (_PTS, 1, NotSerialized) // _PTS: Prepare To Sleep { If (Arg0) { LEDS (Arg0) \_SB.TPM.TPTS (Arg0) MPTS (Arg0, SPTS (Arg0), \_SB.PCI0.SBRG.SIO1.SIOS (Arg0), \_SB.PCI0.NPTS (Arg0)) } } Method (_WAK, 1, NotSerialized) // _WAK: Wake { DBG8 = (Arg0 << 0x04) \_SB.PCI0.NWAK (Arg0) \_SB.PCI0.SBRG.SIO1.SIOW (Arg0) DBG8 = (Arg0 << 0x04) SWAK (Arg0) MWAK (Arg0, LEDW (Arg0)) Return (WAKP) /* \WAKP */
-
@Rocket88 @Rox67er & any other Asrock TRX40 Creator users. Please check your OC Bootup screen (either film it when in -v verbose or check your bootleg) for an APCI Boot up error (if you are using the GPWR ACPI ssdt and Patch). If you have one tell me the address for _L08. need to check against mine. We need to find what is stopping Sleep and causing immediate Wake . No Local Variables are initialized for method [_L08] I have a D1B7 device error (like the GPWR ssdt has come unstuck at this address). [\_GPE._L08] (Node ffffff94ec243780) _SB.S0D1.D1B7, 0x02 // Device Wake This is rogue and COULD BE triggering Wake No other _GPE device is listed in my bootlog (verbose boot) Here is the part in DSDT (L08)
-
Tell me if you get an ACPI error on OC boot up just before it goes into Home (OSX Screen)
-
Here is my latest OC 0.75 EFI which rids the Wake reason: D0A1 D0A2 D0A3 D0A4 D0A5 D0A6 D0A7 D0B0 D0B1 D0B2 D0B3 D0B4 D0B5 D0B6 D0B7 D1A0 D1A1 D1A2 D1A3 D1A4 D1A5 D1A6 D1A7 D1B1 D1B2 D error:- However, Im still trying out variables to get Sleep / Wake to work correctly... some intensive dsdt analysis is going on. MMIOWhitelist is for Resize bars bios fw 1.73. This is the most stable EFI yet. DRIFTWOOD ASROCK TRX40 CREATOR EFI.zip Im safely using 8 for boot quirks and -1 for UEFI (disabled)
