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

[HenryM]

This is being posted from my Z490 Vision D running Windows 10. This is the same Hackintosh with SSDT-DMAR enabled. Are you using the correct version of SSDT-DMAR?

In BIOS, I have also changed Boot --> Windows 8/10 --> Windows 8/10 Features (instead of Other OS).

Ok, I was able to solve the problem by creating my own SSDT-DMAR.aml, and I think it's because we use different BIOS versions. (I’m using F20.) Now everything is working fine and i can boot into Windows. In the screenshot you can see the differences between our dmar-files (left is yours, right is mine). Thanks again.

 

[suren6791]

Ok, I was able to solve the problem by creating my own SSDT-DMAR.aml, and I think it's because we use different BIOS versions. (I’m using F20.) Now everything is working fine and i can boot into Windows. In the screenshot you can see the differences between our dmar-files (left is yours, right is mine). Thanks again.

View attachment 524487

I am also on F20 because I was using Rocket Lake before and had no issues going into Windows using Casey's SSDT. Glad that your method is working

 

[dsingh]

I can also confirm the same:

• On Big Sur and Monterey it is not necessary to use FakePCIID or modify Device ID to enable i225-V Ethernet port. Using boot argument dk.e1000=0 is sufficient.
• On Monterey, however, the i225-V port does not connect, but this may be specific to my Z490 Vision D. Things tried:
  • Deleting NetworkConfiguration.plist file
  • Enabling and disabling AppleVTD
  • Switching from DHCP to DHCP with Manual IP
• All of these configurations work in Big Sur using same EFI and same Z490 Vision D system. I will just wait for next Monterey Public Beta.

Did you try a fresh install of macOS? Also did you try connecting the Ethernet to another router in case you have spare one lying around?

 

[descry]

Are you booting from EGPU or IGPU? try switching your display to other ports and see if it helps. Also did you use the Intel EFI?

used the intel efi, booting from iGPU...tried to the mobo display but didnt work

Some questions:

• What are you trying to upgrade?
  • Older version of OpenCore to newer version of OpenCore?
  • Catalina to Big Sur?
  • Both OpenCore --> to --> new OpenCore and Catalina --> to --> Big Sur?
• If you updated OpenCore first, was the new OpenCore EFI folder able to boot Catalina?
• If Big Sur is not booting, have you tried pressing and releasing CMD-V at the OpenCore Boot Picker to enable verbose mode, then selecting the Big Sur boot disk?

1. older version of OC to newer version
2. Catalina upgrading to Big Sur


-i upgraded both at the same time. meaning i didnt reboot with the new OC and just hit upgrade
-ill try verbose

 

[dsingh]

Ok, I was able to solve the problem by creating my own SSDT-DMAR.aml, and I think it's because we use different BIOS versions. (I’m using F20.) Now everything is working fine and i can boot into Windows. In the screenshot you can see the differences between our dmar-files (left is yours, right is mine). Thanks again.

View attachment 524487

I use rEFInd which boots into either OpenCore or Windows or any other Linux distros I have. Since it bypass OpenCore while booting into any other OS I can turn on any fancy features in Bios temporarily which doesn’t affect macOS at all. I also added scan policy which ignore Windows partition in OpenCore Picker so I only see macOS related stuff. Since each OS use their own boot loader, it give me full flexibility for all OSes, I don’t have to worry about breaking anything while experimenting on any of the OSes.

 

[RandC]

This starts to be a long story with many trials... but that's the beauty of Hackintosh !

- When I boot with fresh EFI OC 0.71 from your Mini Guide with a USB key initial boot is OK as I can start to load the OS.
Then when I reach login screen on BS or Monterey no more mouse (I see immediately that the mouse is disappearing during the boot process as the mouse has lightning inside that goes off).
And then at loginscreen I see that keyboard is no longer working. Furthermore, no USB port are available.
The Os try to find Bluetooth keyboard and mouse but obviously does not find any.


- Yes XHCI Handoff is enabled.

Basically I boot with the same BIOS settings for my existing working 0.70 EFI updated to 0.71 AND with the freshly created EFI OC 0.71 from your mini Guide.
One give me fully functioning mouse.
The EFI created with your mini Guide OC 0.71 leads to mouse/keyboard/USB ports not working.
If you put that EFI on a dedicated hard drive and not a USB key same problem occurs.
That's why I am really confused...

EDIT: To further investigate I created again from your Mini Guide a fresh EFI OC 0.70 USB key... and Boot is fine, keyboard, mouse and USB Ports are OK.
Therefore I feel there are some changes somewhere between EFI 0.71 and EFI 0.70 that leads to non working USB ports when you boot from fresh 0.71 EFI. This does not occur when you update your 0.70 EFI to 0.71 one.

