etorix

I see the same conditions as in just every AM5 DSDT that was posted here, and every set of patches provided by CorpNews. Here is a generic version of these three patches which should do for your motherboard… and many others, I hope. am5_patches.plist.zip

@sdmkx Have you tried the OpenCore patches from @corpghost, which @fabiosun has reposted multiple times in this thread? If it works, it is a much better way to do it—and if it doesn't work, we'll investigate why.

@Jaidy Maybe open a dedicated thread and post your EFI and SysReport from the WRX90 system?

or even non-Pro. But 2 DIMMs per channels, so reduced speed (and probably best to keep to the RAM QVL). In the event that either of you had a free week-end to tinker while the WRX90 machine is at rest, you might give a try at hackintoshing it (with hyper-threading disabled for the 7985WX, and a compatible AMD GPU). It should not be that different from a TRX50.

And, if I'm not mistaken, no one has ever hacked EPYC (3000/5000/7000/8000/9000, not 4000, which I would expect to be a given). On the Intel side of things, it seems that X299 "had quite a few people", but looks like a niche rather than a "popular" playground, while C422 has a handful of faithful users (which is a pity, as I find these systems to generally be a breeze to hack…), C621 even less and we may be down to two or three users with C621A hacks; no one has yet cracked W790 or C741. You commend some respect for willing to address such requirements on a Hackintosh rather than jumping to Linux like everybody else… But I submit that for this amount of RAM you should look straight at WRX90 (Threadripper Pro 7000WX) and its 8 RAM channels (up to 2 TB) rather than at TRX50 and its mere 4 channels (1 TB). (If you're willing to go for older DDR4 systems, dual Xeon Scalable can take up to 4 TB RAM with 3DS LRDIMM or Optane DCPMM.)

Please define "popular" in this context… The need for high RAM and/or many PCIe lanes are also addressed by Xeon Scalable/Xeon W-3000, some of which are natively supported by macOS, and which do not raise issues about application compatibility, contrary to Ryzen/Threadripper. I would not say that C621(A) hacks are "popular" by any reasonable acception of the term: We are a handful with these.

I did it by hand. To simplify, I begin by temporarily commenting out the Operation CPVS declaration, so that all further references to its objects show up as errors and then track them one by one: Find one, jump to the corresponding object in the tree in MaciASL left panel, go to the next object to find the closing bracket, delete it, go back to the opening section and complete the deletion, check, rinse and repeat. It's somewhat tedious, and not made easier by the many warnings produced when recompiling the base DSDT. (AMD ACPI tables are an awful mess compared with those from Intel systems.) The new inner conditional statements are worse, as they can be quite long, which makes it difficult to find the closing bracket. But it's maybe not necessary to remove these. Anyway, if the patches by @corpghost keep working these are a much, much, better way to go forward.

@kosmos Here are two patched DSDT you may try. The first one follows strictly the method in the first post; 'patched2' then further removes conditional statements on G002 and G001 inside declarations. @Lorys89, please have a look into this. patched.zip

Have you tried ACPI patches in OpenCore instead? This is getting naughty, as I now see conditional statements inside declarations, in addition to conditionational statements wrapping full declarations.

On AM5, security updates in BIOS also brought some breaking changes in DSDT; maybe similar issues are at play here? Have you tried to compare ACPI tables from the older and nwer BIOS, or re-checked memory whitelisting?

There's a non-escaped space in the application path. Do not type paths! Use shell autocompletion (<TAB> key). Something like /A<TAB>Au<TAB>A<TAB>A<TAB> should give the correct syntax ( AutoCAD\ 2022 ). Or wrap the path in quotes.

My proposal: DSDT_patched.aml.zip

"Custom" is your key to disabling Secure Boot. PS. In my experience with Xeons, serial ports are no issue at all. macOS is happy to boot with them, and to display "Serial" among networking possibilities. (I haven't dug up my 33.6k modem to check whether they actually work.)

Do we know what this field is, and what are the expected values for those G0xx? Not all conditions can be met simultaneously (G000): If (((G002 != 0x03) && (G000 == One))) { Scope (\_SB.PCI0.GPP7) { Device (UP00) { If (((G002 != 0x03) && (G000 == 0x02))) { Scope (\_SB.PCI0.GPP7) { Device (XH00) so deleting all the conditions create more ACPI objects than would exist if CPVS were properly processed. Possibly more worryingly, there is some debug-like code (calls to M460) and empty stubs If (((G002 != 0x03) && ((G000 == One) && (G002 == 0x04)))){} so there's a risk that the code will further evolve in future BIOS revisions. Maintaing a database of patched DSDTs for successive BIOS versions of boards of interest is going to be cumbersome.

More fundamentally, I wonder why this extra code prevents macOS from booting. Is macOS unable to read the CPVS region and initialise these G0xx variables? Is it a general issue with macOS? A memory mapping issue? An AMD-specific issue?