Jump to content

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


obus
 Share

852 posts in this topic

Recommended Posts

 

On 3/5/2020 at 1:39 PM, obus said:

Sorry if I'am a little bit confused but according to @vit9696 this patch is only needed if we can't force enable Legacy RTC in bios. On our motherboard (ASUS WS C422 Pro/SE) this option is possible and enabled.

Does that mean we just dosen't need it and if not what doe's we need? I can boot with @lovest.fhd:s SSDT-RST.aml and if I boot with this SSDT I get AWAC initialised too. 

Can anybody explain for me what I shall use please. 

You trying to enable two conflicting devices. AWAC(_STA 0xf) condition STAS=0 and RTC(_STA 0xf) condition STAS=1. You managed to do it forcibly via SSDT then you're surprised you have unexpected behavior(panic). I don't know... You could instead test given SSDT-AWAC.aml and contribute, post request to Acidanthera team for editing comment in SSDT-AWAC.aml, but of course it's up to you;)AWAC.png.a41d86b7cc09207d0eebe40c747931d2.png

RTC.png.c88d56c0128d3c3eab3094b1a77215e7.png

Edited by hardcorehenry
Link to comment
Share on other sites

1 hour ago, hardcorehenry said:

 

You trying to enable two conflicting devices. AWAC(_STA 0xf) condition STAS=0 and RTC(_STA 0xf) condition STAS=1. You managed to do it forcibly via SSDT then you're surprised you have unexpected behavior(panic). I don't know... You could instead test given SSDT-AWAC.aml and contribute, post request to Acidanthera team for editing comment in SSDT-AWAC.aml, but of course it's up to you;)

 

I have no KP with original v. 3003 bios and @lovest.fhd:s SSDT-RTC.aml, so I don't exactly know what you are reffering to. My rig is rock stable with this configuration and I have both RTC and AWAC initialised. Wake after sleep is working perfect too.  The  "problem/unexpected behaviour" I was talking about in earlier post was KP when trying to wake the rig after sleep with a modded v. 3003 bios from @metacollin, and this is a complete different story I presume. 

And by the way I'm trying to contribute as good as I can in relation to my knowledge.:whistle:

Edited by obus
Link to comment
Share on other sites

2 hours ago, metacollin said:

 

@yapan4 (and anyone else having sleep/wake panics), can you upload the panic log (or just the top part plus the crashed thread stack trace)?  Even when waking up from sleep, usually it gets far enough to still make a panic log.  You all might have one in your /Library/Logs/DiagnosticReports folder.   It will probably be called 'kernel', and of course have a .panic suffix.  It might be under pmutil or something like that as well, not sure. 

 

 

Here we go. Can.t find this panic suffix. 

 

Kernel_2020-03-03-145948_iMac-Pro.panic

Edited by obus
Link to comment
Share on other sites

1 hour ago, obus said:

I have no KP with original v. 3003 bios and @lovest.fhd:s SSDT-RTC.aml, so I don't exactly know what you are reffering to. My rig is rock stable with this configuration and I have both RTC and AWAC initialised. Wake after sleep is working perfect too.  The  "problem/unexpected behaviour" I was talking about in earlier post was KP when trying to wake the rig after sleep with a modded v. 3003 bios from @metacollin, and this is a complete different story I presume. 

And by the way I'm trying to contribute as good as I can in relation to my knowledge.:whistle:

Question is, why do you insist on having AWAC in your IOReg, macos doesn't control AWAC, there's no AWAC device in any MAC AFAIK:whistle:

Edited by hardcorehenry
Link to comment
Share on other sites

1 hour ago, hardcorehenry said:

Question is, why do you insist on having AWAC in your IOReg, macos doesn't control AWAC, there's no AWAC device in any MAC AFAIK:whistle:

I'm not insisting on that and I know after reading @vit9696:s comment on GitHub that there is no AWAC device to control in a Mac. But because both SSDT-AWAC and SSDT-RTC is working on my rig I was confused.

That's it!

  • Like 1
Link to comment
Share on other sites

@hardcorehenry

 

Now there is a new problem with OC 0.5.6!!! 

With new OC release my rig isn't booting at all with SSDT-AWAC.aml but booting perfect with SSDT-RTC.aml without initialising AWAC???:blink:

 

This with @metacollin:s modded v. 3003 bios. What about That???

 

 

Screenshot 2020-03-06 at 20.17.01.png

Edited by obus
Link to comment
Share on other sites

1 hour ago, obus said:

@hardcorehenry

 

Now there is a new problem with OC 0.5.6!!! 

With new OC release my rig isn't booting at all with SSDT-AWAC.aml but booting perfect with SSDT-RTC.aml without initialising AWAC???:blink:

 

This with @metacollin:s modded v. 3003 bios. What about That???

 

 

