Help installing Mojave on Xeon W-2175 and Asus WS C422 mobo

[yapan4]

In my case the situation is a bit better, because I have the ability to install macOS on a previous BIOS, then the BIOS was updated. So i have installed on SSD verified fully working macOS Catalina 10.15.4b1.

After BIOS update some kernel patches stop working. Only old bootstrap_patch remained for run kernel and boot macOS.

Without any modifications i got runing kernel and then stop on PCI Configuration end error in verbose mode.

X299 users have the same problem and say it has to do with the PCIe distribution.

 

I have some progress after using old DSDT.aml in /Clover/ACPI/patched. This allow bot in single user mode and skip PCI Configuration end error.

Edited February 11, 2020 by yapan4

[skyflying5]

On 2/10/2020 at 6:10 AM, yapan4 said:

Hi, @skyflying5

I see you reacted to nmano in "KernelAndKextPatches 10.13x,10.14.x,10.15.x X99" topic. Do this mean that you has success boot b1 with latest kernel patches? 

 

sorry I still stay at 10.15.3.

 

My OC config still cannot boot， I've tried so many versions，but every version i tried only got 

00:000 00:000 OCB: Failed to match a default boot option

this in debug file.

 

Can U fig out for me . THX！

Edited February 12, 2020 by skyflying5

[obus]

5 hours ago, skyflying5 said:

 

sorry I still stay at 10.15.3.

 

My OC config still cannot boot， I've tried so many versions，but every version i tried only got 

00:000 00:000 OCB: Failed to match a default boot option

this in debug file.

 

Can U fig out for me . THX！

Can you download your EFI (without serial)

[skyflying5]

41 minutes ago, obus said:

Can you download your EFI (without serial)

without serial skyflying5-oc0.5.6.zip

 

thx!!

[obus]

59 minutes ago, skyflying5 said:

without serial skyflying5-oc0.5.6.zip

 

thx!!

Your config.plist is not the nicest I've seen so I think you need to sit down and read the documents carefully again.

Mandatory is to fill in MaxKernel and MinKernel under every added kext  "Kernel --> Add".

You should use HfsPlus.efi instead of VBoxHfs.efi otherwise you can't boot to recovery.

Normally you just need ApfsDriverLoader.efi,FwRuntimeServices.efi,HfsPlus.efi and VirtualSmc.efi to boot.

 

Try this EFI  (just put in your serial first)

skyflying5-oc0.zip

Edited February 12, 2020 by obus

[yapan4]

On 2/12/2020 at 11:18 AM, skyflying5 said:

 

sorry I still stay at 10.15.3.

 

My OC config still cannot boot， I've tried so many versions，but every version i tried only got 

00:000 00:000 OCB: Failed to match a default boot option

this in debug file.

 

Can U fig out for me . THX！

Sorry, i'm still on Clover... but nothing changed 10.15.4beta1 vs 10.15.3 except you need new xcpm_pkg_scope_msrs kernel patch from here

https://www.insanelymac.com/forum/topic/335650-kernelandkextpatches-1013x1014x1015x-x99/?do=findComment&comment=2707701

Edited February 13, 2020 by yapan4

[metacollin]

On 2/11/2020 at 12:32 PM, yapan4 said:

In my case the situation is a bit better, because I have the ability to install macOS on a previous BIOS, then the BIOS was updated. So i have installed on SSD verified fully working macOS Catalina 10.15.4b1.

After BIOS update some kernel patches stop working. Only old bootstrap_patch remained for run kernel and boot macOS.

Without any modifications i got runing kernel and then stop on PCI Configuration end error in verbose mode.

X299 users have the same problem and say it has to do with the PCIe distribution.

 

I have some progress after using old DSDT.aml in /Clover/ACPI/patched. This allow bot in single user mode and skip PCI Configuration end error.

This is excellent information @yapan4, thank you.  And I believe that this is exactly what is happening to me as well.  I think the same problem and it seems to effect C620 series chipsets as well. 
 

