X299 Big Sur Support

[TheBloke]

BTW, I have successfully updated my Catalina drives on an AMD hack and my VERY OLD MacPro 5,1 to BS 11.0.1 without any issues. This X299 specific problem is driving me nuts

OK so you know you can use this to get your X299 on Big Sur also? Until the X299 issue is fixed, I'd suggest you do what @rustEswan has done:

• Take your Catalina SSD/NVMe out of the X299, and put it in one of your systems that you know can update to BigSur; the AMD, or the MacPro 5,1.
• Do the upgrade to Big Sur on that second machine
• Once it's complete and you've logged in for the first time, put your X299 EFI on that drive, take it out and return it to the X299
• If your experience is the same as rustEswan, it should now boot fine in the X299
• This will continue to work until, possibly, the next time you need to update again, eg to 11.0.2 or 11.1, whichever comes first.
  • That update might work direct on the X299 - maybe it's only complete fresh installs or updates from earlier OS that fail - or it might be you need to use a surrogate system to do all updates.

It's not very convenient, but from the sounds of it it should work.

If your X299 doesn't have a working Catalina install - eg because you already tried upgrading and now it's hosed - then you could do a fresh Big Sur install on your AMD or Mac Pro on to a blank drive, then put that drive into the X299 and it should work.

In other words, the evidence suggests that it's only installation and upgrade of Big Sur that's broken on X299 systems. Day to day running appears to be fine. So anyone who has another hack or real Mac can get around the issue by using it to do upgrade/install duties for the X299.

 

[amitbapat]

OK so you know you can use this to get your X299 on Big Sur also? Until the X299 issue is fixed, I'd suggest you do what @rustEswan has done:

• Take your Catalina SSD/NVMe out of the X299, and put it in one of your systems that you know can update to BigSur; the AMD, or the MacPro 5,1.
• Do the upgrade to Big Sur on that second machine
• Once it's complete and you've logged in for the first time, put your X299 EFI on that drive, take it out and return it to the X299
• If your experience is the same as rustEswan, it should now boot fine in the X299
• This will continue to work until, possibly, the next time you need to update again, eg to 11.0.2 or 11.1, whichever comes first.
  • That update might work direct on the X299 - maybe it's only complete fresh installs or updates from earlier OS that fail - or it might be you need to use a surrogate system to do all updates.

It's not very convenient, but from the sounds of it it should work.

If your X299 doesn't have a working Catalina install - eg because you already tried upgrading and now it's hosed - then you could do a fresh Big Sur install on your AMD or Mac Pro on to a blank drive, then put that drive into the X299 and it should work.

In other words, the evidence suggests that it's only installation and upgrade of Big Sur that's broken on X299 systems. Day to day running appears to be fine. So anyone who has another hack or real Mac can get around the issue by using it to do upgrade/install duties for the X299.

I tried exactly same approach for my MSI X299 Raider based Hackintosh. I have a real MacPro (2013, old and slow) that I used to install Big Sur 11.0.1 on the SSD connected to USB, then transferred it back to the Hackintosh and added the EFI folder. Boots just fine into Big Sur.

 

[rustEswan]

If any SSDT failed to apply for any reason, you'll see it described there. It doesn't specifically say which failed, however if they all have unique names, you can work it out.

It's a long shot, but worth double checking that the SSDT is actually loading.

Thanks - good to know - looks like they're all loading successfully, no indication of any entries to say otherwise (I just added the grep here to minimise the output, but nothing obvious):

aswan@Alexs-iMac-Pro ~/Downloads/MountEFI-update $ sudo log show --style syslog --source --last boot  | grep "ACPI AML"
2020-11-22 14:39:43.856199-0800  localhost kernel[0]: (AppleACPIPlatform) <AppleACPIPlatform`AcpiOsVprintf> 9 ACPI AML tables successfully acquired and loaded
2020-11-22 14:39:43.856200-0800  localhost kernel[0]: (AppleACPIPlatform) <AppleACPIPlatform`AcpiOsVprintf> 9 ACPI AML tables successfully acquired and loaded

Im going to take another long hard look at the DSDT and see if I can try any other paths for the PMCR to get NVRAM working.

 

[Loloflatsix]

Thanks - good to know - looks like they're all loading successfully, no indication of any entries to say otherwise (I just added the grep here to minimise the output, but nothing obvious):

aswan@Alexs-iMac-Pro ~/Downloads/MountEFI-update $ sudo log show --style syslog --source --last boot  | grep "ACPI AML"
2020-11-22 14:39:43.856199-0800  localhost kernel[0]: (AppleACPIPlatform) <AppleACPIPlatform`AcpiOsVprintf> 9 ACPI AML tables successfully acquired and loaded
2020-11-22 14:39:43.856200-0800  localhost kernel[0]: (AppleACPIPlatform) <AppleACPIPlatform`AcpiOsVprintf> 9 ACPI AML tables successfully acquired and loaded

Im going to take another long hard look at the DSDT and see if I can try any other paths for the PMCR to get NVRAM working.

I just take a look at your DSDT and PMC1 (PMCR) ACPI path :

your PMCR looks like PMC1 :

    Scope (_SB.PC00)
    {
        Scope (PMC1)
        {
            Method (_DSM, 4, Serialized)  // _DSM: Device-Specific Method

In clover , in past time with KGP we renamed PMC1 ——>PMCR but no need with SSDT :

    Scope (_SB.PC00)
    {
        Scope (PMC1)
        {
            Name (_STA, Zero)  // _STA: Status
        }
        Device (PMCR)
        {
            Name (_ADR, 0x001F0002)  // _ADR: Address
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (_OSI ("Darwin"))
                {
                    Return (0x0B)
                }
                Else
                {
                    Return (Zero)
                }
            }

            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                Memory32Fixed (ReadWrite,
                    0xFE000000,         // Address Base
                    0x00010000,         // Address Length
                    )
            })
        }

