[Success] b1's "Mac Mini Killer" with macOS Mojave: i7-8700 | Gigabyte Z370N | RX560 | 16GB RAM

[pastrychef]

Any idea why VirtualSMC doesn‘t work? @pastrychef @CaseySJ maybe?

I have no problems with VirtualSMC.

 

[pastrychef]

Thanks for your fast response!

While comparing your Asus Z370-G OC EFI folder (0.5.9) with rrviega's I noticed that VirtualSMC.kext contains a Plugin folder where both SMCProcessor.kext and SMCSuperIO.kext are present.
At the same time these are present in EFI/OC/Kexts as well.

Could this be the reason?

Furthermore, the injection sequence inside config.plist -> Kernel -> Add is different from yours.

I have no idea. I get VirtualSMC from acidanthera and use them as they are.

You can probably use the EFI from my Z370 build. Just clear out everything in config.plist > DeviceProperties > Add.

 

[pastrychef]

@pastrychef

I edited my last post (#780) and attached a modified config.plist.
Could be that the error occurs because these kexts are present inside OC/Kexts as well as inside VirtualSMC.kext/Contents/Plugins.

One question about dGPU injection via DeviceProperties section though (I believe it was in your thread where I read about that MacOS uses the GPU that gets recognized first for encoding):

does it make sense to rename it from Radeon RX 580 to AMD Radeon RX 580?
This is for a iMac19,1 headless config where the IGPU gets injected as Intel UHD Graphics 630 (Desktop)

So just get the VirtualSMC from acidanthera and use that instead. It won't have the Plugins folder.

I don't know how macOS decides which GPU to use. You can use iMacPro1,1 and disable IGPU so it doesn't have any options.

It shouldn't matter how you name your RX 580. You can name it anything, and it should still work the same. It's cosmetic.

 

[rrviega]

Thanks for your fast response!

While comparing your Asus Z370-G OC EFI folder (0.5.9) with rrviega's I noticed that VirtualSMC.kext contains a Plugin folder where both SMCProcessor.kext and SMCSuperIO.kext are present.
At the same time these are present in EFI/OC/Kexts as well.

Could this be the reason?

Furthermore, the injection sequence inside config.plist -> Kernel -> Add is different from yours.

Edit: @rrviega

Please check attached config.plist if the problem still persists with VirtualSMC 1.1.4
Please delete SMCProcessor.kext, SMCSuperIO.kext and VirtualSMC.kext inside OC/Kexts and replace with 1.1.4 attached.

Inside config.plist (Kernel->Add section) I changed the injection sequence and BundlePath.

Maybe this is the reason it doesn't work.

You are right. Fixed now (BundledPath). Now I guess we have a Golden OC Build. Thanks!!!!
Yes, I followed Dortania Guide and further documentation. No mistake. OC have a excellent documentation.

 

[rrviega]

Excellent, you're welcome!
I'm just rebuilding the SSDT's for my build and report back once I have finished everything.

Edit:

@rrviega
By the way, you might want to add NVMeFix.kext to your config.plist for better power management of your NVMe drive.

See here.

Testing here, temperature on XPG S11 pro dropped 3º degrees on Idle. 46º -> 43º. Write speed also improves +- 150mb on Blackmagic Disk Speed. 1950-2050mbs -> 2050-2200mbs. So, I guess it's working. Thanks.

 

[rrviega]

@rrviega

Very nice!

Question: in your Config.plist Kernel -> Quirks Section, XhciPortLimit is set to "YES".

Shouldn't that be set to "NO" after USB Mapping has been done?

I didn't remap everything as I already did it in Clover (which means both SSDT-UIAC.aml and SSDT-USBX.aml are present in ACPI/patched) thus just created the USBPorts.kext via Hackintool. See Post #751 for reference.
This should be fine, no?

Guess I'm done with the config so far – someone brave enough to test it for me? (I'm still on 10.14.6)

Edit:

EFI attached, OCBinaryData already added.
Just paste in own MLB, ROM, SystemSerialNumber and SystemUUID.

With usbinjectall replacing usbports + SSDT-UIAC and SSDT-USBX YES!
I think SSDT-SBUS-MCHC is not really necessary on newer chipsets. I've never used.

Added your fixes to final EFI, with binary resources.

 

[rrviega]

Cool!

Did you test the EFI I posted with your unit?

Does everything work as expected?

No, Rammon. Just figured things inside. Sorry for the last response.
But, If you don't boot with that build the problem is the usbports or SSDT-SBUS-MCHC! Almost identical with mine.

 

[rrviega]

I wasn‘t sure about the XhciPortLimit value just followed Dortonia‘s suggestions but if you say it‘s okay

You are right. In my last release I changed the value to NO. I forgot. Also worked fine with YES value. haha.

anyway, you can test your build on Sanity Checker - OC

 

[rrviega]

I‘m not sure if I understand that correctly. My USB mapping is different from yours (I use Front USB for instance), so some USB ports might be deactivated. Is this what you‘re saying?

Yes, don't use my configuration if it differs from your usb schema (my usbports.kext). Instead, just replace the USB ports with usbinjectall.kext + and your SSDT-UIAC and SSDT-EC-USBX files in ACPI. Or create your own usbports.kext.

With SSDT-SBUS-MCHC idk, because I never needed to use it. Can you explain to me why it is needed? I really don't know.

 

[rrviega]

Concerning SSDT-SBUS-MCHC take a look here. It‘s not exactly needed but I don‘t think it would do any harm when using it.

Concerning USB mapping we only had a misunderstanding.

Nice and should not affect startup. I hope it works well for you. Again, Thanks.