Contribute
Register

Gigabyte X299X - Catalina Support

Status
Not open for further replies.
Hi @Ellybz - I was wondering whether you might have a moment to help me understand a little more about using DeviceProperties, as you explained back in July:

If it is only a matter of cosmetic issue, I suggest you to use device properties in OpenCore vs SSDTs ( old school ).
Very simple and effective. You'll need Hackintool: PCIe section. Look for your device, right click to copy the device path and report the elements inside OC /DeviceProperties. If you want to add some vendor ID or other fields, you'll find them with IOReg. Check the exemples below and you should be all

I am still working on SSDTs for the Designare and I have started to use DeviceProperties instead of SSDT _DSM sections. I am following your method - look in Hackintool to get device path, and then specify the properties using DeviceProperties. I am copying the properties out of the SSDTs that dolgarrenan provided.

This seems to work well, at least in the few I've tested.

But I would like to understand this a bit better, and in particular to understand whether there any situations where I can't use DeviceProperties, and an SSDT must be used?

To put it another way: if I converted every _DSM section in my SSDTs to DeviceProperties in config.plist, would I run into any problems?

You said "if only a matter of cosmetic issue", which suggests that not every _DSM could convert to DeviceProperties?

And the OpenCore manual says:
"For all kernel drivers, which may inspect the IODeviceTree plane without probing (e.g. Lilu and its plugins such as WhateverGreen) it is particularly important to ensure device presence in the ACPI tables. Failing to do so may result in all kinds of erratic behaviour caused by ignoring the injected device properties as they were not constructed at the first stage."

Which also suggests the same. But I don't yet know how I can know which properties are OK to specify in DeviceProperties, and which must be in an SSDT?

The reason that I like the idea of DeviceProperties is that it only applies to macOS, and it allows the user to see everything in config.plist, rather than having to check between config.plist and SSDTs to see what's being set up.

I have had a look around for an example EFI that uses DeviceProperties in the way you described, but so far I have not found any. I found one example EFI from you (in the X299 BigSur thread), and also looked at lolflatsix's EFIs in the same thread, but neither had any DeviceProperties configured. dolgarrenan's EFI uses DeviceProperties to configure a couple of Thunderbolt devices, but the vast majority are configured via SSDT.

Thanks in advance for any advice.
 
Last edited:
My position has evolved since July. In some cases ( Thunderbolt, changing curve fans of a GPU, etc.. ) SSDTs were more efficient or easier to manage than DeviceProperties. The issue with SSDTs was that if you're not using OSX ( Windows, Linux, etc..) Your side OS might be prone to erratic behaviors because you're feeding it an OSX argument.

In the past, a user called NDK created a custom version of OpenCore adding a quirk to disengage SSDTs if you're not using OSX. I loved his approach. Unfortunately, the devs of OpenCore did not see eye to eye and refuse to add his quirk in their releases. I know that you can add the "IF" argument in SSDTs to restrict their loading exclusively to OSX but still..

As Hackintosh users, we are in some sense artists, pirates or pioneers , so we have to try different ways in approaching problem solving ( and not always follow what everyone says :lol: ). So, the only advice I can give you is: "If It bugs you, try something else" ;)

Since the last few months I got rid of all my SSDTs. I wanted my EFI to be as "Vanilla" as possible. Because my WU-8 does not need SSDTs for EC, RTC, AWAC to boot. ( Even with Big Sur ), I only used SSDTs for USBX & CPUPM, but I decided to get rid of them.

USBX:
The longest part was to map all my USB ports , Including TB & Inateck PCIe USB card , in my USBPorts.kext . After this was done, I incorporated the properties of SSDT-USBX in the kext, verified that the properties were loaded without the SSDT & got rid of that SSDT. This approach is explained here by @Loloflatsix :
What will you gain?
- Saying goodbye to SSDT-USBX
- No more 15 ports limits. (22 XHCI working ports on WU-8 )