Screenshot 2020-03-06 at 20.17.01.png

Sounds unbelievable, but if SSDT-RTC.aml works for you best I think you should stick to it.

  • Like 1
Link to comment
Share on other sites

7 minutes ago, hardcorehenry said:

Sounds unbelievable, but if SSDT-RTC.aml works for you best I think you should stick to it.

 

After clearing CMOS and NVRAM it's possible to boot with SSDT-AWAC.aml on OC 0.5.6.

This is the recommended way to implement the device so I stick to that. Thank's for your help.:thumbsup_anim: 

Link to comment
Share on other sites

@skyflying5

my bluetooth keyboard still cannot work ,when i want to pear it ,it aways got disconnected immediately when display “connected”

 

I recommend wired USB keyboard for hackintosh.

 

 

now i have a bug with reboot & poweroff,the process will stack at only background photo without any icon

 

i have to press the reboot button to let it finish the reboot process

 

 

This means that macos cannot complete the running process or the open application.

Edited by yapan4
Link to comment
Share on other sites

On 3/6/2020 at 3:39 PM, metacollin said:

Well, this is (or at least, originally was) a thread for the C422, so its kind of the fault of all us C621 people invading the thread for the confusion.  Sorry about that, but I figure it is better to pool our resources :).

 

 

@yapan4 (and anyone else having sleep/wake panics), can you upload the panic log (or just the top part plus the crashed thread stack trace)?  Even when waking up from sleep, usually it gets far enough to still make a panic log.  You all might have one in your /Library/Logs/DiagnosticReports folder.   It will probably be called 'kernel', and of course have a .panic suffix.  It might be under pmutil or something like that as well, not sure. 

 

I agree. C422 and C621 are very similar and much of the information for one chipset is also suitable for another.

 

@obus already posted their KP log files, I will also leave my own

 

Also note that I was expecting some side effects. We still need to try the full installation of Windows 10 and macOS. If this is not the problem, then the kernel panic when waking from sleep is not the worst result. But why only on ASUS?

 

Best regards.

yapan4

yapan4_wake_KP_log .zip

Link to comment
Share on other sites

14 hours ago, yapan4 said:

 

 

Also note that I was expecting some side effects. We still need to try the full installation of Windows 10 and macOS. If this is not the problem, then the kernel panic when waking from sleep is not the worst result. 

Dual-boot with windows 10 is working without problems on my rig with @metacollin:s modded v. 3003 bios and OC 0.5.6

Edited by obus
  • Like 2
Link to comment
Share on other sites

@obus

Sorry, I meant the installation process from start to finish. There is no particular reason to worry but we need to make sure.

 

Update: tested fully fresh installation:
1) Win10 1709+all updates - no problem, 
2) macOS 10.15.2+updates  -no problems too. 
Wery nice! :thumbsup_anim:

 

@metacollin 

I uninstalled the IntelPowerGadget, unfortunately it didn't help

Kernel_2020-03-08-125644_Admins-Mac-Pro-2.panic

Edited by yapan4
Link to comment
Share on other sites

  • 2 weeks later...

BIOSes needing a generalized unlocking solution:

1. Supermicro motherboards

2. Asus Cxxx motherboards

3. Asus X299 motherboards

4. All Cxxx & X299 motherboards if possible?

 

One down, 3 to go.  https://www.insanelymac.com/forum/topic/343024-supermicro-x11-series-patches-for-uefipatch/

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

BIOSes needing a generalized unlocking solution:

1. Supermicro motherboards

2. Asus Cxxx motherboards

3. Asus X299 motherboards (or at least, one of them)

4. All Cxxx & X299 motherboards if possible?

 

3 down, 1 to go.  https://www.insanelymac.com/forum/topic/343024-uefipatch-bios-patches-for-c422-c621c622-x299-based-motherboards-vanilla-unpatched-kernel-native-power-management/

 

Get the patches.txt file from that link, and you can use UEFIPatch to unlock the 0xE2 and 0x1AA MSRs (which allows you to boot macOS without any kernel patches and permits total, native power management in macOS) for the following motherboards (at least.  My hope is the patches are generalized enough that they will work for a large number of motherboards across multiple brands - but that remains to be seen):

  • Asus WS C422 PRO/SE
  • Asus PRIME X299-A
  • Asus WS C422 SAGE/10G
  • Supermicro X11 Series LGA2011 & LGA3647 single and multisocket motherboards
  • Maybe your motherboard?

 

Also I'm working towards getting my OpenCore folder and config up on github soon for people to use as an example, though I need to figure out what is preventing macOS from booting if I use my latest BIOS's DSDT instead of blocking it and using a DSDT table from an older version of my BIOS.  I've done a diff of the working and non-working DSDT, and I can't find anything that would cause this problem... unless macOS needs processors to be processors and not devices?  That seems unlikely but I might try that.  Stay tuned.  

