Clover General discussion

[LockDown]

Hi

i have  .nvram.plist (a hidden .nvram.plist WITH a DOT in the beginning). Where did this came from?

Edited March 14, 2018 by ellaosx

[Maniac10]

The dot at the beginning of a file name is a trick that "flags" it as hidden. It was most likely created by Clover's shutdown scripts. Open Console.app and locate /Library/Logs/CloverEFI/rc.shutdown.log for more information.

[apianti]

6 hours ago, TheBloke said:

Hi guys

Got a bug report:  ATI Connectors Data and ATI Connectors Patch will not accept enough digits to allow me to use the FB connector patch that I need.

1. If I try to copy these into ATI Connectors Data or ATI Connectors Patch in Clover Configurator, it changes it to '0'
2. If I manually edit them into config.plist, Configurator says: "Please fix the following code before saving: integer overflow in <integer> on line 162

You used the <integer> tag:

<key>ATIConnectorsData</key>
<integer>000400000403000000010001000000001204030100000000000400000403000000010001000000002205040200000000000400000403000000010001000000001102010300000000000400000403000000010001000000002103020400000000000400000403000000010001000000001000050500000000000400000403000000010001000000002001060600000000</integer>
<key>ATIConnectorsPatch</key>
<integer>000200000402000000010001000000002205050200000000040000001402000000010001000000001000060500000000000400000403000000010001000000001204030100000000000400000403000000010001000000001102010300000000000400000403000000010001000000002103020400000000000400000403000000010001000000002001040600000000</integer>

but it requires the <string> tag:

<key>ATIConnectorsData</key>
<string>000400000403000000010001000000001204030100000000000400000403000000010001000000002205040200000000000400000403000000010001000000001102010300000000000400000403000000010001000000002103020400000000000400000403000000010001000000001000050500000000000400000403000000010001000000002001060600000000</string>
<key>ATIConnectorsPatch</key>
<string>000200000402000000010001000000002205050200000000040000001402000000010001000000001000060500000000000400000403000000010001000000001204030100000000000400000403000000010001000000001102010300000000000400000403000000010001000000002103020400000000000400000403000000010001000000002001040600000000</string>

I have made the same comments on your ticket and closed it.

[TheBloke]

2 hours ago, apianti said:

You used the <integer> tag:

<key>ATIConnectorsData</key>
<integer>000400000403000000010001000000001204030100000000000400000403000000010001000000002205040200000000000400000403000000010001000000001102010300000000000400000403000000010001000000002103020400000000000400000403000000010001000000001000050500000000000400000403000000010001000000002001060600000000</integer>
<key>ATIConnectorsPatch</key>
<integer>000200000402000000010001000000002205050200000000040000001402000000010001000000001000060500000000000400000403000000010001000000001204030100000000000400000403000000010001000000001102010300000000000400000403000000010001000000002103020400000000000400000403000000010001000000002001040600000000</integer>

but it requires the <string> tag:

<key>ATIConnectorsData</key>
<string>000400000403000000010001000000001204030100000000000400000403000000010001000000002205040200000000000400000403000000010001000000001102010300000000000400000403000000010001000000002103020400000000000400000403000000010001000000001000050500000000000400000403000000010001000000002001060600000000</string>
<key>ATIConnectorsPatch</key>
<string>000200000402000000010001000000002205050200000000040000001402000000010001000000001000060500000000000400000403000000010001000000001204030100000000000400000403000000010001000000001102010300000000000400000403000000010001000000002103020400000000000400000403000000010001000000002001040600000000</string>

 

OK thanks @apianti.  The bug is in Clover Configurator then, which always uses integer tags for this field.  I thought Configurator was made by the Clover team but I see now it is not.  I will report this separately to the creators of the Configurator.

[pkdesign]

On 2/21/2018 at 5:21 PM, TheBloke said:

Guys, I want to test the boot flag -nehalem_error_disable

