Contribute
Register

[Success] GIGABYTE Z370 Gaming 7 + Intel Core i7-8700K + RX 580 + (2x) Dell P2715Q 4k @ 60Hz

jb007 said:
Hi @jiffyslot, while waiting for @HackaShaq to reply, my take is that you have to use Emulated NVRAM as this Mobo does not have NVRAM.

To test the emulated NVRAM:
Code: 
In a terminal, set a persistent variable entry in memory:
nvram TEST_VAR=DELETE_ME
Restart system.
In a terminal look for the persistent variable entry previously set in memory:
nvram -p | grep TEST_VAR
Delete the persistent variable entry from memory using the terminal:
nvram -d TEST_VAR

If you don't use Emulated NVRAM, you will not see the variable (TEST_VAR) after rebooting, as there is no non-volatile RAM to store the variable.

If you are using Emulated NVRAM, you should see a the variable and also have a nvram.plist file in the /EFI folder.

Jim
Click to expand...

I couldn't find an answer to this that convinced me, so I'll ask. Does our mobo need an UEFI Emulated NVRAM Clover build or just the plain old UEFI NVRAM Clover build?
 
Daystrom M5 Multitronic Unit
Z390 DESIGNARE |  i9 9900K |  RX 6600 Pulse 8GB
The Guardian of Forever
Z370 AORUS Gaming 7 |  i7 8700K |  RX 580 Pulse 8GB
jiffyslot said:
I couldn't find an answer to this that convinced me, so I'll ask. Does our mobo need an UEFI Emulated NVRAM Clover build or just the plain old UEFI NVRAM Clover build?
Click to expand...
Do I have to convince you!
Our Mobo has native NVRAM support.
Obviously you have to tell Clover this when you use Multibeast to setup your Clover boot options.
See this post by the guru himself RehabMan.
Bottom line is if you don't have EmuVariableUefi-64.efi in this folder;
Screen Shot 2018-12-14 at 8.42.45 pm.png

then, you are using Native NVRAM, but to make sure you should run this test to make sure variables are sticking.
Code: 
In a terminal, set a persistent variable entry in memory:
sudo nvram TEST_VAR=DELETE_ME
Restart system.
In a terminal look for the persistent variable entry previously set in memory:
nvram -p | grep TEST_VAR
Delete the persistent variable entry from memory using the terminal:
nvram -d TEST_VAR

Edit: Just tested to make sure version F11 of the BIOS hasn't removed native NVRAM, some ASUS Mobo's had a problem where it was removed on a BIOS upgrade!

Jim:geek:
 
Last edited:
jb007 said:
@mavherzog, I need more info and more details.
1. When version of macOS are you on?
2. Do other USB3 devices work at their rated speed?
3. Are USB3 devices being reconised as USB3 devices, not USB2 devices.
4. Model of WebCam?

My Logitech C920 works fine FWIW.
Click to expand...

1. 10.14.2
2. No clue. Not sure if any other USB devices ARE USB3 (probably not).
3. Again, not sure.
4. Logitech BRIO (https://www.amazon.com/gp/product/B01N5UOYC4/?tag=tonymacx86com-20)

Could very well be a USB3 issue. What should I do?? :)
 
Point me in the right direction and, hopefully, I can fix it!!
 
jb007 said:
Hi @hackmymac, @jiffyslot, @e-troc and others enquiring about USB and power to charge phones and also the Apple Superdrive.

Firstly @hackmymac the answer is yes, you don't need anymore kexts, just follow my post(s) to @jiffyslot and you should be good to go.

Ok, here is what I've found out. If you look at this article on the Apple site, it's apparent that some genuine Mac models have the capability of providing more power than the USB specs.

Our iMac is not a genuine Mac in the USB department and cannot provide the sort of current (amperage), that an Apple iMac can.

...
Click to expand...

Thanks for your great effort you've put in so far!!

Sure our Hackintosh is no genuine Mac, though it should be easily able to provide at least the current defined by USB specs.
That being said, let's take a look at how the current on a genuine Mac looks like in System Information:

iPhone:
...
Current Available (mA): 500
Current Required (mA): 500
Extra Operating Current (mA): 1600
Sleep current (mA): 2100
Click to expand...

Unfortunately, on our Hackintosh, this is not the case - at least not on my machine. I just tested it again with my iPhone. Even though it is correctly recognized, while charging, it only uses 500 mA current on USB 3.1 Bus (the Red USB-3.1 Port of the MoBo):

Screenshot 2018-12-14 at 20.22.38.png


Even with the 1500 mA limit of USB 3.1, it should look like this, to charge the iPhone in a reasonable time:

Current Available (mA): 500
Current Required (mA): 500
Extra Operating Current (mA): 1000 <--- USB 3.1 limit 1500 mA - 500 mA already in use = 1000 mA
Sleep current (mA): 1500 <--- "Sleep Current" = current being delivered while our Hackintosh is sleeping
Click to expand...

So how can we manipulate macOS to request / define the "Extra Operating Current" and "Sleep Current" (latter to provide the ability to charge our device over night with the Hackintosh being in sleep mode)? Is there a way to patch this behavior?

I found this comment on /r/hackintosh, that says something like:
You probably need to inject the AAPL,current properties into your USB devices (EH01/EH02/XH01).
Click to expand...
and adds some code to be added to SSDT:
Code: 
DefinitionBlock ("SSDT-USB", "SSDT", 1, "APPLE ", "UsbSsdt", 0x00000001)
{
   External (_SB.PCI0, DeviceObj)

   Scope (\_SB.PCI0)
   {
       /* Adding device properties to EH01 */
       Scope (EH01)
       {
           Name (AAPL, Package()
           {
               "AAPL,current-available", 2100,
               "AAPL,current-extra", 2200,
               "AAPL,current-extra-in-sleep", 1600,
               "AAPL,current-in-sleep", 1600,
               "AAPL,device-internal", 0x02,
               "AAPL,max-port-current-in-sleep", 2100
           })

           Method (_DSM, 4, NotSerialized)
           {
               If (Arg2 == Zero) { Return (Buffer() { 0x03 }) }
               Return (AAPL)
           }
       }

       /* Adding device properties to EH02 */
       Method (EH02._DSM, 4)
       {
           If (Arg2 == Zero) { Return (Buffer() { 0x03 }) }
           Return (^^EH01.AAPL)
       }

       /* Adding device properties to XH01 */
       Method (XH01._DSM, 4)
       {
           If (Arg2 == Zero) { Return (Buffer() { 0x03 }) }
           Return (^^EH01.AAPL)
       }
   }
}

Unfortunately, since I just joined the hackintosh community about 3 weeks ago, I don't know what exactly it means, where it is being done and if it is still possible on 10.14.2. Maybe you've got an idea how to do this in respect to adding the above mentioned "Extra Operating Current" and "Sleep current"?

Your help is MUCH appreciated!
 
Last edited:
jb007 said:
Do I have to convince you!
Our Mobo has native NVRAM support.
Obviously you have to tell Clover this when you use Multibeast to setup your Clover boot options.
See this post by the guru himself RehabMan.
Bottom line is if you don't have EmuVariableUefi-64.efi in this folder;
View attachment 372690
then, you are using Native NVRAM, but to make sure you should run this test to make sure variables are sticking.
Code: 
In a terminal, set a persistent variable entry in memory:
sudo nvram TEST_VAR=DELETE_ME
Restart system.
In a terminal look for the persistent variable entry previously set in memory:
nvram -p | grep TEST_VAR
Delete the persistent variable entry from memory using the terminal:
nvram -d TEST_VAR

Edit: Just tested to make sure version F11 of the BIOS hasn't removed native NVRAM, some ASUS Mobo's had a problem where it was removed on a BIOS upgrade!

Jim:geek:
Click to expand...
Thanks @jb007. I didn't think so. The reason I asked is because that Terminal command returned an error and was unusable, so I figured something had changed.
When starting and the machine gets past post, I'm seeing a flurry of rapid, unreadable text (as in 4x game show end-credits speed) speed that I can't capture. the nvram -c command is not working in Clover's command/terminal tool, so all I can do is hit F11. When Mojave starts up, there's a brief lower-left side flurry of more text, then it all boots fine. Nothing seems to be in Verbose mode. It's just odd.

