X299 Big Sur Support

[rustEswan]

There's a Dortania guide that shows how to check if NVRAM is fully working: https://dortania.github.io/OpenCore-Post-Install/misc/nvram.html#verifying-if-you-have-working-nvram

I'd suggest some of you who are having problems with Big Sur install/upgrade try that test, to see if you can confirm if your NVRAM is fully working or not.

This is very interesting because that is the one thing that is actually broken still - even on my Catalina install. I haven't been able to get it to work and didn't know if emulated nvram.plist would actually work correctly without the logout hook to write the values during a Big Sur install. Perhaps that is preventing something happening correctly during the install.

So I have my own custom SSDT-PMC for it (but it doesn't work) based on the LPC and PCI pathing found in the DSDT searching for "Name (_ADR, 0x001F0000)" and "PNP0A08" respectively, as per the Dortania guide to fixing NVRAM...

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've attached my dumped DSDT you can check it against my SSDT above if you want and see if there's anything obvious I'm missing. Or whether there's potentially a different LPC/PCI path I can try? Otherwise perhaps emulated NVRAM is the way to go.

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

 

[Loloflatsix]

There's a Dortania guide that shows how to check if NVRAM is fully working: https://dortania.github.io/OpenCore-Post-Install/misc/nvram.html#verifying-if-you-have-working-nvram

I'd suggest some of you who are having problems with Big Sur install/upgrade try that test, to see if you can confirm if your NVRAM is fully working or not.

Thanks for your help and feedback : I’m really embraced that their installation doesn’t work too.

I can't explain what's going on even with the new Big Sur process that works on others builds : the files seems to not be deployed ( correctly) on the destination disk ( reserved or update)

What to explore and check again : some ways :
- macOS Big Sur install app : I think 20B29 is better but now we have 20B50 : download it again ? ( I can help to get 20B29 or RC2 )
- the destination disk : NVme or SDD ( more or = to 128 GB) : use different ones ?
- yes Nvram : but I have already continued on the right track even with a bad one : try with Dartonia way for non native Nvram ?
- the SSDTs : for me if AWAC on DSDT you must put SSDT-AWAC see here. : Asrock X299 creator : #64 ?
- the config.plist: they checked it more than twice ?
But very strange in fact

 

[oli.mathieu]

Yeah I think this may be what happens with the installer - for some reason under certain circumstances it seems it fails to create the correct APFS volumes, I guess inc. the Preboot volume necessary to successfully complete an installation.

I agree

 

[rustEswan]

It is very strange...

for me SSDT-AWAC doesn't work because by changing the "STAS == 1" property, it flips the AWAC off and the RTC on and that conflicts with my RTC0 that has the correct memory ranges configured. If I just have my own SSDT-RTC0-RANGE then I do end up with AWAC and RTC0 but it seems to be working perfectly fine (apart from the installer of course)

This is my IOReg note the RTC0 device and correct memory ranges, but still the presence of AWAC...

I thought that AWAC just wasn't supported in MacOS rather than it actually interfered with and/or broke MacOS?

 

[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.