In Clover Configurator, do I add that as typed above: -nehalem_error_disable

Or do I add it as: nehalem_error_disable ?

Looking at the default boot flags provided by Configurator, some are -flag and some are just flag, no - before it. I'd expect a flag to normally have a - so maybe this is just how Configurator is displaying some of them inconsistently.

I'm currently booted with -nehalem_error_disable added as follows:



My guess is that this is the correct way, but I wanted to ask to be sure, as I have no other way of confirming if the flag applied or not (I'm trying it on my X58 system as I've heard it's sometimes required/helpful on systems with SMBIOs 5.1.)

What is the purpose of -nehalem_error_disable?

All I have found is that it disables AppleTyMCEDriver. Is that correct and why would I want to do that?

How are you measuring/viweing your speedsteps?

Edited March 16, 2018 by pkdesign

[TheBloke]

4 hours ago, pkdesign said:

What is the purpose of -nehalem_error_disable?

All I have found is that it disables AppleTyMCEDriver. Is that correct and why would I want to do that?

I read a few (old) posts indicating that this might be necessary on X58 motherboards.  I know AppleTyMCEDriver is related to ECC memory.  The MacPro 5.1 system used X58 with ECC RAM, and I've read discussion of needing to patch AppleTyMCEDriver if you don't use ECC RAM (as I don't).

I've also read discussions of -nehalem_error_disable being needed sometimes, to prevent certain errors.  I can't remember which ones now, but maybe again related to ECC.

I don't think you need the flag.  I added it because I was getting strange crashes and errors post-boot, so I was looking for anything that might be wrong.  I've since resolved my errors/crashes (a bad DIMM), so it wasn't anything to do with adding that flag that fixed it. 

So as far as I can tell, adding -nehalem_error_disable has made zero difference to my system (positive or negative).  In fact I am not even using the flag any more - I removed it a week or so ago when I was adding another flag, and nothing is different that I can see.

Maybe whatever problem the flag solved is no longer an issue in High Sierra.  Or maybe it's something that Clover now fixes automatically.  Or maybe it was never needed at all and was just misinformation.    I wouldn't bother about it at all, unless you have errors related to ECC, which I doubt you do.

Quote

How are you measuring/viweing your speedsteps?

HWMonitor, as bundled with RehabMan's version of kozlek's FakeSMC.

 

EDIT: Another way to see them is iStat Menus (although the info is slightly odd, in that the listed frequencies don't match the listed multipliers on a core-by-core basis, and, at least for me, one of the cores is called 'Core 18'. But the listed multipliers do generally match what HWMonitor is showing):

Spoiler

 

Edited March 16, 2018 by TheBloke

[cecekpawon]

On 3/14/2018 at 1:31 PM, TheBloke said:

OK thanks @apianti.  The bug is in Clover Configurator then, which always uses integer tags for this field.  I thought Configurator was made by the Clover team but I see now it is not.  I will report this separately to the creators of the Configurator.

Seems fixed on 4.60.3.4

[TheBloke]

52 minutes ago, cecekpawon said:

Seems fixed on 4.60.3.4

Yeah I reported it to mackie and it's fully working now.

[pkdesign]

On 3/16/2018 at 2:37 PM, TheBloke said:

HWMonitor, as bundled with RehabMan's version of kozlek's FakeSMC.

 

EDIT: Another way to see them is iStat Menus (although the info is slightly odd, in that the listed frequencies don't match the listed multipliers on a core-by-core basis, and, at least for me, one of the cores is called 'Core 18'. But the listed multipliers do generally match what HWMonitor is showing):

  Reveal hidden contents

 

Oh okay, that is how I check speedsteps. I miss DPCIManager's ability to show you speedsteps. Anyone going to fix that?

[TheBloke]

Is there any way to get Clover to block loading of a Kext in EFI/CLOVER/kexts/Other?

For example if I want to make two config files, one that loads WhateverGreen and one that does not.

I have read through the Wiki and can't find such an option.  But when I go to Options in the boot GUI, there is an option with a name that seems to suggest it might do this.

I know Clover can't stop loading of kexts on the OS drive, but presumably it could theoretically prevent them loading from EFI/CLOVER/kexts?  

If it can't do this now, this would be a nice feature to add I think.

Thanks.

[chris1111]

11 minutes ago, TheBloke said:

Is there any way to get Clover to block loading of a Kext in EFI/CLOVER/kexts/Other?

For example if I want to make two config files, one that loads WhateverGreen and one that does not.

I have read through the Wiki and can't find such an option.  But when I go to Options in the boot GUI, there is an option with a name that seems to suggest it might do this.

I know Clover can't stop loading of kexts on the OS drive, but presumably it could theoretically prevent them loading from EFI/CLOVER/kexts?  

If it can't do this now, this would be a nice feature to add I think.

Thanks.

Type space 

 

[TheBloke]

1 minute ago, chris1111 said:

Type space 

 

 

Ahh yes that's the name - thanks.  But do you know if there is a config.plist name for "Block injected kexts" ?    So that kexts can be disabled permanently in a config file?

I think maybe this Block option is only available from Boot menu, and can't be configured in config.plist?  At least I can't find any name for this option in the Wiki or via Google.

[chris1111]

18 minutes ago, TheBloke said:

Ahh yes that's the name - thanks.  But do you know if there is a config.plist name for "Block injected kexts" ?    So that kexts can be disabled permanently in a config file?

I think maybe this Block option is only available from Boot menu, and can't be configured in config.plist?  At least I can't find any name for this option in the Wiki or via Google.

I dont think its possible from config.plist, not sure ?

[TheBloke]

Just now, chris1111 said:

I dont think its possible from config.plist, not sure ?

Yeah it seems not.  I will raise it as a feature request on the tracker.  Thanks.

[el_charlie]

37 minutes ago, TheBloke said:

Is there any way to get Clover to block loading of a Kext in EFI/CLOVER/kexts/Other?

For example if I want to make two config files, one that loads WhateverGreen and one that does not.

I have read through the Wiki and can't find such an option.  But when I go to Options in the boot GUI, there is an option with a name that seems to suggest it might do this.

I know Clover can't stop loading of kexts on the OS drive, but presumably it could theoretically prevent them loading from EFI/CLOVER/kexts?  

If it can't do this now, this would be a nice feature to add I think.

Thanks.

Use the -radoff boot arg.

[TheBloke]

1 minute ago, el_charlie said:

Use the -radoff boot arg.

Oh yeah!  Of course, that would work fine for WEG.  Thanks, I forgot about that.

I still think it would be helpful if Clover had this option in config.plist for other kexts - but yeah, no need for WEG   Which is the only kext I need to do it for at the moment anyway.

[apianti]

Use the \EFI\CLOVER\OEM\SystemProduct\ (where SystemProduct is one of the two things given in your boot.log as to what system product [motherboard] you are running) folder as root instead of just \EFI\CLOVER if you want different configurations for different machines, otherwise just disable the kext injection from the options. There is already this capability, please do not open tickets because you did no research, or even waited long enough for an answer......

[TheBloke]

17 minutes ago, apianti said:

Use the \EFI\CLOVER\OEM\SystemProduct\ (where SystemProduct is one of the two things given in your boot.log as to what system product [motherboard] you are running) folder as root instead of just \EFI\CLOVER if you want different configurations for different machines, otherwise just disable the kext injection from the options. There is already this capability, please do not open tickets because you did no research, or even waited long enough for an answer......

1. I wanted variable kext loading for the same machine, not two different machines. 

2. I wanted to disable loading of specific kexts, but not all.  Disabling all kext loading will not help, in fact it would stop me booting at all.

I won't open a ticket but I believe the feature request is valid - in the case of WEG it is possible to disable it via a boot flag, but this does not help in the case of other Kexts.  For example, yesterday I wanted to test loading with and without FakeSMC_GPUSensors.  As there is no way to do this via different config files, I must either delete this kext from EFI/CLOVER/Kexts/Other, or else continually interrupt boot to choose Block Kexts.   It would definitely be useful to have this in a config.plis variable.

[apianti]

15 minutes ago, TheBloke said:

1. I wanted variable kext loading for the same machine, not two different machines. 

You can load another config from the options menu....?

15 minutes ago, TheBloke said:

2. I wanted to disable loading of specific kexts, but not all.  Disabling all kext loading will not help, in fact it would stop me booting at all.

This is already a feature as I said, you can disable individual kexts from being injected in the options menu. Putting this in the config serves no purpose, just move it from kexts injection folder if you don't want it injected then.

16 minutes ago, TheBloke said:

I won't open a ticket but I believe the feature request is valid - in the case of WEG it is possible to disable it via a boot flag, but this does not help in the case of other Kexts.  For example, yesterday I wanted to test loading with and without FakeSMC_GPUSensors.  As there is no way to do this via different config files, I must either delete this kext from EFI/CLOVER/Kexts/Other, or else continually interrupt boot to choose Block Kexts.   It would definitely be useful to have this in a config.plis variable.

HOW? Then you would have to edit your config.plist constantly instead which is infinitely more wasteful then just choosing not to inject a kext from an already available options menu....

[TheBloke]

9 minutes ago, apianti said:

You can load another config from the options menu....?

This is already a feature as I said, you can disable individual kexts from being injected in the options menu. Putting this in the config serves no purpose, just move it from kexts injection folder if you don't want it injected then.

HOW? Then you would have to edit your config.plist constantly instead which is infinitely more wasteful then just choosing not to inject a kext from an already available options menu....

Having the ability to block specific kexts in config.plist means I can save configuration files with certain sets of multiple config for testing which includes whether kexts are loaded or not:  configA = setting1 + setting2 + kextA loaded; configB = setting1 + setting2 + kextA not loaded;  configC = setting3 + kextA loaded; configD = setting3 + kextA not loaded.  etc.

Then each test can be run just by putting the next config in, and any past test can be repeated just by copying a single file that is already prepared.  The configs can be named exactly for everything that is tested, so when I copy "config.setting2.setting3.kextA-notloaded.plist" I know everything it does - there is not required a separate external step (modifying kexts/Other, or interrupting boot to disable the kext) required to make this test correct.

I know the manual methods to do this, that's what I have been doing recently - eg scripting the copying of kexts in and out of kexts/Other along with copying a specific config.plist (or an alternative - make multiple USB sticks with varying kext/Other folders.)  I just feel that it would be a little cleaner and more manageable to be able to control everything from config.plist. 

Obviously you do not agree and I do not want to argue with you.  Certainly it is not hugely important.  But I know that if it existed I would definitely make use of such a feature next time I needed to debug my system with/without kexts.

[apianti]

9 minutes ago, TheBloke said:

Having the ability to block specific kexts in config.plist means I can save configuration files with certain sets of multiple config for testing which includes whether kexts are loaded or not:  configA = setting1 + setting2 + kextA loaded; configB = setting1 + setting2 + kextA not loaded;  configC = setting3 + kextA loaded; configD = setting3 + kextA not loaded.  etc.

Then each test can be run just by putting the next config in, and any past test can be repeated just by copying a single file that is already prepared.  The configs can be named exactly for everything that is tested, so when I copy "config.setting2.setting3.kextA-notloaded.plist" I know everything it does - there is not required a separate external step (modifying kexts/Other, or interrupting boot to disable the kext) required to make this test correct.

I know the manual methods to do this, that's what I have been doing recently - eg scripting the copying of kexts in and out of kexts/Other along with copying a specific config.plist (or an alternative - make multiple USB sticks with varying kext/Other folders.)  I just feel that it would be a little cleaner and more manageable to be able to control everything from config.plist. 

Obviously you do not agree and I do not want to argue with you.  Certainly it is not hugely important.  But I know that if it existed I would definitely make use of such a feature next time I needed to debug my system with/without kexts.

This is irrelevant, you are basically just asking to complicate something you could already do just by moving the files (in the EFI shell). I don't think any developer is going to put time into this. But if any one out there wants to do that, please be my guest, just know that currently the behavior of any arrayed setting is to be merged not replaced.

Edited March 20, 2018 by apianti

[Cyberdevs]

Hi guys,

Clover is injecting these values by default, is there a way to tell it not to?

I already have InjectATI=True and I already selected the Orinoco as the default framebuffer but it and macOS High Sierra 10.13.4 Beta (5,6,7) detect my GPU as an AMD RX 480 instead to RX 580.

I don't use WEG or a SSDT.

[apianti]

9 hours ago, Cyberdevs said:

Hi guys,

Clover is injecting these values by default, is there a way to tell it not to?

I already have InjectATI=True and I already selected the Orinoco as the default framebuffer but it and macOS High Sierra 10.13.4 Beta (5,6,7) detect my GPU as an AMD RX 480 instead to RX 580.

I don't use WEG or a SSDT.

They have the same device id, 0x67DF, as RX470/480/570/580 are modified ellesmere architecture, so the code needs to be rewritten to determine the revision id. There are a lot of cards that can only be determined by the revision id.... I somewhat suspect that maybe this has something to do with why polaris cards have a lot of trouble in macOS, the card probably needs revision id injected as well but I don't know how a real mac actually does this. Is there anyone that has the External Graphics Development Kit that can provide the dumps for the RX580 card that it uses?

EDIT: This may be an interesting read, https://egpu.io/forums/mac-setup/guide-radeon-rx-580-identification-is-macos/. That guy modified the VBIOS to be exactly what the EGDK has to get the card to work, yet some people experience black screens in windows after..... Also the second to last post may be of some interest.

EDIT2: WhateverGreen injects the revision id, it's just "revision-id" property. So I would think that you should get proper graphics with WhateverGreen.kext...?

Edited March 28, 2018 by apianti

[Cyberdevs]

4 hours ago, apianti said:

They have the same device id, 0x67DF, as RX470/480/570/580 are modified ellesmere architecture, so the code needs to be rewritten to determine the revision id. There are a lot of cards that can only be determined by the revision id.... I somewhat suspect that maybe this has something to do with why polaris cards have a lot of trouble in macOS, the card probably needs revision id injected as well but I don't know how a real mac actually does this. Is there anyone that has the External Graphics Development Kit that can provide the dumps for the RX580 card that it uses?

EDIT: This may be an interesting read, https://egpu.io/forums/mac-setup/guide-radeon-rx-580-identification-is-macos/. That guy modified the VBIOS to be exactly what the EGDK has to get the card to work, yet some people experience black screens in windows after..... Also the second to last post may be of some interest.

EDIT2: WhateverGreen injects the revision id, it's just "revision-id" property. So I would think that you should get proper graphics with WhateverGreen.kext...?

Thanks apianti but what is interesting is that if I only injectATI and don't select the Orinoco as the framebuffer or any other framebuffer, macOS detects it as RX 580 but I lose one of my displays, what I forgot to mention is that I'm conducting these tests under macOS 10.13.4 (Beta 4,5,6,7) which as you know doesn't need WEG or RadeonDeInit to make AMD GPUs work.

Edited March 28, 2018 by Cyberdevs

[joe75]

3 hours ago, Cyberdevs said:

 I forgot to mention is that I'm conducting these tests under macOS 10.13.4 (Beta 4,5,6,7) which as you know doesn't need WEG or RadeonDeInit to make AMD GPUs work.

Apple has proprietary identification for AMD and a PC card with OEM identification will never fully just work, no matter what is being reported.