X299 Big Sur Support

[oli.mathieu]

@oli.mathieu @shutterbug168 - Do you guys have working NVRAM or an emulated NVRAM?

Nope

 

[rustEswan]

Nope

So I just looked at your DSDT again and it is exactly the same LPC/PCI pathing as mine - you could try compiling my SSDT on post #917 and see if your NVRAM works?

I suspect we are both suffering broken NVRAM but that wouldn't explain why @Loloflatsix has progressed without a working NVRAM... But possibly of interest anyway that our boards share the same LPC/PCI pathing and we have the same issues

 

[Loloflatsix]

So I just looked at your DSDT again and it is exactly the same LPC/PCI pathing as mine - you could try compiling my SSDT on post #917 and see if your NVRAM works?

I suspect we are both suffering broken NVRAM but that wouldn't explain why @Loloflatsix has progressed without a working NVRAM... But possibly of interest anyway that our boards share the same LPC/PCI pathing and we have the same issues

Just checked now Nvram :
Big Sur :
- on Asus Prime Deluxe X299 : ok : if I select : Catalina as startup disk : I boot on Catalina
- on Gigabyte X299 UD4 : ok : if I select : Catalina as startup disk : I boot on Catalina
- on Asrock X299 Steel Legend : not ok : I boot on first boot disk priority in bios
- on Asrock X570 Taichi : ok : if I select : Catalina as startup disk : I boot on Catalina

 

[TheBloke]

But possibly of interest anyway that our boards share the same LPC/PCI pathing and we have the same issues

FYI my LPC/PCI pathing for PMCR, and indeed my entire SSDT-PMCR, are identical to yours, and I don't have any issue with NVRAM. The Dortania NVRAM test passes, and I am able to set my startup disk, both via System Preferences -> Startup Disk and by hitting Control-Enter in the OpenCore boot picker.

Have you confirmed that your SSDTs are all loading OK? You can check your logs from boot with:

sudo log show --style syslog --source --last boot  | less

Scroll through the output (hit space to scroll to next page). The first couple of pages will handle DSDT/SSDT loading. You're looking for a summary line like this:

2020-11-23 17:19:57.895413+0000  localhost kernel[0]: (AppleACPIPlatform) <AppleACPIPlatform`AcpiOsVprintf> 2 ACPI AML tables successfully acquired and loaded
2020-11-23 17:19:57.895415+0000  localhost kernel[0]: (AppleACPIPlatform) <AppleACPIPlatform`AcpiOsVprintf> 2 ACPI AML tables successfully acquired and loaded