I got the boot flags set to do the most ridiculously verbose boot I know how to do without having kextlog=0xffff set (-v debug=0x14e io=0xff smc=0xff keepsyms=1) and this revealed that the boot was hanging during AML device configuration but so early that it hadn’t even gotten to the first PCI bridge yet, so PCI Configuration Begin never even got printed.  But the specific phase of the boot process that it was hanging is the same as the one where PCI Configuration Begin gets printed, mine is just happening a little earlier and obscuring this. 

I think whatever is causing it just gets executed earlier during the X11DAi-N hardware enumeration/configuration (PCI configuration begin is where a good bit of the AML code - DSDT + SSDTs - gets executed) but its probably the same problem. 
 

Anyway, it turns out the USB thing was just a red herring.

 

But I did scrape/download the contents of Supermicro’s entire SFTP server (since Supermicro is apparently a fairly bitchy and unreasonable company when it comes to just giving customers older versions of firmware, I figure I might as well grab whatever I can).  Lots of random {censored} but I managed to find some older BIOSes for several X11 series motherboards, including mine.  
 

I was running version 3.2 of my bios, but I found version 3.0c and flashed that, set all my bios settings how I thought would be most conducive to booting macOS, and I would note that the settings were identical to what I had set when using 3.2.

 

macOS got passed the spot that it never had, even once, using the 3.2 bios.  In fact, it never crashed.  
 

