Contribute
Register

X299 Big Sur Support

Joined
Mar 18, 2017
Messages
1,042
Motherboard
ASUS ROG Rampage VI Extreme
CPU
i9-7940X
Graphics
2 X VEGA 56
Mac
  1. iMac
  2. Mac mini
Mobile Phone
  1. iOS
Hello Guys,
I am kind of lost with OC and Big Sur. I am running Hackintosh for few years without any big issues, but Big Sur kind of screwed me ;-) I had nicely functional Catalina and I tried to update the system by apple update. But this decision did broke my original system. I was running latest Clover. After reading so many threads I decided to replace it with OpenCore, which looks like elegant solution, but I have no luck to make it run.

My config is:
Asus TUF X299 MARK2 - Bios 3201
CPU: i9 7940X
GPU: AMD Radeon PRO SSG - It id detected as Vega II

I don't want to waste your time, but I will really appreciate any advice how to solve my issue.
Thank you
Your build setup is very close to mine as requested by another owner I will be sharing my Prime Deluxe EFI but in fact I am busy maintaining my job here and confinement makes it difficult to have plenty of time to help here.
 
Joined
Mar 17, 2011
Messages
15
Motherboard
Asus X299 Mark 2
CPU
i9-7940X
Graphics
Quadro M6000
Mac
  1. Mac mini
  2. Mac Pro
Mobile Phone
  1. iOS
Your build setup is very close to mine as requested by another owner I will be sharing my Prime Deluxe EFI but in fact I am busy maintaining my job here and confinement makes it difficult to have plenty of time to help here.
If you can share your EFI, that will be great. I will go through it to see how different it is from mine.
 
Joined
Feb 26, 2011
Messages
127
Motherboard
ASUS PRIME X299-A II
CPU
i9 10940X
Graphics
AMD Radeon RX 6800 XT
Mac
  1. MacBook
  2. MacBook Pro
Mobile Phone
  1. iOS
I don't want to waste your time, but I will really appreciate any advice how to solve my issue.
Thank you

Have a further read of this - Opencore Install Guide - Stuck at PCI Configuration

If you follow the whole install guide very closely you should have a good chance to get it all working without problems on Asus boards, they seem to be quite friendly for Big Sur - specifically I think you may need to ensure that you have the SSDT-RCT0-RANGE.aml properly configured and working.

Also check IORegexplorer to see if you have an RTC0 device and confirm the ranges are correctly set.

If you're still stuck - post your dumped DSDT and your SSDT-RTC0-RANGE and I'll take a look.

IOregexplorer should look something like this:

Screenshot 2020-11-24 at 08.38.06.png
 
Joined
Mar 6, 2013
Messages
272
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
I don't want to waste your time, but I will really appreciate any advice how to solve my issue.
Thank you

specifically I think you may need to ensure that you have the SSDT-RCT0-RANGE.aml properly configured and working.
Yeah stuck at PCI Begin is 99% certain to be fixed by adding Dortania's SSDT-RTC0-RANGE.aml

Add that to your EFI @dank0 and it should proceed further
 
Joined
Feb 26, 2011
Messages
127
Motherboard
ASUS PRIME X299-A II
CPU
i9 10940X
Graphics
AMD Radeon RX 6800 XT
Mac
  1. MacBook
  2. MacBook Pro
Mobile Phone
  1. iOS
Thanks for your feed back :
I did already verify on real iMacPro 1,1 and MacPro 7,1 this concordance and you confirm my investigation.
For example we have on LPCB device EC and DMAC too but no AWAC I agree.

I tried the alternative SSDT-PMC suggestion - again it looks good, no PMC1 device but does show just a single PMCR device but it still isn't holding variables unfortunately.

I feel like this is really close to being resolved...

Is there any way opencore could be resetting NVRAM on each boot? Like an incorrect setting in config.plist?
 
Joined
Mar 18, 2017
Messages
1,042
Motherboard
ASUS ROG Rampage VI Extreme
CPU
i9-7940X
Graphics
2 X VEGA 56
Mac
  1. iMac
  2. Mac mini
Mobile Phone
  1. iOS
I tried the alternative SSDT-PMC suggestion - again it looks good, no PMC1 device but does show just a single PMCR device but it still isn't holding variables unfortunately.

I feel like this is really close to being resolved...

Is there any way opencore could be resetting NVRAM on each boot? Like an incorrect setting in config.plist?
Maybe you've already read on Dartonia for Emulated Nvram, this creates nvram.plist on update volume (if I remember) :Emulated Nvram ?

nvramplist.png
 
Last edited:
Joined
Mar 6, 2013
Messages
272
Motherboard
Gigabyte X299X Designare 10G
CPU
i9-10980XE
Graphics
AMD 6900XT
Mobile Phone
  1. Android