PLUG ( XCPM ):
MacOS native power management is NOT mandatory. ( if it bothers you, think of it this way: If it was mandatory, the devs of OpenCore would have integrated it as part the bootloader , not as a separate SSDT. Performances are similar. Only differences can results in improper sleep, higher temperature or higher power consumption. If your Bios can handle XCPM properly ( it should ) & no bugs above are reported, you can get rid of it.

Thankfully, works great on my system ( 18c @ 4.9Ghz - 1.2Ghz in Idle : 6 Speedsteps ) . Sleeps/Wake also work.
Zero bug. Using it this way for the past 4 months.
Cinebench score in BS are above 10000pts but a bit lower than Mojave/Catalina ( 10400) . Still better than the 2020 MacPro 28cores.

PS: I'm using a Music Producer & I use my system for work under heavy loads 18/6 and and it is completely stable. Not a single KP.
Many tools exist to verify that your XCPM is working properly. Look it up.

I'm attaching my EFI below. ( Mojave /Catalina /Big Sur ). I do not use WIFI. I have a USB Key for bluetooth.
Airplay also works.

Today is Sunday so, relaxing day, I could respond to your post. I'm usually quite busy with work, so If don't respond in the future, thanks for understanding.
All my best and Good luck.

If you read all my thesis, kudos to you :lol:

Slot 1: IEEE1394
Slot 2: TB Alpine Ridge
Slot 3: RME Audio Card
Slot 4: Inateck KT5001
Slot 5: Asus Hyper M.2
Slot 7: GPU RX580
( All Recognized via Deviceproperties )

Screen Shot 2020-11-15 at 21.59.46.png
 

Attachments

  • Ellybz EFI OC063.zip
    2.8 MB · Views: 78
Last edited:
Wow, thanks so much @Ellybz for the detailed response. That's extremely useful.
Today is Sunday so, relaxing day, I could respond to your post. I'm usually quite busy with work, so If don't respond in the future, thanks for understanding.
All my best and Good luck.
I quite understand. I do have a few more questions, but please don't feel any urgency to respond. Your excellent post has given me plenty to research and test. And I think I should take the time to read the 75 pages of that Big Sur X299 thread, which I am sure will teach me even more.

My position has evolved since July. In some cases ( Thunderbolt, changing curve fans of a GPU, etc.. ) SSDTs were more efficient or easier to manage than DeviceProperties. The issue with SSDTs was that if you're not using OSX ( Windows, Linux, etc..) Your side OS might be prone to erratic behaviors because you're feeding it an OSX argument.

In the past, a user called NDK created a custom version of OpenCore adding a quirk to disengage SSDTs if you're not using OSX. I loved his approach. Unfortunately, the devs of OpenCore did not see eye to eye and refuse to add his quirk in their releases. I know that you can add the "IF" argument in SSDTs to restrict their loading exclusively to OSX but still..
Yeah, dolgarrenan was using that NDK fork. It's a big shame that the OC developers decided not to integrate those changes, because it would simplify a lot of things. I kind of understand their reasoning - that SSDTs should be set up correctly - but that doesn't account for ACPI patches, and my understanding is that not all ACPI patches can be converted to SSDTs. Or at least, not necessarily in a simple way.

Even when they can be it's extra work and not everyone understands how, myself included at the moment. It feels to me that it could save a lot of users a lot of effort if OpenCore could be optionally configured to only apply SSDTs and ACPI Patches to macOS. Oh well!

I went through all my SSDTs and added those IF statements and that generally seems to work OK. I don't think I've done it perfectly, as I didn't understand exactly where I needed to put the IF, so I basically surrounded the whole of each SSDT in an IF _OSI ("Darwin") { ... }. That's not how the Dortania SSDTs do it, but it does seem to work - I can dual-boot Windows and macOS.

However dolgarrenan's config also had a lot of ACPI patches, which I think he sourced from KGP's original config. Having all those patches in config.plist would always break Windows boot. Many I think were cosmetic, changing names to resemble a real Mac Pro 2019, like FPU -> MATH and renaming the CPUs to start FP. Those could be removed fairly easily.

But at least one has proved stubborn: renaming _DSM to XDSM. Without this patch I have been unable to load dolgarrenan's XHC SSDT, as it applies a _DSM on several USB devices, and this triggers an AE_ALREADY_EXISTS error because that/those device(s) already have a _DSM in the system DSDT.

Then I found that I could still boot Windows even with the _DSM -> XDSM ACPI rename, so currently that is the one ACPI patch I still have enabled.

But like you said I would much prefer a 'clean' EFI that changes nothing for Windows. Hence my starting to look at DeviceProperties instead, so I can try and avoid using _DSM in any SSDT.

As Hackintosh users, we are in some sense artists, pirates or pioneers , so we have to try different ways in approaching problem solving ( and not always follow what everyone says :lol: ). So, the only advice I can give you is: "If It bugs you, try something else" ;)
Yeah, this has caused me some confusion. I've been unsure as to what the 'right' solution is, but recently have realised there likely isn't a single correct answer, but instead various different configuration options and styles, many of which could work OK.