It never booted either though hahaha.  Made it as far as waiting for root device though, so now it’s probably some USB problem (I’m booting off of an SD card plugged into a fairly questionable usb to SD card dongle because I managed to lose all my thumb drives apparently).  I already tried all the standard stuff (different ports, turning xhci handoff on, using the port limit patch and usbinjectall, trying the usb related Releasefirmware OC quirk (I don’t remember the name, it’s the only one that begins with Release though).  None of that worked.  I think the problem may be the sketchy SD card dongle I dunno.  

 

I’m probably just going manually set up a catlina installed on a hard drive instead.  
 

I digress.  Anyone using a X11DAi-N (looking at you @eritius), do not use the latest BIOS, it won’t boot. 

 

@yapan4, it sounds like this problem might be fixable with the right DSDT and/or SSDT fixes.  I’m looking into this now.

[yapan4]

@metacollin

I tried to get the help of ACPI experts on this forum, even creating a topic in the appropriate theme. But there was no response so finally I deleted the topic.

 

Since in my case the CPU is still SkyLake, I allowed myself to experiment with the old DSDT I wrote about above. Of course, this is not a solution, but it may clarify something. 

 

I do not think the problem is so serious because my system with this config boot ok in single user mode(-s) or goes all verbose mode (-v) as usual, but does not show the desktop and just keep in text mode. The system simply bypasses the place when video drivers should load and prolongs the boot in verbose mode. Finally keyboard work as usual, for example sound +/-, print screen, launch applications, etc, all actions are performed ...but in background.

The impression is that the system knows nothing about the video card or PCIe connector it is in. 

 

Please let me know if my Google-translated text is unreadable.

 

P.S. @obus and all ASUS WS C422 Pro/SE users: I don't find "Primary Display"  switcher's in BIOS v.3003 for using ASpeed AC2500 video as Primary...

 

Edited February 16, 2020 by yapan4

[metacollin]

I think I found what may be the problem, not sure yet though.

 

The BIOSes that present problems all have their _DSM methods accepting 3 Arguments.  This is a violation of the ACPI 6.2 spec, maybe they added it in the 6.3 one, I am not sure.  _DSM should always accept 4 arguments. 

 

I can see why it happened.  Many of the _DSM methods simply called PCID, which also accepted those same 4 arguments, but only used the first 3.  In more recent BIOS versions, PCID was shortened to use just the 3 arguments it needed, and at some point, for some reason, all the _DSM methods were shortened to 3 arguments as well.  For example, in v1202 of your BIOS, the DSDT tables have a 4 argument _DSM.  In the most recent one, it has been shortened to 3.  Maybe it is nothing, but it IS a violation of the ACPI spec and macOS typically does not handle those well.  A relatively simple patch could fix it though, if that is even the problem. 

[yapan4]

I understand nothing in AML, so if you can make this fix i'm ready for test.

 

For comparison Darwin Dump for original MacPro7,1 

 

Add: By users report - New BIOS 3006 for some X299 MoBo - any changes, still non functional MSR Lock and not bootable hackintosh.

MacPro7,1.zip

Edited February 17, 2020 by yapan4

[obus]

On 2/16/2020 at 8:55 PM, yapan4 said:

I do not think the problem is so serious because my system with this config boot ok in single user mode(-s) or goes all verbose mode (-v) as usual, but does not show the desktop and just keep in text mode. The system simply bypasses the place when video drivers should load and prolongs the boot in verbose mode. Finally keyboard work as usual, for example sound +/-, print screen, launch applications, etc, all actions are performed ...but in background.

The impression is that the system knows nothing about the video card or PCIe connector it is in. 

 

 

 

Sorry if I'am a little bit confused but are you saying that you actually can boot (in to black screen) in verbose mode with 3003 bios?

And if so have you checked if you can connect remotely from another Mac or Pc?

 

Edited February 17, 2020 by obus

[yapan4]

14 hours ago, obus said:

Sorry if I'am a little bit confused but are you saying that you actually can boot (in to black screen) in verbose mode with 3003 bios?

Yes, with OEM v.1202 DSDT.aml in /EFI/Clover/ACPI/patched (dumped by Clover F4 button) my system with v.3003 has more no stop during boot, verbose mode run as usual but just ignore load video drivers and macOS GUI at all and remained in text mode.

 

14 hours ago, obus said:

And if so have you checked if you can connect remotely from another Mac or Pc?

I'm trying remote control over IPMI, no success because one more "surprise" in v.3003 from ASUS - not available BOOT -> Primary Display option.

 

PrimaryDisplay1202.BMP

 

Also i can try do Apple Remote Desktop in v.1202 and then flash v.3003 and try connect. 
I will be try also different DSDT files.
Also I notice reinit process for video card in Windows during first boot after BIOS update, so something changed in CPU PCIe subsystem. PCIe x1 Video Card can help if connect it in PCH PCIe slot. Onboard ASpeed video is such but...

 

I will experimentalize...

Edited February 18, 2020 by yapan4

[obus]

10 hours ago, yapan4 said:

Also I notice reinit process for video card in Windows during first boot after BIOS update, so something changed in CPU PCIe subsystem. PCIe x1 

 

Are you running Mac Pro7,1 SMBIO:s? And if so is it the same behaviour with iMac Pro1,1 SMBIO:s?

Edited February 18, 2020 by obus

[yapan4]

Last time I test only MacPro7,1 SMBIOS. Now I'm not sure, probably past times I tested with iMacPro1,1 SMBIOS and was different behaviour during boot kernel, different kernel_patches or so on... sorry, i do not remember...

Edited February 18, 2020 by yapan4

[obus]

5 minutes ago, yapan4 said:

Last time I test only MacPro7,1 SMBIOS. Now I'm not sure, probably past times I tested with iMacPro1,1 SMBIOS and was different behaviour during boot kernel, different kernel_patches or so on... sorry, i do not remember...

Ok. I will test myself a little bit more. I'm still having a discussion with ASUS about the Bios 3003 and the locked MSR 0xE2 register. I still think this could be the culprit at least in our case. 

[yapan4]

I agree, it's important.

I now again in v.1202, if you in v.3003 check please Primary Display option, if also unavailable then it's second major bug from ASUS in this BIOS.

[obus]

1 minute ago, yapan4 said:

I agree, it's important.

I now again in v.1202, if you in v.3003 check please Primary Display option, if also unavailable then it's second major bug from ASUS in this BIOS.

I will test the 1202 DSDT in OC 0.5.5 with 3003 bios now.

[yapan4]

6 minutes ago, obus said:

I will test the 1202 DSDT in OC 0.5.5 with 3003 bios now.

Don't forget just one patch of the kernel is working for me in Clover in v.3003 and MP7,1: 

xcpm_bootstrap © Pike R. Alpha

8D43C43C 227722

8D435E3C 227722

[yapan4]

... and connect VGA Display(if you have) to onboard ASpeed video.

 

If you have problems with OC, then you can use my Clover EFI

EFI.zip

Edited February 19, 2020 by yapan4

[metacollin]

There seems to be some confusion I think about clover patches and OpenCore.  

 

OpenCore implements all the necessary XCPM patches already, but in a more generalized way so you don't ever need to worry about specific patches for specific OS/kernel versions, or even specific versions of that patch for a specific family of CPUs.  OpenCore dynamically looks at the kernel that you're about to boot, as well as the CPU (or in some cases, the emulated CPUID if present) and correctly patches the kernel automatically.  

 

Your kernel patch section, except in very rare and specific cases, should be empty with OpenCore.  If you have any xcpm patches, remove them, you do not need them.  If you have any USB port limit patches, remove them, you do not need them. If you have any storage, AHCI, SSD, NVMe patches, remove them, you do not need them! I do not know of a single patch that one needs to add manually to clover that isn't done automatically for you in OpenCore, as long as you turn on the right thing.  Simply put, if you have kernel patches in your OpenCore config, you're not using OpenCore correctly and it even if you manage to get it to boot, such a configuration will be extremely fragile and could stop working after even small changes to your system or macOS.

 

Instead of any USB port limit patches, turn on the XhciPortLimit quirk in the kernel section.  This will dynamically patch any kernel, past, present, and future by dynamically determining the correct patch by looking at the actual kernel in question.  

 

Instead of any of the xcpm patches, turn on the AppleXcpmCfgLock quirk in the kernel section.  This will apply all the different xcpm patches you need for your cpu and the specific kernel version you're booting dynamically.  Specifically, it prevents any writes to the 0xE2 MSR, so if yours is locked, you need this checked to boot.  If you have any xcpm related kernel patches, these will almost certainly interfere with OpenCore's far more robust and effective automated patching algorithm.  

 

In some cases, if your motherboard also locks the 0x1AA MSR, the misc power management register, you will need to enable the AppleXcpmExtraMsrs quirk.  This will dynamically patch any version of macOS to disable writes to this register as well.  To boot, I need both of these turned on as my BIOS locks both of these registers unfortunately.  I am working on a patch for my bios but we'll see if it works.  I cannot find the second option that @eritiusfound in his version of the bios.  The name he said it was called does not exist anywhere in v3.0c of the same motherboard's BIOS.  

 

Even PMHeart's xcpm performance patch, notoriously dependent on both CPU generation and kernel version, can be automatically applied for any architecture on any kernel version by turning on the AppleXcpmForceBoost quirk in open core.  Just be warned, your room is probably going to get pretty warm if you use that one :). 

 

Even non-xcpm power mangement is covered.  Need to patch writes to 0xE2 in AppleIntelCpuPowerManagement.kext?  Turn on the AppleCpuPmCfgLock quirk.  Want to disable it entirely, ala NullCpuPowermanagement?  Turn on the DummyPowerManagement quirk.  

 

This is why I am using OpenCore over Clover, because it is becoming too difficult to get the right combinations of patches for the right CPU architecture and for the right version of MacOS, and by using OpenCore, one does not need to worry about kernel patches at all.  OpenCore can figure out the patches for you, removing the need for primitive find/replace patches which are fragile, kernel and/or cpu specific, and easily broken.  

 

 

Secondly, it is not mandatory to fill in Min/Max kernel at all for kexts.  In fact, leave them empty.  All they do is make it harder to know which kexts are enabled and which aren't.  If you don't want to use a kext, then don't enable it.  If you do, then enable it.  It's that simple.  I have these fields empty and have always had them empty and it causes no problems.

 

 

Do not drop power management tables.  Skylake and Cascade lake are both natively supported by xcpm and HWP.  Dropping CPU power management tables just breaks power management on these platforms and potentially will prevent you from booting.  You had to do this on haswell and broadwell.  Do not do it on newer architectures.  

 

Do not use a UsbKeyboard EFI driver while also having Key Support turned on.  Choose one way to fix something, I cannot drive this point home enough.  Enabling multiple fixes for the same thing almost always will mean you can't boot.  Why would you turn on Key Support when you already have a EFI driver that... surprise... adds key support?  

 

Do not use a display level above 64 (0x40) unless your intention is to completely halt your CPU on any error for remote debugger purposes.  

 

You WILL need to use a SSDT to inject plugin-type = 1 property on your first CPU for working XCPM.  There are ready made SSDTs easily found for this.  Make sure it makes the ACPI path for your CPU, which is usually SB.PC00.CP00 on these platforms instead of SB.PCI0 etc.

 

Unless you're on broadwell or haswell, do not use a fake CPUID.  And beyond that, it will not work unless you have the correct CPUID mask as well.  And the CPUID is not the same as in clover.  Regardless, you probably don't need it unless you're on a non-natively supported architecture, which for anything recent, is limited to broadwell and haswell.  Anyone with a C620, X299, or C422 chipset should have CPUID1 and CPUID1Mask completely blank.  

 

I've attached a fixed OC config for skyflying.  It might not get you booting, but it definitely won't make things worse.  Also, not sure what that excel spread sheet is doing in your ACPI.  You need to copy and paste the output of the spreadsheet into Device Properties, along with several other things just like in Clover.  But don't worry about that now, the Radeon VII (same card as I have) works fine without any of that.  Worry about overclocking later when things are working :).  

skyflying5_oc_fixed.zip

Edited February 21, 2020 by metacollin

[skyflying5]

18 hours ago, metacollin said:

There seems to be some confusion I think about clover patches and OpenCore.  

 

OpenCore implements all the necessary XCPM patches already, but in a more generalized way so you don't ever need to worry about specific patches for specific OS/kernel versions, or even specific versions of that patch for a specific family of CPUs.  OpenCore dynamically looks at the kernel that you're about to boot, as well as the CPU (or in some cases, the emulated CPUID if present) and correctly patches the kernel automatically.  

 

Your kernel patch section, except in very rare and specific cases, should be empty with OpenCore.  If you have any xcpm patches, remove them, you do not need them.  If you have any USB port limit patches, remove them, you do not need them. If you have any storage, AHCI, SSD, NVMe patches, remove them, you do not need them! I do not know of a single patch that one needs to add manually to clover that isn't done automatically for you in OpenCore, as long as you turn on the right thing.  Simply put, if you have kernel patches in your OpenCore config, you're not using OpenCore correctly and it even if you manage to get it to boot, such a configuration will be extremely fragile and could stop working after even small changes to your system or macOS.

 

Instead of any USB port limit patches, turn on the XhciPortLimit quirk in the kernel section.  This will dynamically patch any kernel, past, present, and future by dynamically determining the correct patch by looking at the actual kernel in question.  

 

Instead of any of the xcpm patches, turn on the AppleXcpmCfgLock quirk in the kernel section.  This will apply all the different xcpm patches you need for your cpu and the specific kernel version you're booting dynamically.  Specifically, it prevents any writes to the 0xE2 MSR, so if yours is locked, you need this checked to boot.  If you have any xcpm related kernel patches, these will almost certainly interfere with OpenCore's far more robust and effective automated patching algorithm.  

 

In some cases, if your motherboard also locks the 0x1AA MSR, the misc power management register, you will need to enable the AppleXcpmExtraMsrs quirk.  This will dynamically patch any version of macOS to disable writes to this register as well.  To boot, I need both of these turned on as my BIOS locks both of these registers unfortunately.  I am working on a patch for my bios but we'll see if it works.  I cannot find the second option that @eritiusfound in his version of the bios.  The name he said it was called does not exist anywhere in v3.0c of the same motherboard's BIOS.  

 

Even PMHeart's xcpm performance patch, notoriously dependent on both CPU generation and kernel version, can be automatically applied for any architecture on any kernel version by turning on the AppleXcpmForceBoost quirk in open core.  Just be warned, your room is probably going to get pretty warm if you use that one :). 

 

Even non-xcpm power mangement is covered.  Need to patch writes to 0xE2 in AppleIntelCpuPowerManagement.kext?  Turn on the AppleCpuPmCfgLock quirk.  Want to disable it entirely, ala NullCpuPowermanagement?  Turn on the DummyPowerManagement quirk.  

 

This is why I am using OpenCore over Clover, because it is becoming too difficult to get the right combinations of patches for the right CPU architecture and for the right version of MacOS, and by using OpenCore, one does not need to worry about kernel patches at all.  OpenCore can figure out the patches for you, removing the need for primitive find/replace patches which are fragile, kernel and/or cpu specific, and easily broken.  

 

 

Secondly, it is not mandatory to fill in Min/Max kernel at all for kexts.  In fact, leave them empty.  All they do is make it harder to know which kexts are enabled and which aren't.  If you don't want to use a kext, then don't enable it.  If you do, then enable it.  It's that simple.  I have these fields empty and have always had them empty and it causes no problems.

 

 

Do not drop power management tables.  Skylake and Cascade lake are both natively supported by xcpm and HWP.  Dropping CPU power management tables just breaks power management on these platforms and potentially will prevent you from booting.  You had to do this on haswell and broadwell.  Do not do it on newer architectures.  

 

Do not use a UsbKeyboard EFI driver while also having Key Support turned on.  Choose one way to fix something, I cannot drive this point home enough.  Enabling multiple fixes for the same thing almost always will mean you can't boot.  Why would you turn on Key Support when you already have a EFI driver that... surprise... adds key support?  

 

Do not use a display level above 64 (0x40) unless your intention is to completely halt your CPU on any error for remote debugger purposes.  

 

You WILL need to use a SSDT to inject plugin-type = 1 property on your first CPU for working XCPM.  There are ready made SSDTs easily found for this.  Make sure it makes the ACPI path for your CPU, which is usually SB.PC00.CP00 on these platforms instead of SB.PCI0 etc.

 

Unless you're on broadwell or haswell, do not use a fake CPUID.  And beyond that, it will not work unless you have the correct CPUID mask as well.  And the CPUID is not the same as in clover.  Regardless, you probably don't need it unless you're on a non-natively supported architecture, which for anything recent, is limited to broadwell and haswell.  Anyone with a C620, X299, or C422 chipset should have CPUID1 and CPUID1Mask completely blank.  

 

I've attached a fixed OC config for skyflying.  It might not get you booting, but it definitely won't make things worse.  Also, not sure what that excel spread sheet is doing in your ACPI.  You need to copy and paste the output of the spreadsheet into Device Properties, along with several other things just like in Clover.  But don't worry about that now, the Radeon VII (same card as I have) works fine without any of that.  Worry about overclocking later when things are working :).  

skyflying5_oc_fixed.zip

 

first i’m appreciate u help

i got lots of information from you post

unfortunatly i still get the same black screen stuck still after i choose the mac boot option

i still cannot figure out what to do next.

 

[metacollin]

 

On 2/22/2020 at 3:04 AM, skyflying5 said:

 

first i’m appreciate u help

i got lots of information from you post

unfortunatly i still get the same black screen stuck still after i choose the mac boot option

i still cannot figure out what to do next.

 

@skyflying5:

 

Ok, I think you might have the same BIOS problem that I had.  What version of the BIOS is on your motherboard?  3.2?  I'm working towards a solution but for now, your best bet might be to flash an earlier version of the bios if you can find one. 

 

But before trying that, a quick sanity check:  Is CSM turned off?  It is kind of hard to find in the Supermicro BIOSes.  If it isn't turned off, the machine will never make it past the OC selector, at least on my motherboard.   

 

First, go to PCIE/PCI/PnP Configuration:

 

 

Then make sure your Onboard Video OPROM is set to UEFI.

 

 

If you had to change it, hit F4 to save and reboot, but enter the BIOS setup a second time (if you don't, you'll get a message saying you need to reboot first to disable CSM, and then you'll just have to reboot anyway).

 

Finally, hidden under the Security tab, go to the Secure Boot  submenu:

 

 

And here, finally, is the CSM setting.  Make sure it is set to Disabled.   Your machine will not boot macOS unless this is set to Disabled.

 

 

Edited February 23, 2020 by metacollin

[metacollin]

In case anyone was wondering, Cascade Lake-SP does in fact work with native power management and HWP on Catalina, no fake cpuid needed.  

Even missing the last 2 sticks of RAM, leaving 2 memory channels empty and preventing full interleaving (due to an unbalanced memory topology), which is causing substantially degraded memory performance at the moment, it didn't matter.

 

I still handily crushed the top-tier Mac Pro's multicore Geekbench 5 score (19172):

https://browser.geekbench.com/v5/cpu/1288154

 

Once those last 2 sticks come in the mail, I expect ~800-1000 more points on the multicore score.  

 

 

Also, @eritius, I added support for the C620 series audio to AppleALC and have audio for our motherboards working.  It isn't in the most recent release, but if you download the latest source from github and compile AppleALC and just use this ssdt, full working audio is yours:

 

 

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20180427 (64-bit version)(RM)
 * Copyright (c) 2000 - 2018 Intel Corporation
 * 
 * Disassembling to non-symbolic legacy ASL operators
 *
 * Disassembly of iASLmnVdyy.aml, Sun Feb 23 11:22:44 2020
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x000000D8 (216)
 *     Revision         0x01
 *     Checksum         0x28
 *     OEM ID           "toleda"
 *     OEM Table ID     "amicavs1"
 *     OEM Revision     0x00003000 (12288)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20180427 (538444839)
 */
DefinitionBlock ("", "SSDT", 1, "toleda", "amicavs1", 0x00003000)
{
    External (_SB_.PC00, DeviceObj)    // (from opcode)
    External (_SB_.PC00.CAVS._ADR, IntObj)    // (from opcode)

    Scope (\_SB.PC00)
    {
        Device (HDEF)
        {
            Name (_ADR, 0x001F0003)  // _ADR: Address
            Method (_INI, 0, NotSerialized)  // _INI: Initialize
            {
                Store (Zero, \_SB.PC00.CAVS._ADR)
            }

            Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
            {
                Return (Package (0x02)
                {
                    0x0D, 
                    0x05
                })
            }

            Method (HDEF._DSM, 4, NotSerialized)  // _DSM: Device-Specific Method
            {
                If (LEqual (Arg2, Zero))
                {
                    Return (Buffer (One)
                    {
                         0x03                                           
                    })
                }

                Return (Package (0x04)
                {
                    "layout-id", 
                    Buffer (0x04)
                    {
                         0x01, 0x00, 0x00, 0x00                         
                    }, 

                    "PinConfigurations", 
                    Buffer (Zero){}
                })
            }
        }
    }
}

 

Edited February 23, 2020 by metacollin

[obus]

On 2/22/2020 at 11:04 AM, skyflying5 said:

Secondly, it is not mandatory to fill in Min/Max kernel at all for kexts.  In fact, leave them empty.  All they do is make it harder to know which kexts are enabled and which aren't.  If you don't want to use a kext, then don't enable it.  If you do, then enable it.  It's that simple.  I have these fields empty and have always had them empty and it causes no problems.

For me it is mandatory because I boot between Mac OS Mojave and Catalina. Without max and min kernel my rig isn't booting at all. If you are booting only Mac OS Catalina only I fully agree that you can leave this blank.

 

Thread name" help installing Mojave on Xeon-W2175..........."

 

Edited February 24, 2020 by obus

[aprilnine]

On 2/23/2020 at 8:13 PM, metacollin said:

In case anyone was wondering, Cascade Lake-SP does in fact work with native power management and HWP on Catalina, no fake cpuid needed.  

Even missing the last 2 sticks of RAM, leaving 2 memory channels empty and preventing full interleaving (due to an unbalanced memory topology), which is causing substantially degraded memory performance at the moment, it didn't matter.

 

Hi metacollin, can you help me with my hackintosh setup? I have a quite similar board as you (X11DPH-T) and run it with two Xeon 6142 Gold processors. It seems you solved the very same problems I'm having with the setup.

 

I've tried my best to patch up the aml:s, but nothing seems to work. Looks like I can't get the EC running since I get no USB (observed from keyboard lights).

 

Attached are my EFI folders and DSDT dump. Any help would be greatly appreciated

 

DSDT.dsl

EFI.zip