(FYI that summary is from my old X58 system, which is still my daily driver until I'm finished configuring the X299X. My GB Designare has far more tables loaded than that.)

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.

 

[shutterbug168]

BIG SUR 11.1 (BETA) UPGRADE REPORT - GIGABYTE X299X DESIGNARE 10G

With all the reports of people unable to install Big Sur on X299 MBs, I thought I'd try an upgrade myself and report back, for the record and in case it's of any help to anyone with problems.

SUMMARY: I was able to upgrade a Catalina 10.15.7 install to Big Sur 11.1 Beta with no problems or incidents.

TIMING: The total install took approximately 1 hour, which breaks down as follows:

• 15 minutes (approx; I didn't time it): In Catalina, starting the Big Sur update process, leading to first reboot
• + 20 minutes: Time until second reboot
• + 4 minutes: Time until third reboot
• + 8 minutes: Time until fourth reboot
• + 11 minutes: Time until login screen appeared
• = 58 minutes total upgrade time

METHOD:

1. I first backed up my existing Catalina 10.15.7 install to a secondary SSD.
   1. I made the backup using SuperDuper!, which is macOS backup software capable of making fully bootable backups
   2. An alternative that also works well is Carbon Copy Cloner.
   3. FYI while both these tools are capable of making fully bootable backups of Catalina, they're not yet capable of making bootable Big Sur copies, due to the filesystem changes.
2. After the backup was done, I copied my current EFI folder to the EFI partition of the second SSD, so it was OpenCore bootable.
3. Before booting, I made the following minor changes to my OpenCore config.plist:
   1. I disabled AirportItlwm.kext, as I know it requires a different version for Big Sur
   2. I set DisableLinkeditJettison to true, as I've read this helps Big Sur
4. I removed all other SSD/NVMe drives.
5. I booted directly from the Catalina 10.15.7 install, using its copy of my OpenCore config.
6. I opted in to beta updates by running the following terminal command: sudo /System/Library/PrivateFrameworks/Seeding.framework/Versions/A/Resources/seedutil enroll DeveloperSeed
7. I then started the update process from System Preferences -> Software Update.

I've described all this because I noted that a lot of the people who are having problems installing Big Sur seem to be trying a fresh install? At least that's the impression I got, looking at the screenshots from users like @rustEswan .

I haven't done a fresh install of macOS for 5+ years. I always do an upgrade over an existing install, because I have years worth of applications and settings and I prefer to update in place rather than try the "restore from backup" method. Also, I've never had any problems applying backups in place (I've been doing it since High Sierra), so I see no need to use any other method.

However I always do it on a copy of my main SSD. So if the upgrade fails or isn't bootable, I can carry on with my main SSD/NVMe drive and try the upgrade on a new copy sometime later.

So I'd be interested to know whether the users who have had all these problems are only trying a fresh Big Sur install, or whether any of them have tried an in-place upgrade to Big Sur from Catalina? If you have a spare SSD/NVMe drive, you can test this by cloning your existing drive onto the second drive.

MY OPENCORE 0.6.3 EFI (Gigabyte X299X Designare 10G) - MacPro 7,1 SMBIOS

I've attached the EFI I used for upgrading to Big Sur and booting it, in case this of any help to anyone.

I've not finished refining the EFI. I plan to make the USB.kext like lolflatsix has described, and I hope to reduce the number of SSDTs I'm using and use DeviceProperties instead.

But I can confirm that this EFI is working fine for me on both Catalina and Big Sur. So maybe it might help someone to look at it when working on their own problems.

Note that in config.plist I have removed my PlatformInfo details and replaced these with CHANGEME.

The EFI is using DEBUG versions of OpenCore and all Acidanthera kexts. OpenCore is configured for debug logging via Target = 65 (to disk, but not to screen.) The kexts are not configured for debug logging, but this can be added via boot-args.

The EFI has SIP disabled. This seems to be useful in Big Sur. For example, I was surprised to find that Little Snitch 4.6 still seemed to be fully working after my first Big Sur boot. I assume this must be because SIP is disabled. I had expected to have to either upgrade to Little Snitch 5, or else specifically allow the Little Snitch 4.6 kext to load via spctl kext-consent add MLZF7K7B5R. But in fact it's working fine.

@TheBloke Did you try updating your BS beta to the 11.0.1 release? 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

 

[TheBloke]

@TheBloke Did you try updating your BS beta to the 11.0.1 release?

I'm on a newer version than 11.0.1 release - I'm on 11.1 beta, the first beta of the first point release update for Big Sur, which will be 11.1. The beta came out a few days ago, shortly after 11.0.1 was released.

I chose that version as:
a) It's the latest version, and I figured it was the best to test the very latest version
b) It's the only version with (partial) support for the new AMD 6800 GPUs. If I can't get a 6800XT when the AIB cards go on sale on Wednesday, I will open the 6800 that's currently sitting on my desk, and try it out in macOS. I'm not expecting it to work properly yet, though. The first 11.1 beta added basic support for it, but from what I've heard there's still no acceleration for it. I don't know if that's down to 11.1 not yet fully supporting the 6800 cards, or if lack of acceleration is a Hackintosh specific issue. We might have to wait for a WhateverGreen update, I'm not yet sure.

 

[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