To be clear, I don't have a problem with using SSDTs in general. What I ideally want to achieve is a config that is perfect in both macOS and Windows. So I'd definitely like to avoid ACPI patches, given that OpenCore will apply these to all operating systems.

I don't mind a few SSDTs because they can have that IF statement. But if the SSDT then requires an ACPI patch - like the XHC SSDT currently does - then yes I would like to get rid of it, even when that ACPI patch seems to boot Windows OK (who knows what issues there could be in Windows that won't show up until much later.)
Since the last few months I got rid of all my SSDTs. I wanted my EFI to be as "Vanilla" as possible. Because my WU-8 does not need SSDTs for EC, RTC, AWAC to boot. ( Even with Big Sur ), I only used SSDTs for USBX & CPUPM, but I decided to get rid of them.
Yours is the first EFI I have ever seen with zero AML files! This is really cool and very interesting.
USBX:
The longest part was to map all my USB ports , Including TB & Inateck PCIe USB card , in my USBPorts.kext . After this was done, I incorporated the properties of SSDT-USBX in the kext, verified that the properties were loaded without the SSDT & got rid of that SSDT.
What will you gain?
- Saying goodbye to SSDT-USBX
- No more 15 ports limits. (22 XHCI working ports on WU-8 )
This is really cool. I had not realised this was possible. I'm definitely going to try this method, so I can remove that XHC SSDT which should allow me to also remove the _DSM -> XDSM ACPI patch.
PLUG ( XCPM ):
MacOS native power management is NOT mandatory. ( if it bothers you, think of it this way: If it was mandatory, the devs of OpenCore would have integrated it as part the bootloader , not as a separate SSDT. Performances are similar. Only differences can results in improper sleep, higher temperature or higher power consumption. If your Bios can handle XCPM properly ( it should ) & no bugs above are reported, you can get rid of it.

Many tools exist to verify that your XCPM is working properly. Look it up.
This covers another thing I had not understood. I was asking earlier in this thread: "what does it actually mean to have power management working?"

When I first booted with the config in the OP, I did not have XCPM working, at least according to Dortania's definition: I did not have X86PlatformPlugin attached to the first core. But then when I looked in HWMonitor and Intel Power Gadget, I could see the cores were adjusting their speed from 1200Mhz up to 4600Mhz, and that the fans were spinning up and down according to load, etc.

So I didn't really understand what would be different if power management was 'working'.

I will Google those sources you mentioned to confirm whether power management is functional, and will try them with and without the PLUG SSDT.

My current thought is that if there is no downside to it, I will still have the PLUG SSDT installed, with the IF to prevent loading in Windows. But I'd definitely like to understand better how PM works with and without X86PlatformPlugin.

Thankfully, works great on my system ( 18c @ 4.9Ghz - 1.2Ghz in Idle : 6 Speedsteps ) . Sleeps/Wake also work.
Zero bug. Using it this way for the past 4 months.
Cinebench score in BS are above 10000pts but a bit lower than Mojave/Catalina ( 10400) . Still better than the 2020 MacPro 28cores.
Very nice! Currently the best I can achieve with my AIO is 18c @ 4.6Ghz, but I have ordered parts for a full custom water loop which will be with me in a week or so I hope (all parts coming from Germany), and I hope then I can get at least 4.8, maybe 4.9.

Speaking of sleep/wake, do you happen to know any more about why we need AppleXcpmCfgLock on our Gigabyte motherboards?

I have confirmed that CFG LOCK is definitely unlocked via VerifyMsr, and I even tried the UEFITool patching method (with Modified Grub Shell) to set it to 0x00 just in case.

Which makes me wonder : could it be that there's some other variable that's still locked, and which could be unlocked via UEFITool?

Again it would be great to have things as 'clean' as possible, meaning it'd be nice to be able to disable AppleXcpmCfgLock if there was some way to patch the BIOS to make it unnecessary. The docs describe it as a hack, and the fewer hacks the better it seems to me.

Have you or anyone done any testing or research on that for GB motherboards?

Slot 1: IEEE1394
Slot 2: TB Alpine Ridge
Slot 3: RME Audio Card
Slot 4: Inateck KT5001
Slot 5: Asus Hyper M.2
Slot 7: GPU RX580
( All Recognized via Deviceproperties )
Really cool, and exactly what I hoped would be possible.

Final question: I see you are using iMacPro SMBIOS. Can I ask what makes you decide to use that vs Mac Pro 7,1? Is there any clear pro/con to choosing either? Or is it more a case of personal preference?

I am on Mac Pro 7,1. I chose this because a) Dortania's SMBIOS guide lists Mac Pro 7,1 as a "Cacade Lake-W" system, versus Skylake-W on iMacPro, and my system is Cascade Lake X, and b) I felt that Mac Pro better fits our hardware, both in terms of performance (when overclocked) and upgrade-ability.