I might be wrong, but I thought that emulated NVRam couldn't possibly work in an install/update procedure, because the method used for saving NVRam is a script, executed on shutdown:

1606223830665.png


This works OK with a normal day-to-day usage of macOS, because whenever you shutdown that script will run and save the current contents of NVRAM to nvram.plist.

But in an update/install scenario, that script will never execute. Therefore NVRAM will never be saved to nvram.plist?



I do have an idea for a theoretical workaround for enabling non-NVRAM X299 users to update/install:
  1. Someone with working NVRAM could do an upgrade or install
  2. After each reboot during the process, they check the current contents of NVRAM, and make a list of any new or changed NVRAM variables
  3. Someone with broken NVRAM could then try to do an update/install via the following method:
    1. Start the install normally for the first stage
    2. At the first reboot, edit config.plist and add any NVRAM variables that should be present at this stage
    3. At the second reboot, edit config.plist again if there are any new/changed NVRAM variables expected at this point
    4. Repeat for each reboot
In theory - and it's only theory at the moment - this would allow the install/update to work, because config.plist would be used to manually provide all the expected NVRAM variables, at the right time.

It would be a bit inconvenient editing config.plist multiple times for multiple reboots, but it might still be quicker and easier than having to do the update on a completely different system. And for people who don't have a second hack or real Mac, this might enable them to do the update/install.

I have confirmed that I am able to list all EFI variables by booting from an Ubuntu USB stick. So I do have a way to record what variables are present, and their current values.

When I have time, hopefully later today, I will try a Big Sur install or upgrade and will record the variables at each stage of the process, and see if I can find variables being added or changed. If so, I'll see if I can prepare some config.plist files that a non-NVRAM X299 user could test an install with.

Of course this is no replacement for properly working NVRAM. But it might get some X299 users on Big Sur until a way is found to get NVRAM properly working on X299.
 
Joined
Mar 18, 2017
Messages
1,042
Motherboard
ASUS ROG Rampage VI Extreme
CPU
i9-7940X
Graphics
2 X VEGA 56
Mac
  1. iMac
  2. Mac mini
Mobile Phone
  1. iOS
I might be wrong, but I thought that emulated NVRam couldn't possibly work in an install/update procedure, because the method used for saving NVRam is a script, executed on shutdown:

View attachment 498095

This works OK with a normal day-to-day usage of macOS, because whenever you shutdown that script will run and save the current contents of NVRAM to nvram.plist.

But in an update/install scenario, that script will never execute. Therefore NVRAM will never be saved to nvram.plist?



I do have an idea for a theoretical workaround for enabling non-NVRAM X299 users to update/install:
  1. Someone with working NVRAM could do an upgrade or install
  2. After each reboot during the process, they check the current contents of NVRAM, and make a list of any new or changed NVRAM variables
  3. Someone with broken NVRAM could then try to do an update/install via the following method:
    1. Start the install normally for the first stage
    2. At the first reboot, edit config.plist and add any NVRAM variables that should be present at this stage
    3. At the second reboot, edit config.plist again if there are any new/changed NVRAM variables expected at this point
    4. Repeat for each reboot
In theory - and it's only theory at the moment - this would allow the install/update to work, because config.plist would be used to manually provide all the expected NVRAM variables, at the right time.

It would be a bit inconvenient editing config.plist multiple times for multiple reboots, but it might still be quicker and easier than having to do the update on a completely different system. And for people who don't have a second hack or real Mac, this might enable them to do the update/install.

I have confirmed that I am able to list all EFI variables by booting from an Ubuntu USB stick. So I do have a way to record what variables are present, and their current values.

When I have time, hopefully later today, I will try a Big Sur install or upgrade and will record the variables at each stage of the process, and see if I can find variables being added or changed. If so, I'll see if I can prepare some config.plist files that a non-NVRAM X299 user could test an install with.

Of course this is no replacement for properly working NVRAM. But it might get some X299 users on Big Sur until a way is found to get NVRAM properly working on X299.
Yes you'r right with these explanations : the method used for saving NVRam is a script, executed on shutdown : you must therefore complete the installation procedure before : :thumbup:
 
Joined
Mar 17, 2011
Messages
15
Motherboard
Asus X299 Mark 2
CPU
i9-7940X
Graphics
Quadro M6000
Mac
  1. Mac mini
  2. Mac Pro
Mobile Phone
  1. iOS
One more question - after updating VirtualSMC and SMCProcessor and SMCSuperIO, i am getting weird numbers in minimum and maximum RPM. Is there some Patch to fix those values? Also is there way to manage GPU fan speeds?
 

Attachments

  • fans.jpg
    fans.jpg
    13.1 KB · Views: 32
Top