Gigabyte Z490 Vision D (Thunderbolt 3) + i5-10400 + AMD RX 580

[santitf]

Open your config in OpenCore Configurator, "Device Properties".
Add new device: PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)
Set properties:

name	Data	23646973706C6179
IOName	string	#display
class-code	Data	FFFFFFFF

A few days and all is working fine.
Only a question about saving electricity: my system uses 75W in idle. If I disconnect the GPU pcie cable attached to my 3060ti, the consume down to 38W in idle (almost double the consumption).
Is there any alternative to don't unplug the pcie cable using OC settings/SSDT,...?

 

[emistral]

Some questions:

• Is the Windows boot problem happening with OpenCore 0.6.1 or 0.6.2?
• Are you sure that the computer is booting from the correct disk? We can check the boot disk priority in BIOS --> Boot
• The solution to ACPI_BIOSerror was to ensure that all SSDTs are conditionally injected only into macOS.
  • We do this by adding this to each SSDT: If (_OSI ("Darwin")) { then do Mac stuff }
• I can check your SSDTs if you compress and post the OC/ACPI folder.

@CaseySJ to answer your questions:
1. Windows problem started with 0.6.2
2. In the BIOS I am booting from opencore. Sequence is Opencore, then windows 10 then UEFI Samsung (which is the main NVME where the OC EFI is (same as first in boot sequence). How does OC pick up the disk to boot? is it dynamic or static? I mean if I have a windows 10 disk, then swap it for another windows 10 disk, does Oc pick the right disk or does it maintain a static entry of the previous disk and would eventually fails if it tries to boot from that disk?
3. See attached. Note that those are aml from 0.7.2 release that you posted a while ago. I have not transitioned to 0.7.3 yet. About to do it today.
I had a quick look at some of the SSDT but the use of if (_OSI("Darwin")... is a bit inconsistent. some of those SSDT have the if statement for instance inside a method, some have the if statement encapsulating methods and code, some have no if statement, etc.
I would expect the if statement to be the first thing at the beginning of the SSDT?
The ones that looked weird to me are:
- SSDT-EC
- SSDT-DTPG
- SSDD-DMAC
- SSDT-AWAC

Also I compared some SSDT in 0.6.1 to 0.7.2 and the following ones did not have the if statement in 0.6.1:
- GPRW
- PLUG
- MCHC
- TB3HP
- UIAC V2

 

[Ayvan]

A few days and all is working fine.
Only a question about saving electricity: my system uses 75W in idle. If I disconnect the GPU pcie cable attached to my 3060ti, the consume down to 38W in idle (almost double the consumption).
Is there any alternative to don't unplug the pcie cable using OC settings/SSDT,...?

I think, it's normal idle power consumption for GPU and GDDR memory on minimal frequncies... I don't know how to reduce it using software methods like SSDT or settings/kexts.

 

[jimbojingle]

What errors are you seeing? Do they begin with OCS: ?

Yes they do.

I attach a screenshot.

 

[CaseySJ]

Yes they do.

I attach a screenshot.

This indicates a mismatch between config.plist and OpenCore. Nearly every version of OpenCore has introduced some changes to config.plist, which means we cannot mix-and-match config.plist with any version of OpenCore.

Simply right-click on EFI/OC/OpenCore.efi and select Get Info. Then check the Created date. If it's September 6, then you have OpenCore 0.7.3.

Your config.plist is most likely formatted for OpenCore 0.7.3, but you may be running an earlier version of OpenCore.

 

[CaseySJ]

@CaseySJ to answer your questions:
1. Windows problem started with 0.6.2
2. In the BIOS I am booting from opencore. Sequence is Opencore, then windows 10 then UEFI Samsung (which is the main NVME where the OC EFI is (same as first in boot sequence). How does OC pick up the disk to boot? is it dynamic or static? I mean if I have a windows 10 disk, then swap it for another windows 10 disk, does Oc pick the right disk or does it maintain a static entry of the previous disk and would eventually fails if it tries to boot from that disk?
3. See attached. Note that those are aml from 0.7.2 release that you posted a while ago. I have not transitioned to 0.7.3 yet. About to do it today.
I had a quick look at some of the SSDT but the use of if (_OSI("Darwin")... is a bit inconsistent. some of those SSDT have the if statement for instance inside a method, some have the if statement encapsulating methods and code, some have no if statement, etc.
I would expect the if statement to be the first thing at the beginning of the SSDT?
The ones that looked weird to me are:
- SSDT-EC
- SSDT-DTPG
- SSDD-DMAC
- SSDT-AWAC

Also I compared some SSDT in 0.6.1 to 0.7.2 and the following ones did not have the if statement in 0.6.1:
- GPRW
- PLUG
- MCHC
- TB3HP
- UIAC V2

Some questions:

• Have you enabled AppleVTD by deleting your existing DMAR SSDT and replacing it with SSDT-DMAR? If so, some users encounter problems when booting Windows through OpenCore.
• So if AppleVTD is enabled, please try disabling it by following the procedure at the bottom of this post.

 

[jimbojingle]

You are right. opencore.efi is dated May 21. I used an EFI Folder that I was given suitable for my Motherboard for use for conversion from Clover to OpenCore so the contents are all be dated May 21.

What's the best way to update so all is compatible? I've not used an old EFI before!

 

[CaseySJ]

You are right. opencore.efi is dated May 21. I used an EFI Folder that I was given suitable for my Motherboard for use for conversion from Clover to OpenCore so the contents are all be dated May 21.

What's the best way to update so all is compatible? I've not used an old EFI before!

Instead of upgrading OpenCore, let's try downgrading config.plist back to 0.6.2.

Reason: The upgrade from OC 0.6.2 to OC 0.7.3 is significant and non-trivial. It affects nearly everything.

To downgrade config.plist back to 0.6.2, let's try this:

• Backup the current config.plist
• Download OpenCore Configurator 2.15.2.0 by clicking here
• After running this version of OpenCore Configurator, ignore any messages about updating OpenCore Configurator -- it is necessary to use version 2.15.2.0 only
• Every release of OpenCore Configurator supports two and only two versions of OpenCore
• We must therefore make absolutely sure that it is set to the right version
• Here's how: Set it to 0.6.2 Release Version as follows:

• Now open your config.plist and click through the headings on the left side without making any changes:
  • ACPI
  • Booter
  • DeviceProperties
  • Kernel
  • Misc
  • NVRAM
  • PlatformInfo
  • UEFI
• Save the file. Try booting now.

WARNING: There is a fair chance this will not work. It would be much safer to find the ORIGINAL config.plist from OpenCore 0.6.2 that you used before. It should still exist in the EFI partition of your full system backup disk.

 

[jimbojingle]

Instead of upgrading OpenCore, let's try downgrading config.plist back to 0.6.2.

Reason: The upgrade from OC 0.6.2 to OC 0.7.3 is significant and non-trivial. It affects nearly everything.

To downgrade config.plist back to 0.6.2, let's try this:

• Backup the current config.plist
• Download OpenCore Configurator 2.15.2.0 by clicking here
• After running this version of OpenCore Configurator, ignore any messages about updating OpenCore Configurator -- it is necessary to use version 2.15.2.0 only
• Every release of OpenCore Configurator supports two and only two versions of OpenCore
• We must therefore make absolutely sure that it is set to the right version
• Here's how: Set it to 0.6.2 Release Version as follows:

View attachment 529555View attachment 529556
View attachment 529557

• Now open your config.plistand click through the headings on the left side without making any changes:
  • ACPI
  • Booter
  • DeviceProperties
  • Kernel
  • Misc
  • NVRAM
  • PlatformInfo
  • UEFI
• Save the file. Try booting now.

WARNING: There is a fair chance this will not work. It would be much safer to find the ORIGINAL config.plist from OpenCore 0.6.2 that you used before. It should still exist in the EFI partition of your full system backup disk.

Thanks for this.

The system I had previously was running High Sierra and Clover Bootloader and I am trying to upgrade to Big Sur and OpenCore so I only have an old config.plist from my original Clover setup and a new EFI Folder for my motherboard that I managed to find which is Big Sur compatible.

 

[CaseySJ]

Thanks for this.

The system I had previously was running High Sierra and Clover Bootloader and I am trying to upgrade to Big Sur and OpenCore so I only have an old config.plist from my original Clover setup and a new EFI Folder for my motherboard that I managed to find which is Big Sur compatible.

Is the new EFI folder (that you managed to find for your motherboard) also Clover-based?