But I see a number of users, yourself included, using iMacPro, which makes me wonder if there's some reason I should consider using that instead?

If you read all my thesis, kudos to you :lol:
No, kudos to you for the great explanation! Thank you again for taking the time to explain all this to me, it's been super helpful.
 
Last edited:
I'm sorry you're having such trouble. I can't really understand what's happening.

First, I had to modify some things in the EFI to make the scripts run (as it would do nothing initially).

The only thing that should have needed editing in the EFI is the SMBIOS, filling in your serial number etc, where I wrote "CHANGEME". When you say you edited it, what did you change exactly?

In the end, my windows OS somehow also was also damaged due to the opencore corruption. This I couldn't make sense of as they are installed on seperate SSD's. But it took it down with it.

Did you remember to clear NVRAM on your first boot with the new EFI? It's the last option in the OpenCore boot menu.

In what way exactly was Windows damaged? And how were you trying to boot it? Remember that the EFI I uploaded cannot boot Windows from the OpenCore boot menu. Windows has to be booted from the BIOS Override Menu. Attempting to boot Windows from OpenCore using the EFIs so far uploaded to this thread (mine, dolgarrenan's, etc) will quickly fail with an ACPI_BIOS_ERROR blue screen, on account of both the ACPI patches and the SSDTs, which OpenCore will apply both to macOS and Windows.

If Windows fails on boot too many times it can then cause future Windows boots to bring up the "Repairing Windows" menu (can't remember the exact name), but in that menu you can just choose to reboot and then subsequent boots will work fine - at least if they're done from the BIOS Boot Override menu.

I do now have an EFI that can dual-boot macOS and Windows, directly from the OpenCore boot picker, but I've not posted it yet as I'm still working on refining the SSDTs. Later today I will upload in its current state, which at least can dual-boot Windows.

However, it would post an airport message (i'm assuming referring to the airport kexts) and this would make the computer endlessly reboot.
I've definitely not seen that problem. The only Airport kext is AirportBrcmFixup, which is only of any use if you have replaced your WiFi mini-PCIe card with a Broadcom model.

You could just disable this kext if it did seem to be causing problems.

However I've booted with AirportBrcmFixup enabled many times - without having a Broadcom WiFi installed - and it doesn't cause any issues for me at all; the kext just doesn't load if the device isn't found. So maybe it's another problem.

In this sort of situation it would be useful to get a photograph or video of the errors so we can help debug. Also, if the reboot is caused by a kernel panic, there's an OpenCore setting that gives you a log of that panic in your EFI partition, in a file called panic-<date>.txt.

I think I had that enabled in the EFI I uploaded, but I'll make sure it's definitely enabled in the next EFI I upload.

It then ran the scripts and tried to do the installation at boot (with verbose enabled I could see the scripts running correctly).
What do you mean by 'scripts'? The SSDTs?

Were you doing a fresh installation of macOS? Or booting an existing install? I haven't actually tested a new installation of macOS, so I can't 100% confirm that works. But I'd be quite surprised if it didn't. I have done several upgrades (eg Catalina security update, and Catalina -> BigSur) using this EFI, and they were successful.

What version of macOS were you installing / attempting to run?

Do you have any extra PCI devices installed, besides the GPU?

If you upload the exact EFI you had these issues with, I will look at it and try it on my system and try and work out what was causing you all these problems.

Later today I will upload my current EFI. It's not complete yet but it is working well for me, and can now dual-boot Windows direct from OpenCore.
 
Last edited:
INTERIM EFI - GB Designare 10G - OpenCore 0.6.3 - Windows and macOS Dual Bootable

Here's my current EFI file. It is not yet complete as I would like it, as I plan to do a lot more changes to SSDTs and DeviceProperties, along the lines of what I was discussing with Ellybz.

But it's working OK for me, and unlike previous EFIs should work fine for dual booting Windows and macOS (and probably Linux too - untested) directly from OpenCore.

EFI summary / changes compared to previous EFI:
  1. Dual boot with Windows, direct from OpenCore boot picker, tested and working.
  2. Working power management, via fixed SSDT.
  3. Working sleep, via disabling cosmetic properties for SBUS.
  4. Working wake, via enabling AppleXcpmCfgLock.
  5. Set BootProtect=BootStrap, which creates a permanent OpenCore boot option, preventing Windows upgrades from breaking OpenCore boot
  6. All ACPI patches removed, except for _DSM -> XDSM which remains required for the XHC SSDT. I hope to remove this patch also in future. This patch does not seem to affect Windows.
  7. SSDTs edited so they didn't require the ACPI Patches included in dolgarrenan's config.
  8. SSDTs edited to include IF statement such that they only load in macOS.
    1. I don't think I've done this in the ideal way, as for many SSDTs I just surrounded the whole SSDT in a big IF statement. But it does seem to work. I'll work on improving this later.
  9. DeviceProperties used to inject cosmetic properties for a couple of devices, namely Intel X550 NICs and Intel AX200 WiFi. These values were then removed from the appropriate SSDT.
    1. This is a work in progress - in future I plan to have most or all such properties set via DeviceProperties, not SSDTs.
  10. All kexts upgraded to their latest versions.
  11. Added driver kexts for:
    1. SmallTree Intel NIC drivers, version 3.8.6 patched
      1. If you already have this installed in /L/E, you can disable the kext in config.plist.
    2. AirportItlwm, providing basic (slow) WiFi on our included Intel AX200 WiFi card, with some Continuity support - namely Shared Clipboard and Handoff.
      1. Disabled in config.plist by default, and requires Secure Boot to be enabled for it to work - see instructions below.
      2. I've not managed to get Handoff or Shared Clipboard working yet myself. But basic WiFi does work.
  12. Organised kexts into two folders: Acid for Acidanthera kexts, Other for everything else.
  13. All Acidanthera kexts are DEBUG versions, allowing debug to be enabled via boot-args. Debugging is not enabled in the current config.plist.
    1. To enable logging for all Acidanthera kexts at once (will be very verbose), add -liludbgall boot arg.
    2. To enable logging for an individual kext, check its GitHub page for the arg to use. For example, WhateverGreen is -wegdbg.
  14. OpenCore is also DEBUG, and debugging IS enabled, via Target setting. Currently it will log to disk, but not to screen (screen debugging slows down boot a lot.) Change Target to 0to disable all logging.
    1. However I recommend it's left enabled until the EFI is confirmed working for you.
    2. I added an XML comment describing various options for the Target setting, eg for enabling logging to screen, to disk or both.
  15. Added numerous comments throughout the file, both in comment sections and as XML comments. These comments explain the purpose of the SSDTs, kexts and DeviceProperties, and give some information on a few OpenCore configuration values.
Instructions for use.
  1. Edit the config.plist to change the three CHANGEME values in PlatformInfo -> Genericto match your current SMBIOS values.
    1. The SMBIOS is set up for MacPro 7,1. It should work fine on iMacPro 1,1 also, but I've tested primarily on MacPro 7,1. If you want to use iMacPro 1,1 you'll need to edit the SystemProductName also.
  2. No other changes should be needed in the EFI to boot.
    1. If you find you need to change something else, then something is probably wrong. Check your BIOS settings (I uploaded a basic F3C BIOS config a few days ago), and/or report back.
  3. On the first boot, clear NVRAM via the last option in the OpenCore boot picker. This will trigger a reboot. After the system comes back up you can then launch macOS from OpenCore.
    1. Do not attempt to boot macOS without clearing the NVRAM first, as it may fail. You shouldn't need to clear NVRAM again after this.
  4. As discussed before, never boot OpenCore from the F12 boot menu, BIOS Boot Override menu, or after having been in the BIOS and "Exit Without Saving".
    1. The one exception is if you need to boot OpenCore from a USB drive, eg because your main SSD/NVMe config is broken. Trying to boot with two OpenCore EFIs visible will trigger the boot issue.
    2. In this scenario, boot the USB from the Boot Override menu. The first boot will fail after 10 second, then you can try again and it will succeed. RAM will go down to 2666Mhz and any CPU overclock will be temporarily disabled.
    3. As soon as you're ready to boot normally again from NVMe/SSD, remove the USB stick, go into the BIOS and hit F10 to re-apply BIOS settings, then let OpenCore boot normally.
  5. I would strongly recommend to test with an existing macOS Catalina installation, and not to try either a new install, or Big Sur, at least not until you've confirmed everything works on an existing Catalina install.
    1. Failed boots should not be able to break your existing macOS install - at least not in Catalina and prior versions of macOS. BigSur may be a bit different due to its filesystem changes.
    2. I've had hundreds of failed boots over the years, in both Clover and OpenCore, and I'm still using the same macOS install I've had since 2015.
    3. I believe BigSur will work with this config - though it might require SecureBootModel as described below - but I've not yet really tested it.
  6. I would recommend to test the first boot without a Windows SSD installed, to simplify things. It shouldn't affect anything, but keep things simple on the first try.
    1. Once macOS is confirmed working, the Windows SSD/NVMe can be re-added, and Windows boot can be tested from the OpenCore boot menu.
  7. To set macOS as the default boot option within OpenCore, launch it from the OpenCore boot picker with Control-Enter.
  8. In order to install Big Sur or upgrade to it I believe you will need to change SecureBootModel to Default, or j160 (for MacPro 7,1 SMBIOS). There is a comment in the config file explaining a bit more about this.
  9. AirportItlwm is disabled. If you enable it, you must first change SecureBootModel, as described in point 8; AirportItlwm will not load unless a Secure Boot is done (or if IO80211 is injected, but I have not configured for that in this EFI.)
    1. I would do all testing with AirportItlwm disabled, and only enable it if a) you still have the original Intel AX200 WiFi installed, b) you want to use WiFi, and c) you've confirmed you can boot macOS OK without it.
  10. If/when you're happy that everything is working, you can disable all DEBUG logging by changing Target to 0. You could then optionally replace the OpenCore install with the RELEASE version.
  11. If you get a kernel panic on boot, the text of the KP will be logged to /Volumes/EFI/panic-*.txt, which can be very useful for debug.
  12. Note that if you boot the EFI from a USB stick rather than NVMe:
    1. Ideally you don't want to do this if there is also an OpenCore EFI on the NVMe/SSD, as otherwise you'll hit the usual boot failure BIOS issue. If you need to anyway, see point 4.
    2. With the current config.plist debug settings, boot will be VERY slow. This is due to the logging to disk being very slow on USB. It may take several minutes, including some time at a black screen before the boot picker appears. Just be patient, it is working.
    3. If you want to test from USB and the delays get too annoying, change Target to 0 on the USB EFI.
