MorenoAv Posted February 9, 2019 Share Posted February 9, 2019 (edited) hi @Andres ZeroCross, Thanks for your answer , but I regressed to 4862, because the 4871/2/3, was the same... Edited February 9, 2019 by MorenoAv Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted February 9, 2019 Share Posted February 9, 2019 1 minute ago, MorenoAv said: hi @Andres ZeroCross, Thanks for your answer , but I regressed to 4862, because the 4871, was the same... No problem here, fast scan entry in here r4871 or r4874 are working good. Check your Drivers64UEFI files 1 Link to comment Share on other sites More sharing options...
MorenoAv Posted February 9, 2019 Share Posted February 9, 2019 (edited) ok then is my hack, but is not all bad, at last I managed to repair the random reboots, when I wasn't at the hack... I already checked and as you can see in the picture I have OsxAptioFix2Drv-64, OsxAptioFix3Drv-64, and I think it is the culprit... Edited February 9, 2019 by MorenoAv Link to comment Share on other sites More sharing options...
Pavo Posted February 9, 2019 Share Posted February 9, 2019 (edited) 39 minutes ago, MorenoAv said: ok then is my hack, but is not all bad, at last I managed to repair the random reboots, when I wasn't at the hack... I already checked and as you can see in the picture I have OsxAptioFix2Drv-64, OsxAptioFix3Drv-64, and I think it is the culprit... Since you have AptioMemoryFix, you do not need EmuVariableUefi, OsxAptioFix2Drv or OsxAptioFix3Drv. Not sure what AsAmiShim is for. Upload your entire EFI folder because I assume you have other things wrong also. Edited February 9, 2019 by Pavo 1 Link to comment Share on other sites More sharing options...
MorenoAv Posted February 9, 2019 Share Posted February 9, 2019 Thanks @Pavo, I have no ideia what is AsAmiShim, too, but the others I have deleted them, and rebooted but the result is the same, a painfull slow boot, and at this moment I was looking for ways to locate and uninstall the drivers from L/E or S/L/E to see if it resolves the slowww boot... I only kept OxsAptioFix3Drv-64 and EmuVariable-64.efi. Link to comment Share on other sites More sharing options...
Andres ZeroCross Posted February 9, 2019 Share Posted February 9, 2019 Just now, MorenoAv said: Thanks @Pavo, I have no ideia what is AsAmiShim, too, but the others I have deleted them, and rebooted but the result is the same, a painfull slow boot, and at this moment I was looking for ways to locate and uninstall the drivers from L/E or S/L/E to see if it resolves the slowww boot... I only kept OxsAptioFix3Drv-64 and EmuVariable-64.efi. Try to reset your Nvram first, press F11 at GUI CLOVER Link to comment Share on other sites More sharing options...
MorenoAv Posted February 9, 2019 Share Posted February 9, 2019 @Andres ZeroCross, thanks but didn't result, rebooted instead... and the pita slow boot continues... Installed clover r4874, and cleaned the drivers-64 fold and nothing results... Link to comment Share on other sites More sharing options...
Matgen84 Posted February 9, 2019 Share Posted February 9, 2019 (edited) 2 hours ago, MorenoAv said: @Andres ZeroCross, thanks but didn't result, rebooted instead... and the pita slow boot continues... Installed clover r4874, and cleaned the drivers-64 fold and nothing results... As @Pavo says install AptiomemoryFix.efi, delete EmuvariableUEFI and OsxAptioFix3drv You folder don't have FSInject-64.efi (Clover files mandatory). This driver is installed with Clover automatically. You can keep HFSPlus.efi. If you use FakeSMC.kext, install SMCHelper.efi too. Edited February 9, 2019 by Matgen84 Link to comment Share on other sites More sharing options...
arsradu Posted February 9, 2019 Share Posted February 9, 2019 (edited) 4 hours ago, MorenoAv said: hi all, Today I noticed that clover 4862, took much more time to boot, than usual, this is the new boot of clover or is only my hack? Could you try to check the option to PlayAsync in Clover Config -> GUI? See if there's any improvement? You will need Clover 4871 or newer. You can find 4871 on Clover's official download page. Edited February 9, 2019 by arsradu Link to comment Share on other sites More sharing options...
MorenoAv Posted February 9, 2019 Share Posted February 9, 2019 (edited) Thank you all for the help, I made the changes suggested by @arsradu and @Matgen84, and almost nothing changed, the only change is that the boot was a second or two faster... I'll send my clover for your review, if you have time... CLOVER.zip Edited February 9, 2019 by MorenoAv Link to comment Share on other sites More sharing options...
arsradu Posted February 9, 2019 Share Posted February 9, 2019 (edited) 18 minutes ago, MorenoAv said: Thank you all for the help, I made the changes suggested by @arsradu and @Matgen84, and almost nothing changed, the only change is that the boot was a second or two faster... I'll send my clover for your review, if you have time... CLOVER.zip Uncheck Debug option in Clover Boot. Edited February 9, 2019 by arsradu 1 Link to comment Share on other sites More sharing options...
MorenoAv Posted February 9, 2019 Share Posted February 9, 2019 (edited) Thanks man... I'll try it right away... Solved, it was the debug ... Thanks again... PS: And now that the debug is solved, the random reboots began again, but the strange thing is the reboots occur when I'm not at hack, when I'm here all is well... can someone help me with this? Thanks one more time and this time I'll send my EFI... EFI.zip Edited February 9, 2019 by MorenoAv 2 Link to comment Share on other sites More sharing options...
arsradu Posted February 10, 2019 Share Posted February 10, 2019 (edited) @MorenoAv I think your hack likes to play a little hide and seek with you there. Also, I think the reboots are not random. And if you say they're happening when you're not using the machine, my first instinct would be to check whether or not your computer sleeps well. And also, if it wakes up from sleep well. In other words, power management options. Both for CPU and GPU. Cause, sometimes, on some GPUs (in my experience, the iGPUs tend to do that), the system goes into a reboot when waking up from sleep. Now, you can of course, test this theory by setting your computer to never go to sleep by itself, from System Preferences -> Energy Saver -> Prevent computer from sleeping automatically when the display is off. If you still have that issue after that, then the issue might be caused by something else. But my guess is that it's GPU PM. So, although this is not a fix, it's a valid workaround, in case the attached config doesn't help you. Now, I took a look at your config, and it looks like you forgot to add ig-platform-id along with your Inject Intel. Also, not sure they're important for this case, but I also adjusted a few things in ACPI. Also, I don't know how you zip your files, but it doesn't seem to be using the built-in archiver. And I don't know why. Cause if you try to double click one of your archives to extract it, you will get this. It still works with third party softwares like iZip Unarchiver, or Extractor or similar ones. But not with the default one. And, for some reason, it seems to only occur with your files. So, while I can still see your files, I just thought you should know about it. Anyway, could you please, try the attached config and see if it works any better? The issue is most likely not Clover related. config.plist.zip Edited February 10, 2019 by arsradu Link to comment Share on other sites More sharing options...
MorenoAv Posted February 10, 2019 Share Posted February 10, 2019 (edited) Hi @arsradu, Thanks for your time and willingness to help me, and you are right my machine likes to play hide and seek with me, and still can but not for much long... the replacement is almost here. But meanwhile I tried you config.plist and adjusted System Preferences -> Energy Saver -> Prevent computer from sleeping automatically when the display is off, and tried to put the machine to sleep and it immediately wakes again... It's a surprise for me because I can open my zip files, and they are created by Mojave with compress file only. For unzip I normally use not the default unzip but the unarchiver. The culprit must be GPU PM. Edited February 10, 2019 by MorenoAv Link to comment Share on other sites More sharing options...
arsradu Posted February 10, 2019 Share Posted February 10, 2019 (edited) 11 minutes ago, MorenoAv said: Hi @arsradu, Thanks for your time and willingness to help me, and you are right my machine likes to play hide and seek with me, and still can but not for much long... the replacement is almost here. But meanwhile I tried you config.plist and adjusted System Preferences -> Energy Saver -> Prevent computer from sleeping automatically when the display is off, and tried to put the machine to sleep and it immediately wakes again... It's a surprise for me because I can open my zip files, and they are created by Mojave with compress file only. For unzip I normally use not the default unzip but the unarchiver. The culprit must be GPU PM. So, with System Preferences -> Energy Saver -> "Prevent [...]" DISABLED, you cannot put the machine to sleep? The point of that feature is to keep the computer on. To not allow it to enter sleep mode by itself. However, putting it to sleep from the Apple menu -> Sleep should override that and force it to go into sleep. If it tries to go to sleep, then automatically wakes up, then yes, that's a matter of GPU PM and it's not related to Clover. I was only curious if your restarts happen when the "Prevent [...]" option is Enabled. Meaning if you leave your computer idle for 15 minutes for example, or however it takes it to automatically go to sleep, it won't go to sleep of course, since the Prevent option is ON, but will it reboot after 15 minutes? That's what I wanted to know. Cause I think it won't restart by itself. And I think the problem is on Wake from sleep. Basically, instead of waking up normally, it goes into reboot instead. But I could be wrong. Edited February 10, 2019 by arsradu 1 Link to comment Share on other sites More sharing options...
MorenoAv Posted February 10, 2019 Share Posted February 10, 2019 In the end I don't know how much time it takes to reboot, and I say this, because if for example I am at the machine and go eat dinner when I go back to the machine it has rebooted and is in initial screen, ready to put the password to enter maOS. It happens the two ways, with or without ''Prevent'' and it didn't sleep, instead reboots immediately... Link to comment Share on other sites More sharing options...
tmbt Posted February 11, 2019 Share Posted February 11, 2019 Hi guys, the injectKexts=Detect works also with VirtualSMC ? Because in the Clover wiki it refers only about FakeSMC.kext Thnaks Link to comment Share on other sites More sharing options...
LockDown Posted February 11, 2019 Share Posted February 11, 2019 @tmbt yes. it for all 3rd party kexts Link to comment Share on other sites More sharing options...
tmbt Posted February 11, 2019 Share Posted February 11, 2019 1 hour ago, ellaosx said: @tmbt yes. it for all 3rd party kexts Thanks! Link to comment Share on other sites More sharing options...
Slice Posted February 11, 2019 Share Posted February 11, 2019 7 hours ago, tmbt said: Hi guys, the injectKexts=Detect works also with VirtualSMC ? Because in the Clover wiki it refers only about FakeSMC.kext Thnaks No, "detect" means "detect FakeSMC in SLE". If detected then don't inject kexts from /EFI/CLOVER/kexts/other/ For my mind it is better to set injectKexts=YES, and forget about "Detect". 4 Link to comment Share on other sites More sharing options...
arsradu Posted February 11, 2019 Share Posted February 11, 2019 (edited) 42 minutes ago, Slice said: No, "detect" means "detect FakeSMC in SLE". If detected then don't inject kexts from /EFI/CLOVER/kexts/other/ For my mind it is better to set injectKexts=YES, and forget about "Detect". Exactly. By the way, Slice. I'm not sure what's the default value here. But...wouldn't it be better to set YES by default? I think it's set to Detect by default. But...if we can inject kexts from Clover, why would we even bother with S/L/E in the first place? Also, if we can build Clover with external drivers...can we also build it with external kexts...? Especially FakeSMC. Or VirtualSMC. And add one of them by default in Clover/kexts/Other? I think that's probably one of the most overlooked kexts. One that a lot of new users forget about. And also, one of the most important ones. :)) So...I don't know. My opinion is that this should be set to YES by default. If people still like to have FakeSMC in S/L/E, sure, they can set it to Detect. But...then, you'll have only FakeSMC in S/L/E...and the rest of your kexts in Clover/kexts/Other...? It sounds not intuitive to me. If you can keep them all in one place, then maybe keep them all in one place, for easier management, in my opinion. Now, there are indeed some kexts, such as CodecCommander, which, for as far as I know, only work from S/L/E. But...Detect only refers to FakeSMC. So...that's not gonna make any difference anyway. Just my 2 cents. Edited February 11, 2019 by arsradu 2 Link to comment Share on other sites More sharing options...
tmbt Posted February 11, 2019 Share Posted February 11, 2019 4 hours ago, Slice said: No, "detect" means "detect FakeSMC in SLE". If detected then don't inject kexts from /EFI/CLOVER/kexts/other/ For my mind it is better to set injectKexts=YES, and forget about "Detect". I think it's a way of thinking. All my kexts are in /L/E (including VirtualSMC and Lilu) and i've only VirtualSMC , lilu and WhateverGreen in /Other so that these kext are inject when /L/E is not available (i.e. during Apple update or Recovery). I'm doing this because according to Rehabman : - placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking. - if you develop kexts, error checking is very important! - some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*) - the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality - so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems) - placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac) These seem to me all good reasons to do as he says so i'm following his example. I'm not sure if he is correct and i don't want to start a war .. I'm just following his advices Mattia Link to comment Share on other sites More sharing options...
arsradu Posted February 11, 2019 Share Posted February 11, 2019 (edited) Quote I think it's a way of thinking. All my kexts are in /L/E (including VirtualSMC and Lilu) and i've only VirtualSMC , lilu and WhateverGreen in /Other so that these kext are inject when /L/E is not available (i.e. during Apple update or Recovery). To me, this is not efficient. One reason being that you're basically doubling your kexts. :)) Quote - placing them in /S/L/E (or /L/E on 10.11+) and including in kernel cache, makes kextcache do a lot of error checking. Not sure what kind of error checking is kextcache doing in this case. So I'm not gonna say anything on that. Maybe people with more experience and knowledge can comment on that. Quote - if you develop kexts, error checking is very important! Are you a kext developer? If not...I don't see the benefit from your point of view. Quote - some kexts don't work from Clover/kexts (AppleHDA injector, CodecCommander, BrcmFirmware*) True that. But...once again, are you using any of those kexts? Cause...I don't. At least not anymore. Quote - the idea behind Clover/kexts is to have a set of *stable* and *minimalistic* kexts that will allow booting of the installer/recovery, not full functionality I'm not sure what was the idea behind this implementation, but I can tell you it served me very well over the years, and not just for installer/recovery. Actually, I've had more issues placing kexts in S/L/E than having them in Clover/kexts/Other. It might be (probably is) a very subjective point of view, but...I don't know. To me, it's a lot easier to drag and drop my kexts into Clover/kext/Other than fiddling with S/L/E's permissions and all that. Call me lazy, but I prefer spending my time actually using my computer, than trying to get it to work. So...I do appreciate the simplicity and the convenience that Clover's implementation brings to this. Quote - so...the kexts there I tend to not update as often and the full set is not there (less unneeded kexts, less problems) And still, you seem to prefer having two sets of kexts, one updated, one not, instead of having them all in one place, and up to date. How is that gonna bring you less problems? :)) Quote - placing kexts into kernel cache for day-to-day use is "more native" (as it would be on a real Mac) vs. injection (which is very non-Mac) It might be less native, and "non-Mac", but then again, a lot of the hackintoshing is. And, I personally haven't noticed any difference in day-to-day use between having those kexts in S/L/E rather than having them in Clover/kexts. And I think the benefits of this implementation overweigh the lack of realism. Again, just my opinion. And also, not trying to cause any discussions or so. :)) Just...sharing my opinion on the points you laid out. Simply because I think difference of opinion (done right) can start a very nice and fruitful conversation. And it can lead to progress, on both sides. Edited February 12, 2019 by arsradu 6 Link to comment Share on other sites More sharing options...
bidero Posted February 13, 2019 Share Posted February 13, 2019 Guys, I'm still having problems with boot chime I can only select AMD HDMI and Intel HDMI without freeze. Whenever I want to change my audio output to ALC1150 (any output), whole GUI freezes and no value is written to NVRAM. Since newer Clover revisions use different way of saving NVRAM value, BootChimeCfg is no longer working also. Tested on 4870, 4871 and 4876. Link to comment Share on other sites More sharing options...
lisai9093 Posted February 13, 2019 Share Posted February 13, 2019 For boot chime, is it possible to add USB speaker support? My desktop use USB speaker as the only output Link to comment Share on other sites More sharing options...
Recommended Posts