you can also try :

    Scope (_SB.PC00)
    {
        Scope (PMC1)
        {
            Name (_STA, Zero)  // _STA: Status
        }
        Device (PMCR)
        {
            Name (_HID, EisaId ("APP9876"))  // _HID: Hardware ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (_OSI ("Darwin"))
                {
                    Return (0x0B)
                }
                Else
                {
                    Return (Zero)
                }
            }

            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                Memory32Fixed (ReadWrite,
                    0xFE000000,         // Address Base
                    0x00010000,         // Address Length
                    )
            })
        }

In another thread someone succeeded wilt SSDT-PMC

 

[shutterbug168]

OK so you know you can use this to get your X299 on Big Sur also? Until the X299 issue is fixed, I'd suggest you do what @rustEswan has done:

• Take your Catalina SSD/NVMe out of the X299, and put it in one of your systems that you know can update to BigSur; the AMD, or the MacPro 5,1.
• Do the upgrade to Big Sur on that second machine
• Once it's complete and you've logged in for the first time, put your X299 EFI on that drive, take it out and return it to the X299
• If your experience is the same as rustEswan, it should now boot fine in the X299
• This will continue to work until, possibly, the next time you need to update again, eg to 11.0.2 or 11.1, whichever comes first.
  • That update might work direct on the X299 - maybe it's only complete fresh installs or updates from earlier OS that fail - or it might be you need to use a surrogate system to do all updates.

It's not very convenient, but from the sounds of it it should work.

If your X299 doesn't have a working Catalina install - eg because you already tried upgrading and now it's hosed - then you could do a fresh Big Sur install on your AMD or Mac Pro on to a blank drive, then put that drive into the X299 and it should work.

In other words, the evidence suggests that it's only installation and upgrade of Big Sur that's broken on X299 systems. Day to day running appears to be fine. So anyone who has another hack or real Mac can get around the issue by using it to do upgrade/install duties for the X299.

Thanks! Will try that in the next day or so... But do I finish the ENTIRE update process on my cMP5,1 with the X299 drive connected? Or do I need to disconnect it before the first reboot and let it finish with the original X299 hack? I thought the installer will seal the drive... and "bond" it to the hardware -- the very step that we are all failing at this point... no?

 

[shutterbug168]

I tried exactly same approach for my MSI X299 Raider based Hackintosh. I have a real MacPro (2013, old and slow) that I used to install Big Sur 11.0.1 on the SSD connected to USB, then transferred it back to the Hackintosh and added the EFI folder. Boots just fine into Big Sur.

Did you run the entire update process on the cMP5,1 with the SSD connected to it? And then just reconnected it to your X299? Thanks!

 

[rustEswan]

@TheBloke - I think you could be onto something re NVRAM and it could be the key to resolving some installer issues. If not, at least it could be one more thing working for X299 users, if we can work it out but I'm reaching the limit of my comfort zone with ACPI.

I've done a bit of digging around the NVRAM not working and noticed that when I check the pathing (as detailed in the Dortania guide) I get multiple entries for the PCI path - PC00, PC01, PC02 etc through to PC05. I've tried each of those in place of the pathing in the SSDT-PMC none to seem work:

DefinitionBlock ("", "SSDT", 2, "ACDT", "PMCR", 0x00001000)
{
    External (_SB_.PC00.LPC0, DeviceObj)

    Scope (_SB.PC00.LPC0)
    {
        Device (PMCR)
        {
            Name (_HID, EisaId ("APP9876"))  // _HID: Hardware ID
            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (_OSI ("Darwin"))
                {
                    Return (0x0B)
                }
                Else
                {
                    Return (Zero)
                }
            }

            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                Memory32Fixed (ReadWrite,
                    0xFE000000,         // Address Base
                    0x00010000,         // Address Length
                    )
            })
        }
    }
}

I also then decided to search a real Mac's IORegistry for the PMCR device as listed in the SSDT-PMC template which I found:

And then searched for PMCR on my X299 IOReg which I couldn't find but I did find PMC1 which looks remarkably similar to the PMCR device on the real Mac:

Further searching the Dumped DSDT for the PMC1 device shows it in the tree adjacent to the LPC0 PCI path rather than under it, as suggested in the SSDT-PMC template:

I then tried replacing the SSDT-PMC pathing with just PC00 rather than PC00.LPC0 but it didn't work - I ended up with both a PMC1 and a PMCR device but it still wouldn't work.

I'm at the limit of knowledge here but wondering if we can somehow disable the PMC1 device and create the PMCR device in its place in the correct path in the tree? Im just not clear enough on custom ACPI to work out how to do it - hopefully someone with some more experience here could suggest a possible way forward for resolving our NVRAM issue.

Hopefully in turn that may have a positive impact on the installer issues.

 

[rustEswan]

Did you run the entire update process on the cMP5,1 with the SSD connected to it? And then just reconnected it to your X299? Thanks!

If you do it this way it only wants to reboot once, when it does that just unplug the drive at reboot and let your real Mac boot as normal back into MacOS then plug it back in, mount the EFI partition, copy over your EFI folder and then go and plug it into your hack.

 

[shutterbug168]

If you do it this way it only wants to reboot once, when it does that just unplug the drive at reboot and let your real Mac boot as normal back into MacOS then plug it back in, mount the EFI partition, copy over your EFI folder and then go and plug it into your hack.

@rustEswan Very cool! Thanks again...

 

[rustEswan]

I just take a look at your DSDT and PMC1 (PMCR) ACPI path :

your PMCR looks like PMC1 :

- I only just saw this after my long post! Seems we are thinking alike! I will go and test that now. Thanks!