If you get problems, try to take photos and/or videos of the boot process and upload them here. Also get the latest /Volumes/EFI/opencore-*.txt log files (which will be created when Target = 65, as it is in the provided EFI) and upload them here. Ditto any /Volumes/EFI/panic-*.txt files.

Good luck! Do report back if you get any problems, and include as much debug information as possible.
 

Attachments

  • TheBloke.OpenCore.0.6.3-DEBUG.EFI.17112020.zip
    73.5 MB · Views: 116
Last edited:
Ok, now we need to get rid of all possible SSDT's, yeah!!! That's wonderful lol ;) I like this approach thou. I am amazed how fast all the hackintosh world can change with a simple change your systems boot, now it does not ;)

I have got a lot work to do in my hackintosh now. Thanks everybody! Wonderful people here!
 
Unfortunately I didn't have much time over the last week or so, but I'm quickly reporting in with my current situation.
I took a look at the EFI @TheBloke posted and merged it with my own as much as possible. We're running relatively similar setups anyway, so it worked out alright.

I'm now booted into the latest Big Sur release (11.1) without any problems. All kexts appear to work fine. I did an in-place upgrade to the newest OS release (starting from one of the Dev Betas) and the upgrade process went off without a hitch, too.

My ethernet is also now working fine without any hiccups. Turns out that the powerline adapter I was using had some setup problems that resulted in a weird situation where directly connecting to it would put my ethernet controllers into a broken state, but connecting it to a router and then connecting my Hackintosh to that would work. I've fixed those now (by resetting it and reconfiguring the adapter), and since then I haven't had any further issues with Ethernet.