Edited by metacollin
  • Like 2
  • Thanks 4
Link to comment
Share on other sites

On 3/19/2020 at 7:51 AM, metacollin said:

BIOSes needing a generalized unlocking solution:

1. Supermicro motherboards

2. Asus Cxxx motherboards

3. Asus X299 motherboards (or at least, one of them)

4. All Cxxx & X299 motherboards if possible?

 

3 down, 1 to go.  https://www.insanelymac.com/forum/topic/343024-uefipatch-bios-patches-for-c422-c621c622-x299-based-motherboards-vanilla-unpatched-kernel-native-power-management/

 

Get the patches.txt file from that link, and you can use UEFIPatch to unlock the 0xE2 and 0x1AA MSRs (which allows you to boot macOS without any kernel patches and permits total, native power management in macOS) for the following motherboards (at least.  My hope is the patches are generalized enough that they will work for a large number of motherboards across multiple brands - but that remains to be seen):

  • Asus WS C422 PRO/SE
  • Asus PRIME X299-A
  • Asus WS C422 SAGE/10G
  • Supermicro X11 Series LGA2011 & LGA3647 single and multisocket motherboards
  • Maybe your motherboard?

 

Also I'm working towards getting my OpenCore folder and config up on github soon for people to use as an example, though I need to figure out what is preventing macOS from booting if I use my latest BIOS's DSDT instead of blocking it and using a DSDT table from an older version of my BIOS.  I've done a diff of the working and non-working DSDT, and I can't find anything that would cause this problem... unless macOS needs processors to be processors and not devices?  That seems unlikely but I might try that.  Stay tuned.  

ths, I successfully patched my BIOS

  • Like 1
Link to comment
Share on other sites

On 3/19/2020 at 12:51 AM, metacollin said:

Get the patches.txt file from that link, and you can use UEFIPatch to unlock the 0xE2 and 0x1AA MSRs (which allows you to boot macOS without any kernel patches and permits total, native power management in macOS) for the following motherboards (at least.  My hope is the patches are generalized enough that they will work for a large number of motherboards across multiple brands - but that remains to be seen):

  • Asus WS C422 PRO/SE 

Patched bios v. 3003 according to your guide above with UEFIPatch. Booting perfect without any kernel patches but still panic after wake from sleep. 

Any suggestions?

Kernel_2020-03-19-184639_iMacPro.panic

Edited by obus
  • Like 1
Link to comment
Share on other sites

On 3/22/2020 at 11:58 AM, obus said:

Patched bios v. 3003 according to your guide above with UEFIPatch. Booting perfect without any kernel patches but still panic after wake from sleep. 

Any suggestions?

Kernel_2020-03-19-184639_iMacPro.panic

 

Whoops, I forgot to mention that you need to have the  keepsyms=1 in your boot flags when you generate the wake panic log, otherwise I can't symbol locate where the panic occurred with just the information provided in the log.  Sorry.  So uh, if anyone wants to upload another log, but this time with keepsyms=1 in your boot flags, that'd be great.  

 

And sorry, my fault for forgetting to mention that.  I didn't mean to waste anyone's time.  

 

Oh, and I figured out why the newer version of my BIOS couldn't boot macOS without using the DSDT from an older BIOS.  I am not sure if it is unique to my problem, or if other BIOSes have this problem, but it is worth keeping in mind.

 

So the ACPI spec recently deprecated the use of the Processor object entirely.  From ACPI 6.2 (I think?) and newer, processors are just another Device object, instead of their own special type.  

 

Well, macOS does not support this at all.  If your ACPI tables don't have any processor objects somewhere, macOS isn't able to locate them and just stalls.   As far as macOS is concerned, no processor objects means no CPUs and it I guess just gives up after finding no CPUs hahaha.

 

It would be trivial to change them to Processor objects in the DSDT code, but for me, using a static DSDT (and thus, any DSDT code patches) is unacceptable and will break many BIOS settings and generally cause long term problems... so doing it the easy way was not an option.  A binpatch in OC/Clover would be totally impractical (and probably down right impossible)... so that left me with one option, an SSDT hotpatch.   

 

Used a lot of regex-fu and a bash script to generate this monster, but all I did was add a processor device for each 'CPxx' device with the various reserved methods and names that the actual CPU devices have (or rather, might have), and calls that CPU Device's own method, or returns the result from said method, or returns the name object from the CPU device.  In other words, it just wraps the CPU device in a processor device.  

 

It's not pretty but it got me booting with my latest BIOS's native and unmodified DSDT.  I've attached my SSDT hotpatch in case anyone else has this problem with their DSDT.  This is ultra-specific to my motherboard, which is a dual socket one, so it would need to be modified to work on a different mobo.  

SSDT-CPU-WRAP.dsl

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...