Additionally, the EFI folder did not copy over correctly to the cloned SSD (I dragged it from the Mojave APFS startup volume's EFI to the EFI of the destination, of course.) -So I had to -re-drag it from a 3rd backup I already had. I think this could be an APFS problem. I've never had this file-copy issue with HFS+ -that's why I was cloning Mojave to a clean HFS+ SSD. I just don't trust the APFS scheme which also caused problems in the past in my 2012 Mini.
 
Last edited:
Daystrom M5 Multitronic Unit
Z390 DESIGNARE |  i9 9900K |  RX 6600 Pulse 8GB
The Guardian of Forever
Z370 AORUS Gaming 7 |  i7 8700K |  RX 580 Pulse 8GB
hackmymac said:
Thanks for your great effort you've put in so far!!

Sure our Hackintosh is no genuine Mac, though it should be easily able to provide at least the current defined by USB specs.
That being said, let's take a look at how the current on a genuine Mac looks like in System Information:



Unfortunately, on our Hackintosh, this is not the case - at least not on my machine. I just tested it again with my iPhone. Even though it is correctly recognized, while charging, it only uses 500 mA current on USB 3.1 Bus (the Red USB-3.1 Port of the MoBo):

View attachment 372781

Even with the 1500 mA limit of USB 3.1, it should look like this, to charge the iPhone in a reasonable time:



So how can we manipulate macOS to request / define the "Extra Operating Current" and "Sleep Current" (latter to provide the ability to charge our device over night with the Hackintosh being in sleep mode)? Is there a way to patch this behavior?

I found this comment on /r/hackintosh, that says something like:

and adds some code to be added to SSDT:
Code: 
DefinitionBlock ("SSDT-USB", "SSDT", 1, "APPLE ", "UsbSsdt", 0x00000001)
{
   External (_SB.PCI0, DeviceObj)

   Scope (\_SB.PCI0)
   {
       /* Adding device properties to EH01 */
       Scope (EH01)
       {
           Name (AAPL, Package()
           {
               "AAPL,current-available", 2100,
               "AAPL,current-extra", 2200,
               "AAPL,current-extra-in-sleep", 1600,
               "AAPL,current-in-sleep", 1600,
               "AAPL,device-internal", 0x02,
               "AAPL,max-port-current-in-sleep", 2100
           })

           Method (_DSM, 4, NotSerialized)
           {
               If (Arg2 == Zero) { Return (Buffer() { 0x03 }) }
               Return (AAPL)
           }
       }

       /* Adding device properties to EH02 */
       Method (EH02._DSM, 4)
       {
           If (Arg2 == Zero) { Return (Buffer() { 0x03 }) }
           Return (^^EH01.AAPL)
       }

       /* Adding device properties to XH01 */
       Method (XH01._DSM, 4)
       {
           If (Arg2 == Zero) { Return (Buffer() { 0x03 }) }
           Return (^^EH01.AAPL)
       }
   }
}

Unfortunately, since I just joined the hackintosh community about 3 weeks ago, I don't know what exactly it means, where it is being done and if it is still possible on 10.14.2. Maybe you've got an idea how to do this in respect to adding the above mentioned "Extra Operating Current" and "Sleep current"?

Your help is MUCH appreciated!
Click to expand...

Ok, @hackmymac, I'm on to it and doing a little bit of digging around I have found that RehabMan has covered this in this guide [Guide] USB power property injection for Sierra (and later). I will try to look at this today.... but I'm suffering from 'man flu' ATM and only firing on one lung!
Jim
 
mavherzog said:
1. 10.14.2
2. No clue. Not sure if any other USB devices ARE USB3 (probably not).
3. Again, not sure.
4. Logitech BRIO (https://www.amazon.com/gp/product/B01N5UOYC4/?tag=tonymacx86com-20)

Could very well be a USB3 issue. What should I do?? :)
Click to expand...

Hi @mavherzog. Your BRIO is supported on macOS and I have a gut feeling that you are just using the USBInjectAll.kext and 26 port patch in your config.plist.

If this is correct then since you are using 10.14.2 then you will not have USB3 ports available as 10.14.2 broke the 26 port patch, This patch was never meant to be used as a production-ready fix. You should either create an SSDT-UIAC.aml using the RehabMan method or an USBPorts.kext that is created by the FB-Patcher method.

I have covered both of these methods many times in the last week or so in this thread, so I won't go into how to do it, so the search is your friend here.
 
jiffyslot said:
Thanks @jb007. I didn't think so. The reason I asked is because that Terminal command returned an error and was unusable, so I figured something had changed.
When starting and the machine gets past post, I'm seeing a flurry of rapid, unreadable text (as in 4x game show end-credits speed) speed that I can't capture. the nvram -c command is not working in Clover's command/terminal tool, so all I can do is hit F11. When Mojave starts up, there's a brief lower-left side flurry of more text, then it all boots fine. Nothing seems to be in Verbose mode. It's just odd.

Additionally, the EFI folder did not copy over correctly to the cloned SSD (I dragged it from the Mojave APFS startup volume's EFI to the EFI of the destination, of course.) -So I had to -re-drag it from a 3rd backup I already had. I think this could be an APFS problem. I've never had this file-copy issue with HFS+ -that's why I was cloning Mojave to a clean HFS+ SSD. I just don't trust the APFS scheme which also caused problems in the past in my 2012 Mini.
Click to expand...

Hi @jiffyslot. Your EFI Folder is formatted as FAT32 and should not be affected by APFS. I'm using APFS now as the default. I've got and app under Windows 10 that lets me read/write to APFS so I don't need to do the HFS to APFS shuffle every time that the macOS is updated.
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top