Still running iMacPro1,1 which seems to do me well thus far, no complaints.

I've done a bit more digging on the bios reset thing, but so far no new information has turned up. I'll keep looking into it when I have time, maybe there's something we can do to fix it, but chances remain slim.
 
Ok, now we need to get rid of all possible SSDT's, yeah!!! That's wonderful lol ;) I like this approach thou. I am amazed how fast all the hackintosh world can change with a simple change your systems boot, now it does not
Yup lots to learn! I'm not sure I'll end up removing all SSDTs. But I'm definitely interested to see how Ellybz achieved that. As he said, there's lots of different ways to do things, and not necessarily one 'correct' way.

I do like having cosmetic stuff configured via DeviceProperties, as it's all immediately visible in the config.plist. Just seems cleaner that way.

What I'm yet to really understand is whether it matters what devices are called from an ACPI level. To take one example - our X550 NICs. Using dolgarrenan's SSDTs, they get renamed to XGBE and XGBF. If that SSDT is not loaded, they're called ethernet1 and PXSX (I think).

So what I'd like to know is.. does that matter? Is there any benefit to having them called the same thing at an ACPI/IoReg level as they would be on a real Mac?

Knowing that would help to understand how important it is to have SSDTs/DeviceProperties/etc. Whether it actually matters for functionality, or if it's just a nice-to-have.