Hope I have been clear enough, as it is not always easy to describe the problem and things investigated

I'm having the same problem. OC 0.7.0 with Intel-Wireless on Big Sur runs fine. I have a Windows USB mouse that has a light and it works without issues. I cannot use HackinDROM because Apple only created an EFI partition of 206.5 MB when I initially installed Mac OS X and HackinDROM indicates that there is not enough space.

So here is what I did:
1. Downloaded Casey's most recent OC 0.7.1 Intel-Wireless-Vision-D
2. Used OpenCoreConfiguration upgraded to 0.7.1 and inserted the PlatformInfo. No other changes.
3. Put this on my Flash Drive and rebooted OC from the flash drive.
4. Up to this point the light on the bottom of the mouse is lit.
5. Select the Big Sur disk (11.4) and it begins booting, however, very soon into the boot process the light goes out on the USB mouse. I tried plugging the mouse into various USB ports on the back of the board but no light.

USB works fine in OC 0.7.0 but not in OC 0.7.1.

I'm still going through the thread to see if there is a solution.

Thanks

Rand

 

[dsingh]

Hi @CaseySJ,

Quick question, with aim to improve the build. The first post mentioned that USBInjectAll is needed with iMac20,x. But according to dortania and GitHub README of USBInjectAll, the kext is temporarily used in order to enable all the ports and find the USB info and create a ACPI table from it, which can now be used to enable USB ports. Once done, should the USBInjectAll be not needed any longer? Why does the NOTE mandates it with only iMac20,x and not iMac19,1 or even iMacPro1,1?

from README:

Without a custom configuration, it is not intended that this kext be used long term.

EDIT:
Moreover, the dortania guide mentions this in section after a custom USBmap.kext is created from above mentioned method (By using USBInjectAll temporarily, enabling ALL ports and creating custom map and then removing the USBInjectAll)

Note: Do not use either the SSDT-UIAC.aml or USBInjectAll with the USBmap.kext. This kext we just made should be used by itself with no other USB kexts besides XhciUnsupported if your system needs it. Reason for this is USBInjectAll is no longer being maintained and the USBmap.kext version is how real Macs USB map as well so as close to "Apple Like" as possible to fit the OpenCore mood.

from: https://dortania.github.io/OpenCore-Post-Install/usb/intel-mapping/intel.html

thanks!

 

[RandC]

I'm having the same problem. OC 0.7.0 with Intel-Wireless on Big Sur runs fine. I have a Windows USB mouse that has a light and it works without issues. I cannot use HackinDROM because Apple only created an EFI partition of 206.5 MB when I initially installed Mac OS X and HackinDROM indicates that there is not enough space.

So here is what I did:
1. Downloaded Casey's most recent OC 0.7.1 Intel-Wireless-Vision-D
2. Used OpenCoreConfiguration upgraded to 0.7.1 and inserted the PlatformInfo. No other changes.
3. Put this on my Flash Drive and rebooted OC from the flash drive.
4. Up to this point the light on the bottom of the mouse is lit.
5. Select the Big Sur disk (11.4) and it begins booting, however, very soon into the boot process the light goes out on the USB mouse. I tried plugging the mouse into various USB ports on the back of the board but no light.

USB works fine in OC 0.7.0 but not in OC 0.7.1.

I'm still going through the thread to see if there is a solution.

Thanks

Rand

Compared 0.7.0 config.plist with 0.7.1 config.plist. Here are the differences I noticed:

1. ACPI DMAC enabled in 0.7.1, does not exist in 0.7.0
2. BOOTER SetupVirtualMap enabled in 0.7.1, disabled in 0.7.0
3. DeviceProperties
PciRoot(0x0)/Pci(0x2,0x0)
#AAPL,slot-name (in 0.7.1), not commented out in 0.7.0
4. Kernel
USBInjectAll off in 0.7.1, on in 0.7.0
FakePCII_Intel_HDMI... on in 0.7.1, off in 0.7.0
IntelBlueToothFixUp new and on in 0.7.1, does not exist in 0.7.0
FakePCII_Intel_I225V new and on in 0.7.1, does not exist in 0.7.0
Airportitlwm_Monterey.. new an on in 0.7.1, does not exist in 0.7.0

Most obvious difference is USBInjectAll is off in 0.7.1 whereas it is on in 0.7.0, but haven't tried to turn it on yet to see if it fixes the issue.

Rand

 

[RandC]

Compared 0.7.0 config.plist with 0.7.1 config.plist. Here are the differences I noticed:

1. ACPI DMAC enabled in 0.7.1, does not exist in 0.7.0
2. BOOTER SetupVirtualMap enabled in 0.7.1, disabled in 0.7.0
3. DeviceProperties
PciRoot(0x0)/Pci(0x2,0x0)
#AAPL,slot-name (in 0.7.1), not commented out in 0.7.0
4. Kernel
USBInjectAll off in 0.7.1, on in 0.7.0
FakePCII_Intel_HDMI... on in 0.7.1, off in 0.7.0
IntelBlueToothFixUp new and on in 0.7.1, does not exist in 0.7.0
FakePCII_Intel_I225V new and on in 0.7.1, does not exist in 0.7.0
Airportitlwm_Monterey.. new an on in 0.7.1, does not exist in 0.7.0

Most obvious difference is USBInjectAll is off in 0.7.1 whereas it is on in 0.7.0, but haven't tried to turn it on yet to see if it fixes the issue.

Rand

This was the issue:

in the OC 0.7.1 config.plist file USBInjectAll was disabled. Enabling that and rebooting enabled USB ports again and my USB mouse now works again.

Reason:

1. Casey's downloaded configuration plist files has USBInjectALL enabled.
2. Using OpenCore Configurator Version 2.48.1.0 with preferences Configuration Properties set to OC 0.7.1 Release Version disables USBInjectAll
3. So the issue was with the version of OpenCore Configurator, even with Properties set to 0.7.1 disabling USBInjectAll.

So if anyone else is having this problem, make sure that USBInjectAll is enabled in Kernel.

Rand

 

[dsingh]

Hi @CaseySJ,

Quick question, with aim to improve the build. The first post mentioned that USBInjectAll is needed with iMac20,x. But according to dortania and GitHub README of USBInjectAll, the kext is temporarily used in order to enable all the ports and find the USB info and create a ACPI table from it, which can now be used to enable USB ports. Once done, should the USBInjectAll be not needed any longer? Why does the NOTE mandates it with only iMac20,x and not iMac19,1 or even iMacPro1,1?

from README:


EDIT:
Moreover, the dortania guide mentions this in section after a custom USBmap.kext is created from above mentioned method (By using USBInjectAll temporarily, enabling ALL ports and creating custom map and then removing the USBInjectAll)


from: https://dortania.github.io/OpenCore-Post-Install/usb/intel-mapping/intel.html

thanks!

Hi @CaseySJ,

I explored more. I have been able to generate a custom USBmap.kext which only has Info.plist inside it (and not executable code), and used that to enable USB ports. I disabled all SSDT-UIAC-VISION-D-V*.aml. and USBInjectAll.kext. The ports were still working.

Having no extra code (through a kext) is a good thing, it lets OpenCore handles the port maps, since USBInjectAll is no longer maintained, this makes it even better and as dortania mentioned in my above post's quote, this makes it closer to "Real Mac" because Apple also uses similar method for port maps in real Macs.

I'll post more the proper custom USBMap.kext soon, which is very specific to our Vision D board. Dortania recommends having custom SSDTs and Port maps, as this reduces bloat and faster boot times compared to having generic SSDT and stuff, because those have to go through lots of of non-existing things to figure things our at start of the boot.

Current working config, without UIAC.aml's and no USBInjectAll.kext.

This was the issue:

in the OC 0.7.1 config.plist file USBInjectAll was disabled. Enabling that and rebooting enabled USB ports again and my USB mouse now works again.

Reason:

1. Casey's downloaded configuration plist files has USBInjectALL enabled.
2. Using OpenCore Configurator Version 2.48.1.0 with preferences Configuration Properties set to OC 0.7.1 Release Version disables USBInjectAll
3. So the issue was with the version of OpenCore Configurator, even with Properties set to 0.7.1 disabling USBInjectAll.

So if anyone else is having this problem, make sure that USBInjectAll is enabled in Kernel.

Rand

Yes, that's correct. You will need either USBInjectAll.kext or a custom USB port map to enable proper working of the USB ports. This is because macOS is very poor in picking USB ports from ACPI tables. Thing is USBInjectAll.kext should be used temporarily while preparing config and booting into macOS for very first time. After that a custom map with limited no. of ports can be created (because macOS has limit of 15 ports limit, counting each hub as single unit). XhciPortLimit quirk is also meant to be temporary and be enabled while generating port map. After that, a new USBMap's plist should be used and both USBInjectAll.kext, XhciPortLimit should be removed. Even SSDT-UIAC-VISION-D-V*.aml ACPI tables shouldn't be needed as the new map can disable ports too.