I'm now booted into the latest Big Sur release (11.1) without any problems. All kexts appear to work fine. I did an in-place upgrade to the newest OS release and the upgrade process went off without a hitch, too.
Good to hear. Have you enabled SecureBootModel for BigSur? I'm a bit unsure about that. Dortania's guides seem to indicate it's practically required, at least for install and updates. But then Ellyby's BigSur config had it Disabled.

I just ordered one of the new AMD 6800 GPUs, so I'll need to upgrade to BigSur 11.1 in order to use that.

I've done a bit more digging on the bios reset thing, but so far no new information has turned up. I'll keep looking into it when I have time, maybe there's something we can do to fix it, but chances remain slim.
Yeah, I don't think we're going to get anywhere without some expert/developer help. To that end I posted in an official OpenCore thread on another site. I won't link it as it'll probably get flagged or something. As I rather feared, no responses after several days.

My feeling is that it's definitely a BIOS bug - or at least a BIOS peculiarity - and may well require a special quirk/tweak, ie one that doesn't yet exist. Meaning an OpenCore dev would have to write it. And will they be interested to do that if it only affects this one board? Probably not.

I will keep asking around and might approach an OpenCore developer directly. But mostly I'm resigning myself that we'll just have to live with it. At least it never effects normal booting. It only affects me when I need to boot from USB instead of NVMe, and that's rare now that I've got my config mostly working. And even if I do need to boot from USB, I can do so with only one extra reboot. So it's not the end of the world.

By the way, I'd highly recommend that you all familiarise yourself with OpenShell, and make sure it's enabled in your config. It's very useful for making quick changes and fixes to your config.plist.

For example: you want to test a new or different config.plist setting. On another motherboard you'd probably test this on USB, so as to leave your NVMe config unaffected. But that's a pain on this board, because of the boot failure issue. So instead you go ahead and change it directly on the NVMe. You try and boot, and the boot fails because of the new config.

Now, instead of reverting to your USB backup (and the extra reboots and BIOS F10 required by the boot failure issue), instead you can boot into OpenShell, from the OpenCore menu on your NVMe EFI.

Load OpenShell from OpenCore, then:
  1. Type fs0: or fs1: depending on whether your EFI is on the first or second NVMe/SSD. If
  2. Type cd EFI\OC
  3. Now you can copy files around, eg to restore a backup.
  4. So if you kept a backup of your config.plist from before you tried the most recent change, you can do something like: cp good.config config.plist to overwrite config.plist with your backup copy (called 'good.config' in this example).
    1. It will prompt you to confirm the overwrite with Y
  5. Or, you can directly edit your config with edit config.plist
    1. Here you can make quick text changes, change a 'true' to 'false' or whatever
    2. In the editor, the most important hotkeys are:
      1. Control-E = get help, which lists all the hotkeys
      2. F1 = go to line number
      3. F2 = save
      4. F3 = exit
      5. F4 = search
  6. When you're done, type reset and the system will reboot, and your restored/edited config will activate.

If you get into the habit of making a quick backup of your config.plist within the same EFI folder prior to making any change, it's quick and easy to revert that change via OpenShell. Or for small text changes you can edit them in yourself.

I now use this method quite often when I want to try new changes. It saves having to put up with the boot failure any time I try and boot from USB. It's not quite as good as having Clover's built in config picker and parameter editor, but it's quicker than having to reboot multiple extra times because of the boot failure, and keep having to re-apply BIOS settings each time that happens.
 
Good to hear. Have you enabled SecureBootModel for BigSur?
Yeah, I'm running with the SecureBoot value for iMacPro1,1 and it seems to be working just fine. The Airport kexts also work, but personally I don't use them much so currently they're disabled.

For example: you want to test a new or different config.plist setting. On another motherboard you'd probably test this on USB, so as to leave your NVMe config unaffected.
The thing that I do when testing EFI changes multiple times in a short time period is to go into the BIOS and disable all boot options except for my USB stick. That way I can unplug, change and re-plug without having to go through the BIOS/boot menu, circumventing the issue entirely. Once I'm done I copy the EFI to my actual drive and reenable it in the BIOS.
 
The thing that I do when testing EFI changes multiple times in a short time period is to go into the BIOS and disable all boot options except for my USB stick. That way I can unplug, change and re-plug without having to go through the BIOS/boot menu, circumventing the issue entirely. Once I'm done I copy the EFI to my actual drive and reenable it in the BIOS.
Ah yeah that's a good idea, I'll have to try that if I find myself iterating a lot on config again.

One reason I prefer NVMe boot is for the verbose logging. I found I had to turn off OpenCore debug for USB because it was just so slow. So I prefer to boot from NVMe if possible so I can keep OC logging enabled.

But yeah, when lots of changes are being tried it's nice to use USB which allows for adjusting the config on a second machine while the main is unavailable.
 
Status
Not open for further replies.
Back
Top